How to build one Jira report that works for both deep analysis and dashboard visibility

[#1]

You know the report. It starts out simple: “Let’s see where work is getting stuck.” But before long, it becomes a messy spreadsheet that’s hard to follow.

• You add a few Jira fields for context (key, summary, assignee…)
• Then you add statuses (because that’s the point)
• Then you add a couple of metrics (waiting vs working)
• Then you scroll horizontally for so long you start considering packing snacks

And here’s the real tragedy:

✅ The report is useful.
❌ Nobody looks at it, especially not on a dashboard.

So teams do what teams always do:

• they simplify the report until it becomes harmless
• or they keep it detailed and accept that it’s unreadable
• or they export it to Excel and enter a new life stage called “Spreadsheet Person”

This article is about a third option:

Build one report that can do two jobs:

1. Deep analysis (when you need details and investigation)
2. Dashboard visibility (when you need fast, at-a-glance truth)

The core Jira problem: dashboards want summaries, workflows need details

Jira dashboards are for quick answers. Workflow analysis is for deep questions.

Those two needs fight each other:

• Analysts want detail (“Which status? Which item? Which owner?”)
• Leaders want clarity (“Is flow healthy? Where’s the bottleneck? What needs attention?”)

If your report is too detailed, it becomes dashboard noise. If it’s too simplified, it becomes useless for investigation.

That’s why most “leadership dashboards” end up being a quiet museum of charts: beautiful, polished… and opened once per quarter like a historic monument.

Can you solve this in Jira without third-party apps?

You can partially solve it — but not elegantly.

What you can do natively

• Look at an issue’s history (fine for one ticket, terrible for patterns)
• Use Jira charts (great for certain views, but limited for workflow-forensics)
• Build dashboards from filters and gadgets (good for counts, not for “time inside workflow stages” or repeat transitions)

The hard part Jira doesn’t make easy

To understand workflow behavior, you usually need things like:

• time spent in each status (business hours vs 24/7 matters)
• how often issues bounce into the same status (rework loops)
• how often issues move back and forth between two statuses (ping-pong)

Doing that at scale in native Jira usually means a mix of manual digging, exports, and saying things like, “well, it feels like review is slow.”

If you’ve ever said “we just need to communicate better” in a retro… there’s a good chance the real problem is the workflow, not the conversation.

Where Time in Status by SaaSJet fits

This is exactly what the Time in Status app is built for: it turns Jira issue history into workflow reports so teams can find bottlenecks, reduce rework, and improve predictability without worklogs or spreadsheets.

And it matters for this article because Time in Status gives you two places to use the same report:

• Main Reporting UI (Table/Chart, deep analysis)
• Accurate Time in Status dashboard gadget (Table/Chart, visibility)

In gadget configuration, you can choose report types like Time in Status, Status Count, Transition Count, Status Entrance Date, and more, then display them as a Table (work item list) or Chart.

So you’re not building “a dashboard report” and “an analysis report.”

You’re building one report with two zoom levels.

The method: design a report that scales from dashboard → investigation

Step 1: Build the report in Table View first (this is where truth is born)

Start in Apps → Time in Status and configure the report like you normally would:

• Choose a report type (e.g., Time in Status / Status Count / Transition Count)
• Define your scope (project, sprint, saved filter, label, assignee, etc.)
• Set date ranges (so you don’t accidentally analyze “everything since 2019”)
• Select a calendar (custom business hours or 24/7)
• Choose Table (work item list) as the view

Then open Column manager and pick what actually belongs in the report:

• Work Item fields (key, summary, assignee…)
• Statuses
• Status Groups (to roll up statuses into meaningful phases)
• User Groups (when you’re using Assignee Time)

✅ Now you have a correct report. But it may still be unreadable.

That’s where the new feature comes in.

Step 2: Use Column Groups (so your table stops looking like a crossword puzzle)

What Column Groups do

Column Groups organize related columns into logical groups, making the table easier to read and compare.

The key thing: you can collapse and expand groups, so you can switch between:

• overview mode (totals)
• detail mode (every column)

Column Groups are available in:

• Table view on the main report page
• Dashboard gadget (Accurate Time in Status)

And the best part: when groups are collapsed, they show totals. For example, you’ll see totals across all statuses or all users.

What groups you’ll see

Depending on the report type, groups can include:

• Jira Fields
• Statuses
• Users
• Status Group / User Group rollups

Also, some core fields remain ungrouped (Key / Work type / Summary), so you don’t lose the basics.

Step 3: Build the “two zoom levels” on purpose

Here’s the simple rule:

Collapsed = dashboard mode

Show totals, reduce noise, let humans read it.

Expanded = analyst mode

Open the group you care about and investigate.

This is what turns one report into something both audiences can use.

And it’s also how you stop dashboards from becoming theater.

Now: put the same report on a dashboard (without rebuilding it)

Once the report works in Table View, you can bring the same logic to a dashboard using the Accurate Time in Status gadget.

In gadget configuration you can set:

• report type (Time in Status / Status Count / Transition Count / etc.)
• scope (assignee / filter / label / project / reporter / sprint)
• date ranges + calendar
• view type: Table (work item list) or Graph

And when you choose Table view, you can configure the report columns in the gadget via the same Column manager options (fields, statuses, status groups, user groups).

Column Groups are also available in the gadget, which is what makes this whole “one report, two jobs” idea actually work.

A practical example (that usually gets instant “ohhh” reactions)

Let’s say you want one report that answers:

• Are we mostly waiting or working?
• Which statuses inside “waiting” are the worst offenders?
• Which specific work items are contributing to it?

Dashboard view (collapsed groups)

• You keep Waiting time and Working time visible as totals
• You collapse Statuses into a single “total statuses” column
• You keep key fields visible (Key / Summary / Assignee)

Result: leadership sees the shape of the workflow immediately.

Analysis view (expand the “Statuses” group)

Now you expand Statuses and get the detailed breakdown: which statuses are consuming the most time.

Result: the team can actually fix something.

This is the core difference between:

• “Our cycle time is bad” (vague)
  and
• “Review is eating our timeline” (actionable)

Bonus: when you want patterns first, use Report Summary

Sometimes even a well-structured table is still… a table.

When you want the “pattern layer” first, use Report Summary.

The idea is simple (and honestly underrated):

Count → how big the problem is
Sum → how much impact it has
Avg → how consistent it is

This is the mental shift from:
“What’s wrong with this issue?”
to:
“What does the system look like overall?”

Common mistakes (so your report doesn’t become a dashboard ghost)

1) Mixing workflows in one report

