A Jira filter is a saved search built using Jira Query Language that defines a reusable set of issues. Filters are foundational in Jira because they power boards, dashboards, subscriptions, reports, and automation. Anytime Jira needs a dynamic list of issues that updates automatically, it relies on a filter.
At its core, a filter answers one question: which issues should be included. Once saved, that answer can be reused anywhere in Jira. Filters do not store issues themselves. They store the logic used to find issues. This means a filter always reflects the current state of Jira data rather than a static snapshot.
Creating a filter starts in the issue search experience. A user builds a query using either basic search or JQL, verifies that the results are correct, and then saves the search as a filter. When saving a filter, the user gives it a name and chooses whether to mark it as a favorite. Favorites make filters easier to find but do not change who can access them.
By default, filters are private. Other users cannot see or use a filter unless it is explicitly shared. Sharing a filter allows others to view it, use it on boards or dashboards, and subscribe to it. Sharing does not override permissions. A user must still have permission to view the issues returned by the filter, or those issues will be hidden from them.
Filters are used in many places. Scrum and Kanban boards are built on top of saved filters. Dashboards use filters to populate gadgets such as pie charts and issue statistics. Filter subscriptions send scheduled emails based on filter results. Because of this, filters are one of the most tested concepts on Jira certification exams.
One important exam fact is that filters are owned by users, not projects. If the owner of a filter is deactivated, the filter still exists but may stop functioning correctly until ownership is transferred. Exams often test this scenario by asking what happens to a board or dashboard when the filter owner is removed.
Another commonly tested fact is the difference between sharing and subscribing. Sharing controls who can see or use a filter. Subscribing controls who receives email updates. Subscriptions can be sent to individual users or global groups, and those groups are defined in Atlassian Admin, not inside Jira projects.
Exams also test filter permissions. To create and share filters, a user must have the appropriate global permissions. Without them, users can still run searches but cannot save or share them. Similarly, users cannot subscribe to a filter they cannot see.
Filters are also frequently confused with board sub-filters. A board filter defines the scope of a board and directly affects reports. A board sub-filter is optional and only affects what is shown on the board view without changing reports. Understanding this distinction is a frequent exam requirement.
Another key exam concept is visibility. Filters do not bypass project permissions or issue security. If a filter returns issues from multiple projects, each user will only see the issues they are allowed to see. Jira evaluates permissions dynamically for every filter result.
From an ACP-120 and ACP-620 perspective, filters are tested as building blocks. You are expected to know that boards require filters, that filters can span multiple projects, that ownership matters, and that sharing and subscription are separate concepts. Many exam questions sound simple but hinge on one of these details.
In real Jira environments, filters are the glue that holds everything together. Well-designed filters reduce duplication, keep boards accurate, power reliable reporting, and support automation. Understanding how filters work, how they are shared, and how Jira enforces permissions on them is a core skill for any Jira administrator and a guaranteed topic on Jira certification exams.
0 comments:
Post a Comment