Building a Jira Management Dashboard with Saved Filters and Gadgets

Hello. In the last lesson, you used JQL to define a management question and save its answer as a filter. A dashboard puts several such answers on one page. The challenge is not adding gadgets; it is choosing a small set that tells you what needs attention, what is changing, and where to investigate.

In about 40 minutes, you’ll assemble a dashboard for delivery and QA oversight. We’ll use a pattern that works on an older Jira Server installation and transfers to Jira Cloud, while noting where menus, permissions, and gadget availability may differ.

Decide what the dashboard should answer

Imagine opening a dashboard before a project review. Three questions deserve different presentations:

The screenshot below shows an older Jira dashboard with separate gadgets for an introduction, favorite filters, and issues in progress. Notice the Add gadget, Edit layout, and dashboard menu controls. Favorite Filters is a shortcut to searches; it is not itself a report on those searches.

Start with three or four gadgets, not every metric available. A useful dashboard gives an overview and a route to the underlying issues. It should not ask viewers to infer an action from a decorative chart.

Create the dashboard and establish its scope

Watch the selected portions of Modus Create’s “How to Create a Jira Dashboard in Under 10 Minutes.” The interface in the demonstration may not match yours exactly, but the distinction between dashboard settings, saved filters, and gadget settings is durable.

On an older Server interface, look under Dashboards > Manage Dashboards > Create New Dashboard. In Cloud, look under Dashboards for Create dashboard or View all dashboards; labels and placement vary. Give the page a purpose-led name, such as Product delivery and QA overview. If you cannot create a dashboard, check whether your account has the necessary permission rather than assuming manager-level access includes it.

Keep it private while building it. Dashboard viewers can see the page; editors can change its configuration. Those are different grants. When you are ready to share, choose a relevant project role or group if your installation permits it, rather than making the dashboard visible to everyone by default.

The older Atlassian article below provides a useful menu path and a compact explanation of why each of several common gadgets earns its place. Its plugin advice and screenshots are dated, so use it for the design principles and verify gadget availability in your own instance.

Give each gadget a trustworthy source

Use a project you can browse and replace APP with its key. If you already have suitable saved filters, inspect their results instead of creating duplicates. Otherwise, save two searches:

project = APP AND resolution = Unresolved

Call this, for example, APP unresolved work. It supplies the population for a status-by-issue-type breakdown. Then save a narrower exception list:

project = APP
AND resolution = Unresolved
AND assignee IS EMPTY
ORDER BY updated ASC

Call this APP unresolved without owner. The oldest updates appear first. Check several results before saving: resolution = Unresolved is useful only if your workflow sets and clears resolution consistently. If it does not, agree on an appropriate set of statuses and use that as your scope instead.

Add and configure the gadgets around those sources:

1. Filter Results: Select APP unresolved without owner. Display roughly 10 issues with Key, Summary, Status, Priority, and Updated if those columns are available. Place it high on the page. Ten displayed rows are not necessarily the entire result set; open the filter when you need the complete queue.
2. Two-Dimensional Filter Statistics: Select APP unresolved work. Choose Status for one dimension and Issue Type for the other. This can reveal, for example, whether unresolved bugs are concentrated in a particular status. If your management question is ownership instead, use Assignee as a dimension—but issue counts alone do not measure people’s capacity or effort.
3. Created vs Resolved Chart: Choose the project as its source, or a saved filter that includes both created and resolved issues if your gadget offers a filter source. Set a useful time period available in your instance. Do not feed it the unresolved-only filter: excluding resolved issues would undermine the comparison you want the chart to make.

Gadget configuration controls differ by Jira edition and installed apps. Look for the source project, board, or filter first; then set the statistic, columns, result limit, period, and refresh interval that the particular gadget offers. Arrange the exception list where it is immediately visible and put broader context beside or below it.

A Scrum-focused review might warrant Sprint Health or Sprint Burndown as a fourth gadget. As the video shows, those use a board and sprint, not your saved issue filter. Add one only if sprint progress is a standing question for this dashboard; a board’s scope may differ from that of your project filter.

Read the outputs conservatively. Rising created counts relative to resolved counts suggest a growing intake or backlog, but do not by themselves explain why. A large status cell shows a concentration of issues, not how long they have been there. Those questions call for status-history and flow evidence in the next lesson.

Make the shared page work for its viewers

A dashboard can be visible while one of its gadgets cannot access its saved filter. Before sharing the finished page, check both the dashboard’s viewers and the permissions on every filter-backed gadget. Atlassian’s Data Center filter documentation describes the separate filter-sharing control and the permission it requires.

Use the smallest practical audience for the dashboard and its filters. Viewers also need permission to browse the underlying projects and issues; sharing a filter does not grant access to otherwise restricted issues. If possible, ask an intended viewer to open the page and confirm that the gadgets load and the issue links work. If that is not possible, review the dashboard, filter, project, and issue-access settings separately.

Finally, maintain the dashboard as you would any shared management view. A change to saved filter criteria can silently change every gadget that uses that filter. Recheck results after edits, label sources clearly, and remove gadgets that no longer answer a regular question.

Conclusion

A management dashboard is a set of questions with dependable data sources, not a collection of charts. Use Filter Results for issues requiring action, statistics for a scoped breakdown, and a trend gadget for change over time. Keep dashboard access, filter access, and underlying issue access aligned, then verify what another viewer can actually see.

Next, you’ll investigate what a dashboard count cannot tell you: whether work is spending too long in a workflow stage, using status history, control charts, and cumulative-flow evidence.