Writing JQL Queries with Filters, Logic, Sorting, and Relative Dates

Hello. Last time, you built a search with Jira’s basic controls and saved it as a reusable filter. JQL gives you direct control over the question that filter asks. You can combine conditions that basic search handles awkwardly, specify how results are sorted, and use dates that remain useful when you rerun the filter next week.

This lesson focuses on JQL you could use for day-to-day delivery and QA oversight, whether your workplace has an older Jira Server interface or current Jira Cloud. You will build queries from field criteria, control their logic with AND, OR, and parentheses, add ORDER BY, and choose between calendar-based and rolling date windows. Allow about 40 minutes, including the short viewing and reading segments.

Move from basic search to a JQL clause

Start with the search you already know. Select a project and an issue type in basic search, then switch to Advanced or JQL search. On an older Server installation, look under Issues > Search for issues; in current Cloud navigation, Search or Filters > View all work items leads to the search page. Labels and positions vary, but the useful move is the same: let Jira show you the JQL corresponding to a basic search, then edit it.

A clause has a field, an operator, and a value. For example:

project = APP

Here project is the field, = tests for a matching value, and APP stands for a project key. Add a second clause with AND when both conditions must hold:

project = APP AND issuetype = Bug

issuetype is an issue’s type; you may also see type in Jira examples. Replace APP, Bug, and the status names in this lesson with values available in your installation. Quotation marks are particularly important around multiword values such as "In Progress" or a project name containing spaces. Jira’s autocomplete can help you confirm field names and available values without administrator access.

For a set of acceptable values, use IN:

project IN (APP, API) AND issuetype = Bug

This finds bugs in either listed project, subject to your permission to browse their issues. To find missing data, use IS EMPTY, as in assignee IS EMPTY; an empty assignee is not the same thing as a particular person.

Make the Boolean logic say exactly what you mean

Suppose your review needs bugs from two projects that are either in progress or unassigned. The project and type requirements must apply to both alternatives:

project IN (APP, API)
AND issuetype = Bug
AND (status = "In Progress" OR assignee IS EMPTY)

Read the query as a sentence: an issue must belong to one of the projects, must be a bug, and must meet at least one condition inside the parentheses. This includes an unassigned bug even if its status is not In Progress. If that is not what the review needs, revise the conditions rather than relying on the filter’s name to explain them.

Without the parentheses, the OR assignee IS EMPTY branch can broaden the results beyond the intended scope. Explicit grouping is the safest habit, especially when a query mixes AND and OR.

The Data Center documentation provides a compact written reference for the clause structure and the effect of grouping. It documents AND taking precedence over OR; you need not depend on a remembered precedence rule if you write the grouping you intend.

This matters for cross-project oversight. A filter that unintentionally includes unassigned issues from every accessible project may look plausible at a glance. Check a few returned issues against each branch of your intended rule, particularly after introducing OR.

Order results without changing which issues match

A search condition determines membership in the results; ORDER BY determines their display order. Put it at the end of the JQL:

project IN (APP, API)
AND issuetype = Bug
AND (status = "In Progress" OR assignee IS EMPTY)
ORDER BY updated DESC

updated DESC puts the most recently updated matching issues first. ASC reverses the direction. If your immediate task is to find work that has not been touched recently, ORDER BY updated ASC brings the oldest updates to the top; it does not, by itself, exclude newer issues.

You can sort by more than one field:

project = APP AND issuetype = Bug
ORDER BY priority DESC, updated ASC

Here Jira sorts by priority first, then uses the update date to order issues within the same priority. This is useful for a review queue, but sorting should reflect the review question: “highest priority first” and “least recently updated first” are different choices.

Use dates that stay meaningful when the filter is saved

A fixed date is appropriate for a one-off investigation. A saved filter for a recurring review usually needs a relative date. For example:

project = APP AND issuetype = Bug AND updated >= -7d
ORDER BY updated DESC

The search is reevaluated when you run it; you do not need to edit a stored calendar date each week. But updated means last updated, not “work completed” or “status changed.” A comment or field edit can update an issue. Choose the date field that actually represents your question: created for newly logged issues, updated for recently touched issues, and due for deadlines.

Atlassian University shows both relative intervals and calendar functions. Watch the distinction between “some time before now” and “since the start of this calendar period.”

For a calendar-based monthly view, you might write:

project = APP AND created >= startOfMonth()
ORDER BY created DESC

That means issues created since the start of the current month, not issues created during the last 30 days. The distinction becomes especially noticeable near a month boundary.

For time-sensitive reporting, there is a further distinction between day notation and hours. The Data Center guidance explains that a relative day such as -1d is treated using a day boundary, whereas -24h expresses an hours-based window from the time the query runs. If your review promises “the last 24 hours,” write the hours-based version and verify the boundary behavior in your Jira environment.

A rolling-hours review could therefore use:

project = APP AND updated >= -24h
ORDER BY updated DESC

When dates matter for a report or handover, inspect a result near the cutoff. Time zones and the configuration of your Jira instance can affect how a boundary appears to different users.

Turn the query into a dependable management view

Combine the pieces around a precise question. For example, “Which bugs in these two projects have been updated recently and are either in progress or unassigned?” becomes:

project IN (APP, API)
AND issuetype = Bug
AND (status = "In Progress" OR assignee IS EMPTY)
AND updated >= -7d
ORDER BY updated DESC

Build this kind of query incrementally in an accessible project: run the project clause first, add type and status logic, then add the date restriction and sort. After each addition, inspect whether the results still match the question. A zero-result query may be correct, but it can also signal a status name your workflow does not use, an overly narrow time window, or issues you cannot browse.

Once the results are trustworthy, you can save the JQL search as a filter using the approach from the previous lesson. Give it a name that states its scope and purpose. If an existing shared filter is already used by others, remember that editing its JQL changes the results they receive too; save a separate filter when you are asking a different question.

Conclusion

JQL starts with field–operator–value clauses. AND narrows a search, OR admits alternatives, and parentheses make their scope explicit. ORDER BY changes presentation rather than membership. Relative dates keep a saved query current, provided you choose the right field and understand whether you mean a calendar boundary or a rolling time window.

Next, you’ll put saved filters to work on a management dashboard. A well-defined JQL filter will give its gadgets a reliable answer to display.