Different teams, different status meanings → arguments instead of insight.

2) Too broad scope, no date filtering

The report becomes slow/noisy and people stop trusting it. Time in Status docs explicitly call out scope and date filtering as common causes of “slow or empty” reports/gadgets.

3) Treating dashboards like analysis tools

Dashboards are for quick decisions. Analysis lives in the app. Your goal is not “show everything.”  Your goal is “show enough to trigger the right conversation.”

Make the table readable, and the dashboard becomes useful

A lot of teams think the problem is:
“we need better dashboards.”

But the real problem is:
“our tables are unreadable, so nobody trusts what they see.”

Column Groups fix a surprisingly big part of that by letting you organize columns, collapse or expand groups, and get totals at a glance in both Table View and dashboard gadgets.

Which means you can finally build what every Jira team claims they want:

✅ one source of truth
✅ usable at two zoom levels
✅ without rebuilding the same report twice

Try it

If you want to test this on your own Jira data:

1. Start a trial of Time in Status by SaaSJet
2. Build one report in Table View (Time in Status / Status Count / Transition Count)
3. Use Column Groups to create “collapsed dashboard mode” + “expanded analysis mode”
4. Add the same report to a dashboard with Accurate Time in Status gadget

If your workflow has real bottlenecks, you’ll feel the difference right away. Mostly, you’ll stop scrolling sideways like it’s your job.

Do your dashboards fail because they’re missing data… or because the data is there but nobody can read it?