What is Atlassian Analytics?

Atlassian Analytics is a reporting and visualization tool available with Atlassian Cloud Enterprise plans. Its purpose is simple: bring data from multiple Atlassian products into one place so teams can report on how work actually happens across tools.

Instead of looking at Jira, Confluence, or Jira Service Management separately, Atlassian Analytics pulls their data into a central Data Lake. From there, teams can build dashboards that combine information from different products and show relationships that aren’t visible anywhere else.

In practical terms, Atlassian Analytics lets you:

Build dashboards with charts, tables, and visuals that span multiple tools
Start quickly using prebuilt templates for ITSM, Agile delivery, and content reporting
Explore data using a visual builder or write SQL when deeper analysis is needed
Combine Atlassian data with external sources like spreadsheets or databases

The key difference between Analytics and native dashboards is scope. Native dashboards answer product‑specific questions. Atlassian Analytics answers cross‑product questions.

Why Cross‑Tool Reporting Matters

Most organizations do not work in a single system. Planning, execution, service, and documentation all happen in different tools, even when those tools are part of the same platform.

Jira shows delivery work. Jira Service Management captures requests and incidents. Confluence stores plans, decisions, and knowledge. Each tool does its job well, but reporting inside each one only tells part of the story.

This creates a gap. Teams can answer questions like “How many issues are open?” or “How many tickets were resolved?” but struggle with questions that matter more at scale, such as:

How many service requests turn into delivery work?
Are teams documenting decisions before work starts?
Which areas generate the most follow‑up or rework?
Where are bottlenecks happening across tools?

Without cross‑tool reporting, these questions are answered manually. Teams export data, build spreadsheets, and assemble reports by hand. The result is slow, error‑prone, and difficult to maintain.

Cross‑tool reporting matters because it replaces guesswork with shared insight. It allows teams and leaders to see how work actually flows from request to delivery to documentation, instead of relying on disconnected metrics. This kind of visibility becomes more important as organizations grow. The more teams, projects, and tools involved, the harder it is to understand what is really happening without a unified view.

This guide will walk you through how to do cross‑tool reporting with Atlassian Analytics in practice. It focuses on the real steps teams need to take to connect data across Jira, Confluence, and Jira Service Management, and to turn that data into reports teams can actually trust.

An illustration representing disconnected metrics

How to Do Cross‑Tool Reporting with Atlassian Analytics (Step by Step)

Cross‑tool reporting only works when it’s done intentionally. Atlassian Analytics is powerful, but it won’t fix reporting issues on its own. The steps below reflect how teams actually succeed in practice.

Step 1: Start with One Cross‑Tool Question

The most common mistake teams make is opening Atlassian Analytics and trying to build dashboards immediately.

Instead, start with one specific question that clearly spans more than one tool. This keeps reports focused and prevents unnecessary complexity.

Good cross‑tool questions include:

How many Jira issues originated as Jira Service Management requests?
Which delivery work has supporting documentation in Confluence?
How long does work take from request intake to delivery?
Which teams generate the most incidents that require follow‑up work?

If the question can be answered using Jira alone, Atlassian Analytics is unnecessary. If the answer requires connecting Jira with Confluence or Jira Service Management, Analytics is the right tool.

Step 2: Make Sure Your Tools Are Connected in Practice

Before building reports, your tools must already be connected in how teams use them day to day.

Cross‑tool reporting depends on:

Jira issues being linked to Confluence pages where decisions or plans live
Jira Service Management requests being connected to delivery issues
Teams using shared fields, workflows, and naming conventions

If teams are not linking work to documentation or requests to delivery, Analytics has nothing meaningful to connect. This step is often skipped, and it’s why many dashboards look correct but feel wrong.

Atlassian Analytics reflects reality. It does not fix inconsistent usage.

Step 3: Access Atlassian Analytics and Choose the Right Data Sources

Once Atlassian Analytics is enabled on your Atlassian Cloud Enterprise plan, the first real decision you’ll make is where your data should come from. This choice shapes everything that follows.

To get started:

Open Atlassian Analytics from your Atlassian Cloud navigation
Click Create dataset
You’ll be prompted to choose one or more data sources

In most cross‑tool reporting scenarios, you should start with the Atlassian Data Lake. The Data Lake is where Atlassian centralizes data from tools like Jira Software, Jira Service Management, and Confluence, making it possible to query them together.

Use the Atlassian Data Lake when:

Your question spans multiple Atlassian tools
You want to compare work, requests, and documentation
You need a single, consistent source of truth

Only introduce external data sources when they are genuinely required. For example, you might bring in:

Financial or planning data from Google Sheets
Ticket data from a non‑Atlassian system
Operational metrics stored in an external database

Adding external sources too early often makes reports harder to understand and maintain. If your reporting question can be answered using Atlassian tools alone, start there.

When selecting Atlassian products, most cross‑tool reporting use cases include Jira Software for delivery work, Jira Service Management for requests and incidents, and Confluence for documentation and decisions.

Each product exposes tables that represent real objects, such as:

Jira issues and workflows
JSM requests and request types
Confluence pages and spaces
Users, projects, and ownership data

These tables are the raw materials for reporting. You do not need to select everything. Choose only the products and tables that relate directly to the question you’re answering.

Step 4: Build a Cross‑Tool Dataset Before Building Charts

A dataset is where cross‑tool reporting actually happens. This is where you define how data from different tools relates.

A common approach looks like this:

