How to Write JQL Filters in Jira: A Practical Guide for PMs
Jira's basic search is fine for finding a single ticket. For anything a PM actually needs, such as every customer-reported bug in the current sprint or every story that moved to Done last week, you need Jira Query Language. JQL looks intimidating at first, but most useful queries are built from a handful of fields, operators, and functions.
This guide covers the JQL building blocks, a set of queries PMs reuse constantly, and how to save filters, share them, subscribe to them, and use them to power boards and dashboards. Field names can vary slightly between Jira sites, especially for custom fields, so use autocomplete in the advanced search box to confirm names on your instance.
Working in Jira? Turn your spec into dependency-ordered tickets.
Paste the feature or spec. Vantage pulls out the requirements and breaks them into tickets, ordered by what blocks what, ready to groom with your team.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD and dependency-ordered tickets from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Open advanced search
Go to Filters and choose to search work items or issues, then switch from basic to JQL (advanced) mode. The JQL editor autocompletes field names, operators, and values as you type, which is the fastest way to learn the syntax on your own Jira site. If a field you expect is missing, it may be a custom field with a different name or not available in the projects you are searching.
- Open the Filters menu and start a new search
- Switch to JQL mode
- Type a field name and use autocomplete to explore operators and values
Learn the core building blocks
A JQL clause is a field, an operator, and a value: project = MOB. Combine clauses with AND and OR, group them with parentheses, and sort with ORDER BY. The operators you will use most are =, !=, IN, NOT IN, ~ (contains text), IS EMPTY, and comparison operators for dates. Relative dates such as -7d or -2w make queries reusable without editing.
- Use IN for lists: status IN ("In Progress", "In Review")
- Use IS EMPTY to find missing data: assignee IS EMPTY
- Use relative dates: created >= -14d
- Sort results: ORDER BY priority DESC, created ASC
Use functions for dynamic queries
Functions make filters adapt automatically. openSprints() returns active sprints, so sprint IN openSprints() always shows the current sprint without editing. currentUser() makes one filter work for everyone. startOfWeek() and endOfWeek() help with weekly reporting. membersOf("group-name") filters by a Jira group.
Build the PM queries you will reuse
A few queries cover most PM needs. Current sprint work for a project: project = MOB AND sprint IN openSprints() ORDER BY rank. High-priority open bugs: type = Bug AND priority IN (Highest, High) AND statusCategory != Done. Stale work: statusCategory = "In Progress" AND updated <= -10d. Unassigned items ready for the sprint: status = "Ready" AND assignee IS EMPTY. Using statusCategory instead of specific status names makes queries resilient to workflow differences between projects.
- Current sprint scope for your projects
- Open bugs by priority across projects
- In-progress items not updated in 10 days
- Items missing an estimate or assignee before planning
Query history with CHANGED and WAS
JQL can look at history, which is valuable for weekly updates. status CHANGED TO Done DURING (startOfWeek(), now()) lists what was completed this week. priority CHANGED AFTER -7d shows recent reprioritization. status WAS "Blocked" DURING (-14d, now()) finds items that were blocked at any point in the last two weeks, even if they have since moved on.
Save, share, and subscribe
Once a query returns the right results, save it as a filter with a descriptive name. Set sharing permissions so the right project or group can see it. Add a subscription to receive the results by email on a schedule; a Monday-morning subscription to 'high-priority bugs opened last week' is a simple way to stay on top of quality without opening Jira.
- Save the query as a filter with a name that describes the question
- Share it with the relevant project, group, or users
- Create a subscription for a weekly email digest
- Star the filter so it appears in your favorites
Use saved filters on boards and dashboards
Boards and dashboard gadgets are driven by saved filters. A dashboard with a filter results gadget, a pie chart grouped by status, and a created vs resolved chart can all point at the same saved filter. Changing the filter updates every gadget, which keeps reports consistent.
Common mistakes
Hardcoding sprint names
Writing sprint = "Sprint 42" means editing the filter every two weeks. Use sprint IN openSprints() or futureSprints() instead.
Matching specific status names across projects
Different projects often use different workflows. statusCategory = Done works across all of them; status = Done only matches projects that use that exact status.
Sharing filters too narrowly
If a dashboard gadget points to a filter that viewers cannot see, the gadget shows nothing for them. Check filter sharing permissions before building shared dashboards.
Tips
Use the text operator ~ sparingly; it searches text fields and can return noisy matches.
Keep a personal doc of your best JQL queries so you can copy them into new filters quickly.
Combine statusCategory with resolution date fields for accurate weekly completion counts.
Name filters after the question they answer, for example 'Open P1 bugs - Mobile'.
How Vantage helps
JQL is how you see the work; Vantage helps you shape it before it lands in the tracker. PMs turn context and a PRD into dependency-aware tickets in Vantage, with requirement links that make filtering by feature reliable once tickets are pushed to Jira or Linear.