Create a Shared Jira Saved Filter to Drive a Team Board or Dashboard

The problem: a board or dashboard that quietly shows the wrong issues

A team board that hides half the backlog, or a dashboard gadget that shows zero issues to everyone except its creator, usually points to a saved filter problem rather than a platform outage. Jira saved filters are shared objects with their own permissions and dependencies. When the query is malformed, the sharing is too narrow, or the filter is renamed, the downstream board or gadget fails silently. The useful takeaway: validate the JQL, verify the sharing scope, and confirm the downstream consumer before you rely on the filter.

Desired outcome

You want a named saved filter that returns a predictable issue set, is visible to the intended groups or projects, and drives a board or dashboard gadget without permission gaps. The filter should be stable enough that renaming or editing it does not break existing consumers.

Prerequisites

Before you begin, confirm the following:

• You have the Create Shared Objects global permission if you need to share the filter beyond yourself. Without it, you can save private filters only.
• You hold Browse Projects permission for every project referenced in the query. A user can have access to the filter but still see zero issues if they cannot browse the underlying project.
• You are working in Advanced search (Issues > Search for issues), available in Jira Cloud and Data Center. Some JQL functions and field behaviors differ between Cloud and Data Center; verify availability in your instance before deploying a filter across mixed environments.
• You know the exact project key, group name, or project role you intend to use in the sharing step.

Procedure: create, share, and connect the filter

Compose and validate the JQL

Run the query in Advanced search first. Do not save it until the result set looks correct.

Use the autocomplete to select field names, and quote values that contain spaces or reserved words. For example, to build a board feed for unresolved high-priority work in a specific project:

project = "PLATFORM" AND statusCategory != Done AND priority in (High, Highest) ORDER BY priority DESC, updated DESC

Replace PLATFORM with your actual project key. If your instance uses a custom priority scheme, confirm the priority names in the UI before using them in the query.

Check the issue count against your expectation. Open the first few results and inspect the field values. If the count is zero, run a negative control to confirm the query engine is responding correctly:

issuekey = NONEXISTENT-1

This should return zero results without an error. If it errors instead, the problem is syntax or field availability, not your data.

Save the filter with a stable name

When the query behaves correctly, select Save as. Enter a name that describes the scope, such as Platform Unresolved High Priority. Avoid names that you will likely need to change later; renaming a saved filter can break boards, subscriptions, and dashboard gadgets that reference it.

Set sharing so the right people can see it

After saving, open the filter and locate Details > Edit permissions. By default, a new filter is private. Change the visibility to share with a Group or Project.

Remember that filter sharing is separate from project permissions. If you share the filter with a group, members of that group still need Browse Projects permission for the projects inside the query. A user who can open the filter but cannot browse the project will see an empty result set.

Point the board or gadget at the filter

For a board, open the board configuration and locate the filter or query setting. In many Jira versions this appears under Board settings > General. For a dashboard gadget, edit the gadget and select the saved filter from the filter picker.

Changing a board filter immediately changes the board scope, but the board may cache results for a short period before refreshing. If the board does not update instantly, wait briefly and reload rather than assuming the connection failed.

Expected checks before you rely on it

Run these checks before you announce the board or dashboard as ready:

1. Issue count parity. The count in Advanced search should match the count on the board or gadget. A large mismatch usually means a permission gap or a stale cache.
2. Sharing scope. Re-open Details > Edit permissions and confirm the intended groups or projects are listed. If the filter is still private, only you will see issues on the shared board.
3. Downstream rendering. Open the target board or dashboard gadget as a user who is not the filter owner. Confirm they see the same issue set.
4. Negative control. Run the saved filter with a known non-existent value, such as issuekey = NONEXISTENT-1, and confirm it returns zero results rather than an error.
5. Dependency check. If your instance exposes a reference list for the filter, review it. If not, search for the filter name in board configurations and dashboard gadget settings to inventory consumers before you edit or delete it.

Recovery options for common query and permission failures

JQL syntax errors. These are common when field names contain spaces or reserved words, or when values are unquoted. Use the autocomplete to insert field names, and quote string values. For example, text ~ "server outage" is safer than text ~ server outage. Wildcard support varies by field type and deployment; do not assume * works everywhere.

Empty results despite correct sharing. The most likely cause is that the viewer lacks Browse Projects permission for a project in the query. Have the viewer run the query directly in Advanced search. If they see zero issues there too, the problem is project access, not the filter.

Broken boards or gadgets after a filter change. Renaming or deleting a saved filter can break boards, subscriptions, and dashboard gadgets that reference it. If a board suddenly shows no issues, check whether the underlying filter was renamed or deleted. Re-point the board to the correct filter, or restore the original name if the filter still exists.

Cloud versus Data Center differences. Some JQL functions and field behaviors differ between Jira Cloud and Data Center. If you maintain filters across both environments, verify function availability in each instance before deploying. A function that works in Cloud may be unavailable or behave differently in Data Center.

Board caching. If you have confirmed the filter is correct and shared properly, but the board still shows stale data, the board may be caching results. Wait briefly and refresh. If the problem persists, review the board configuration to ensure it is pointed at the intended filter.

Limitations and version assumptions

This guide describes well-established Jira behavior, but exact menu paths, permission labels, and function availability vary by version and deployment type. Jira Cloud and Data Center may present different options under Details or Board settings. Always verify the current UI in your instance, and test filter changes in a non-production board before applying them to a live team dashboard.