Start with the Jira issues table as the core
Join Jira Service Management request data using issue keys or request IDs
Join Confluence page data using page references or linked issue keys

This creates a single dataset that shows:

Where work originated
How it moved through delivery
Whether supporting documentation exists

At this stage, do not think about charts yet. Focus on defining correct relationships between tools. This is what makes Analytics different from Jira dashboards.

Step 5: Use the Visual Builder First, Use SQL Only When You Need More Control

Once your dataset is solid, you can start shaping how the data is explored. Most teams should begin with the visual query builder. It is designed to handle the majority of cross‑tool reporting needs without requiring SQL.

Use the visual builder when you want to:

Filter data by project, request type, team, or timeframe
Group results by status, issue type, or owner
Compare activity across Jira, Confluence, and JSM
Build reports that other team members can understand and maintain

Visual mode keeps reports easier to update as data structures evolve. This matters in growing environments where workflows and fields change over time.

Switch to SQL mode only when the visual builder can’t express what you need. Common reasons include:

Complex joins that involve multiple conditions
Calculated fields that combine or transform metrics
Advanced logic such as custom aggregations
Blending Atlassian data with external systems

If you’re unsure which mode to use, start in visual mode. You can always convert a query to SQL later if needed. Teams that default to SQL too early often create reports that are harder to maintain and understand.

Choosing between visual builder and SQL in Atlassian Analytics

Step 6: Build Reports That Follow the Workflow, Not the Tool

Good cross‑tool reports reflect how work flows through the organization.

Strong examples include:

A chart showing how many service requests become Jira issues
A table highlighting Jira issues without linked Confluence documentation
A trend showing incident volume compared to documentation updates

Avoid rebuilding product‑specific dashboards inside Analytics. The value of Analytics is in connecting steps across tools, not repeating existing charts.

Step 7: Assemble Dashboards for Specific Audiences

Not everyone needs the same view of the data. Create different dashboards for:

Team leads who need operational visibility
Service managers tracking request impact
Leaders who need high‑level signals, not details

Each dashboard should answer a small number of questions clearly. If someone needs an explanation to understand it, the dashboard is likely doing too much.

Step 8: Validate Reports Against Real‑World Experience

Before sharing dashboards widely:

Review them with people who do the work
Ask whether the data matches their experience
Adjust joins, filters, and definitions as needed

Cross‑tool reporting only creates value when teams trust it.

Step 9: Improve Reports as Usage Improves

Cross‑tool reporting improves as teams improve how they use Atlassian tools.

As teams:

Link work more consistently
Standardize fields and workflows
Capture decisions in Confluence

Analytics becomes more accurate and more useful over time. This is why Analytics should be treated as a long‑term capability, not a one‑time reporting exercise.

A Real Example of Cross‑Tool Reporting in Action

A common setup looks like this:

Jira Service Management captures incoming requests
Jira tracks delivery work
Confluence holds decisions and documentation

Using Atlassian Analytics, teams can see:

How many requests lead to delivery work
How long work takes end to end
Whether documentation keeps pace with delivery

This kind of visibility is not possible with single‑tool dashboards.

Final Perspective

Cross‑tool reporting with Atlassian Analytics is not about building more dashboards. It’s about understanding how work actually flows across planning, delivery, service, and documentation.

When data from Jira, Jira Service Management, and Confluence is viewed together, teams stop relying on assumptions and manual updates. They can see where work originates, how it progresses, and where it slows down. That visibility makes it easier to improve processes, reduce rework, and make better decisions over time.

Atlassian Analytics provides the foundation for this kind of insight, but its value depends on how deliberately it is used. Clear reporting questions, consistent tool usage, and well‑designed datasets matter just as much as the charts themselves. When teams focus on connections first and visuals second, cross‑tool reporting becomes a reliable part of how they operate, not a one‑off reporting exercise.

The Role of Atlas Bench

Atlas Bench works deeply within the Atlassian ecosystem and has extensive experience helping teams turn Atlassian Analytics into a practical reporting capability, not just an enabled feature.

As an Atlassian Platinum Solution Partner, we focus on Atlassian tools and how they work together in real environments. That includes helping teams prepare Jira, Confluence, and Jira Service Management for cross‑tool reporting, designing scalable datasets, and building dashboards that reflect real workflows instead of disconnected metrics.

Is your team just getting started with Atlassian Analytics or struggling to make cross‑tool reporting useful at scale, Atlas Bench helps bridge the gap between raw data and meaningful insight.

Interested in learning more? Connect with Atlas Bench to book a complimentary consultation with our Certified Atlassian Experts.

Start transforming reporting today with Atlassian Analytics. Sign up now to help your team work better together.

Atlas Bench is an Atlassian Platinum Solution Partner with deep Cloud Specialization, helping Data Center customers move beyond migration and fully transform on the Atlassian Cloud Platform. We deliver Atlassian’s System of Work end to end through four collections: Strategy, Teamwork, Service, and Software, connecting planning to execution, aligning teams around outcomes, modernizing service delivery, and accelerating software development.

We are also recognized as an Atlassian World Class Software Development Partner of the Year (Americas), and we bring AI leadership to every engagement. By leveraging Rovo for automation and purpose built agents, we reduce manual work, unlock knowledge across tools, and speed up decision making so organizations realize measurable value faster in cloud.

Atlassian's Remote MCP Server (Overview)

Atlassian's Remote MCP Server (Overview)