Before You Build the Jira Dashboard, Prove the Search Is Answering the Right Question

Twelve high-priority items appear on the dashboard. The chart is clear enough to discuss immediately. Then a team member notices that their release blocker is missing, while three visible items belong to another project.

Before changing the chart, I would open the search behind it. Jira can display the wrong set of records perfectly. The problem may be what the query selects, what the viewer is allowed to see, or both; a different visualization won't recover the missing work. [1][2]

This is a diagnostic guide to that selection problem. The examples below use fictional Jira Cloud records, a project key of PAY, and locally configured priority and label values. They illustrate query behavior, not a configuration tested in your site.

First, say which records belong

“Show important work” leaves an administrator to invent the meaning. For this example, let's make the intended rule explicit: show unfinished work in PAY that is either High or Highest priority, or explicitly labeled as a release blocker.

That last part matters. A medium-priority dependency might still block the release. Equally, a high-priority item already completed doesn't belong in this particular exception report. The rule is a choice about the meeting's purpose, not a universal definition of important work.

A plausible but incorrect JQL query might read:

project = PAY AND priority = High
OR labels = "release-blocker"

JQL gives AND stronger binding than OR. This query therefore selects High-priority PAY items or any visible item with the label, including items elsewhere. It also omits a Highest-priority PAY item without that label and has no condition excluding completed work. [3]

One expression of our intended rule is:

project = PAY
AND statusCategory != Done
AND (
  priority in (High, Highest)
  OR labels = "release-blocker"
)

The parentheses keep both alternatives inside the project and completion conditions. These names must match the site's actual values and process. Here, Done means the configured status category; it is not a substitute for deciding what completion means in your own report. Existing JQL using project remains relevant even where newer screens call projects “spaces.” [4]

A few known records tell us more than a plausible total

The purpose of the query becomes testable before another chart is built:

The repaired query should explain each of these outcomes. A total rising from twelve to fourteen tells us much less: it could mean two missing records were recovered or two unrelated records were added.

Empty values deserve the same attention. A report about unassigned work must deliberately include a missing assignee, rather than assume a comparison with another value will do so. The treatment should follow the question being answered. [4]

Then repeat the search as the intended reader

A shared filter makes the saved query available; it doesn't grant permission to every record the query could select. An administrator and a delivery manager can see different results from the same search. [2]

If PAY-14 appears for the administrator but not for the manager, changing the priority clause again may target the wrong problem. Compare the manager's access to that specific record. If neither can see it in the result but both can open it directly, the selection is a stronger place to investigate. These observations narrow the diagnosis without proving that only one layer can be involved.

Once the correct records reach the right reader, choose the display around the next action. A list may be better than a chart when the manager needs to assign individual blockers. A trend may help when the question concerns recurring growth. The search supplies the population; the display makes its significance easier to inspect.

There is a final distinction worth keeping outside this repair. Two teams can classify priorities differently even when their queries count accurately. That is a comparison of meaning, not another syntax error. Don't let a successful query repair become a claim that every cross-team performance comparison is now sound.

For this meeting, success is more concrete: the missing blocker is present, unrelated work is absent, and the person expected to act can see the same relevant records. The dashboard can then support a discussion about the release instead of becoming the subject of the meeting.