Short definition
A Jira filter is a saved JQL query. Filters are first-class objects with owners, share permissions, and subscriptions - they back agile boards, dashboard gadgets, scheduled email reports, and automation rules. The filter, not the underlying query, is what other Jira objects reference, so renaming a filter doesn't break the things that consume it.
Filters as first-class objects
In Jira, a filter is not just a URL with a JQL string in it. It’s a stored entity with:
- An owner (the user who created or last took ownership).
- A name and optional description.
- Share permissions (who can see it).
- An edit permission (who can change the JQL).
- A favourite flag per user.
- A subscription list (who gets emailed when, on what schedule).
Everything in Jira that references “this set of issues” prefers to do so via a filter ID. Boards, dashboard gadgets, automation rule triggers - they all hold a reference to the filter, not a copy of the JQL. This means editing the filter automatically updates every consumer.
Filter ownership traps
When the user who owns a filter leaves the company and their Jira account is deactivated, the filter becomes inaccessible to others unless an admin transfers ownership. Boards backed by an orphaned filter break. This is one of the most common Jira surprises during offboarding.
A defensive pattern: own important filters from a service account or assign them to a Jira admin group’s lead. Don’t leave production-critical filters owned by a single human user.
Filter visibility vs. issue visibility
A filter can be shared with everyone in the organisation, but each viewer only sees the issues they are allowed to see. The filter says “this is the query,” not “this is the result set.”
This is occasionally confusing because two users running the same filter can see different counts of issues. That’s working as intended - the filter is the question, the answer depends on the asker’s permissions.
Filter subscriptions
Filter subscriptions email a rendered view of the filter results on a schedule. Useful for:
- Daily standups - “what did we close yesterday?”
- Weekly status emails - “all open issues for the team.”
- SLA monitoring - “issues breaching SLA in the next 4 hours.”
Subscriptions are configured per filter, not per user. The same filter can have many subscriptions with different recipient lists and schedules.
Filters and boards
Every agile board in Jira is backed by exactly one filter. The filter decides “which issues might appear on this board.” The board’s column configuration then maps Statuses to columns. Filter changes propagate to the board automatically.
A common mistake is to put ORDER BY clauses in board filters - Jira’s agile boards manage ranking via the
Rank field, and explicit ORDER BY in the filter is ignored on board views but does affect the filter
results elsewhere.
Common questions
What is a filter in Jira?
A Jira filter is a saved JQL query. Filters are first-class objects with owners, share permissions, and subscriptions - they back agile boards, dashboard gadgets, scheduled email reports, and automation rules. The filter, not the underlying query, is what other Jira objects reference, so renaming a filter doesn't break the things that consume it.
How do you share a filter with the team?
Open the filter, click Details -> Edit permissions, and add a share scope: a project, a project role, a group, or 'Any logged-in user.' The viewer needs both the share permission *and* permission to see the underlying issues - a public filter still shows only issues each viewer is allowed to see.
What's the difference between a filter and a board?
A filter is the JQL query. A board is the visual interface (Scrum or Kanban) built on top of a filter. Every board has exactly one filter; the filter decides which issues appear on the board, and the board's column configuration decides which Status maps to which column.
Can a filter be subscribed to via email?
Yes. Filter subscriptions can be scheduled (daily, weekly, custom cron) and emailed to specified users or groups. Subscriptions are commonly used for executive summaries ('all open P0 bugs') and SLA tracking ('issues breaching response SLA today').