Build one cross-project JQL filter and share it safely

One filter for multiple projects

Your team supports three products in three Jira projects. Every Monday, someone opens three boards, exports three CSVs, and pastes them into a spreadsheet to answer one question: which bugs are open across the portfolio? That manual assembly is slow, and it breaks the moment someone forgets to refresh a filter.

Takeaway: build one saved JQL filter that spans projects, share it with the right group or project role, and add it to a dashboard. This post shows how to write the query, share it safely, and check performance before it lands on a board.

Write a cross-project JQL query

JQL, or Jira Query Language, is Jira's native syntax for searching issues. Go to Issues > Search for issues, switch to advanced search, and enter a query such as:

project in (PROJ-A, PROJ-B, PROJ-C) AND issuetype = Bug AND status not in (Done, Closed, Resolved) AND updated >= -7d

Replace PROJ-A, PROJ-B, and PROJ-C with your actual project keys. The -7d term is a relative date meaning updated within the last seven days.

Run the search and confirm the results: open a few returned issues manually and verify they are unresolved bugs in the listed projects. You need Browse Projects permission for each project included in the query; otherwise those issues will not appear even if the filter runs.

Save the filter and share it narrowly

Save the search with a descriptive name, such as Open bugs across platform projects. Use the Share dialog to add specific users, groups, or project roles. Avoid sharing with Anyone unless you intend for every logged-in user to see the filter; sharing with Anyone can expose issue metadata to all logged-in users.

Recipients who can view the filter can run it and see the issues they already have permission to browse. Sharing a filter does not grant access to projects the recipient cannot otherwise browse. If you need to reverse the change, open the filter, use Share to remove the group, or delete the filter entirely.

Check performance before adding it to a dashboard

JQL behavior and available functions differ between Jira Cloud and Jira Data Center. Functions such as currentUser() and membersOf(), and relative dates such as -7d, should be validated on the target deployment. Queries with many OR clauses or broad tilde (~) text searches can degrade search performance and cause timeouts on large instances.

A practical diagnostic is to run the query in advanced search and note how long it takes. If it is slow, narrow the project list or remove text search before using the filter in a dashboard gadget, agile board, or automation rule. Test on a staging instance with realistic issue volume where possible.

Limitations to plan around

• Filter results are live. There is no snapshot unless you export the results or use a dashboard gadget that refreshes on its own schedule.
• Viewers see only issues they are permitted to browse, so a shared filter may return different issue counts for different people.
• Complex queries may time out or behave differently between Cloud and Data Center, so confirm the exact syntax on your deployment.

Pick one recurring cross-project report, write the JQL, save it, share it with a specific group or role, test the timing, and add it to a dashboard gadget. Review filter shares quarterly so old queries do not stay visible to groups that no longer need them.

Verify these steps on your Jira deployment before relying on them in production; behavior can differ between Jira Cloud and Data Center.