Filter scope changes

When you create or link a Jira issue from a Zendesk ticket, Zendesk automatically adds the jira_escalated tag to the ticket and the same label to the linked Jira issue.

For example, a ticket might be linked to an incident created to investigate an error and to a story created to deliver the fix in a future release.

You can use the jira_escalated label as the report source to display the complete issue hierarchy, including the incident and the story. To do so, follow these steps.

1. Open the report sidebar and select the Source tab.

2. Expand the Base Source section and select JQL / Search results as the source type.

3. In the JQL Request field, enter: labels = jira_escalated

4. Expand the Related Issues section and select Parent issues, Child issues, and Siblings, to extend the report source.

5. (Optional) Use the JQL Post Filter to limit the report to a specific project, fix version, or Zendesk ticket ID.

6. (Optional) Expand the Custom hierarchy section and select Use default settings, or configure a custom hierarchy.

For example, if you use Blocks to define the relationship between Initiatives and Epics, enabling the custom hierarchy lets you display all Epics that must be completed under an Initiative before the related Zendesk ticket can be resolved.

7. Click Apply.

8. (Optional) Open Columns and select Zendesk ticket ID. This column lets you identify which Jira issues are blocking specific Zendesk tickets.

9. (Optional) To include all related issues in a specific fix version, open Columns and select Fix Version/s. This column lets you identify the fix version, such as Version 1.0, for all related issues. Then update the JQL / Search results query to: labels = jira_escalated or fixVersion = "Version 1.0".

Unless you know the kick-off date and time and release date and time for fix version, you can rely on the following queries to track changes during 2 week sprints. You can change the search interval if you are working with 1 week or 3 week sprints, by adjusting the increments in the functions.

parentProject = ssp and (created >= startOfWeek(-2w) or created < endOfWeek(-1w))

(cloud only) parentProject = ssp is used in Jira to find all child issues (such as subtasks) whose parent issue belongs to the project with the key "SSP

parent is not empty and (created >= startOfWeek(-2w) and created < endOfWeek(-1w))

• If you release a version every 2-week sprint and want to know if any issues added or postponed to another version

• Fix version changed 2 weeks ago: When you are using 2-week sprints, you can see any issues were added to a fix version during this sprint. For example, while working on a story during a sprint, a previously not estimated task or a bug is created in a version and moved to a future version, due to its complexity or required level of effort, before the end of the sprint.

fixVersion CHANGED during (startOfWeek(-2w), endOfWeek(-1w))

The query that finds issues whose fixVersion field changed during the time range from the start of two weeks ago to the end of last week.

worklogDate >= startofweek(-2w) and worklogDate < endOfWeek(-1w)

This Jira Query Language (JQL) expression filters worklogs from the entirety of the previous-to-last week (two weeks ago), spanning from the start of that week through the end of it.

• If you’re working with a single active version, you can use the earliestunreleased() function to track changes to it, such as issues removed or add from the active version to other newer versions, which are not yet started.
  The assumption is that the active version is fully scoped before being started, in comparison subsequent versions that are not fully scoped and undergo changes. That is why this function is useful tracking changes.

• Unreleased version excluding the active version, which is assumed to the oldest. It is named the earliest in the function, since it considered to be the one created earlier based on all of other unreleased versions, based on the released sorted in the project.

fixversion in unreleasedVersions() AND fixversion != earliestUnreleasedVersion()

fixVersion CHANGED TO earliestUnreleasedVersion()

• find issues that transitioned into the earliest unreleased version from absolutely any state (whether it had a version before or was completely blank), you only need to specify the destination state. Omitting the FROM predicate tells Jira to look for any historical change event where the final value became earliestUnreleasedVersion(), regardless of what the field held previously.

Because it evaluates the function based on today's state, the historical results will shift over time.

• Scenario: Imagine "Version 2.5" is your current unreleased version. Your query will correctly find any issue that was changed to "Version 2.5".

• The Shift: Once you release "Version 2.5", the earliestUnreleasedVersion() automatically shifts to "Version 2.6".

• The Result: The exact same saved filter will suddenly stop showing the history for "Version 2.5" and will only show issues that changed to "Version 2.6".

fixVersion CHANGED to earliestunreleasedversion() DURING (startofweek(-2w), endOfWeek(-1w))
AND
((worklogDate >= startofweek(-2w) AND worklogDate <= endOfWeek(-1w)) 
OR worklogdate is empty)

It finds issues where the fixVersion was changed to today's earliest unreleased version during a two-week window that occurred 1 to 2 weeks ago, filtered by work logged during that same timeframe.

Jira evaluates earliestUnreleasedVersion() based on today's date (August 2026). Let's assume today's earliest unreleased version is "v3.0".

• Jira converts this clause to: fixVersion CHANGED TO "v3.0" DURING (startofweek(-2w), endOfWeek(-1w))

• What it looks for: It searches your history to see if an issue was moved into "v3.0" during that specific two-week window in the past.

The DURING clause looks at a strict historical window:

• startofweek(-2w): The start of the week, two weeks ago.

• endOfWeek(-1w): The end of last week.

• The Result: It strictly filters for issues whose version assignment happened inside that 14-day window.

This clause filters the resulting issues based on their time-tracking history:

• It includes issues that had work logged on them during that same 14-day window.

• It also includes issues that have never had any work logged on them at all (worklogdate is empty).

System fields

System fields such as Created, Updated, and Resolved automatically display dates and times in the time zone configured in your Atlassian account preferences.

For example, if you change your account time zone from Montreal (EDT, UTC-4) to Jakarta (WIB, UTC+7), the displayed values for these fields change to match your selected time zone. The underlying timestamps remain unchanged.

Functions

Calendar functions, such as startOfWeek(), endOfWeek(), and startOfYear(), are evaluated using the time zone configured in your Atlassian account. You cannot specify a different time zone for an individual JQL query, saved filter, or Issue Navigator search.

For example, if your account time zone is set to Montreal (EDT, UTC-4), the startOfWeek() function returns Sunday at 00:00 EDT, based on Jira's default week settings.

Similarly, if your account time zone is set to Montreal (EDT, UTC-4), the startOfYear() function returns January 1 at 00:00 EDT.

Fields

The Due date field stores only a calendar date (YYYY-MM-DD). It does not store a time or time zone, so its value does not change when users view the issue from different time zones.

duedate >= startOfWeek()

For example, for a user in Montreal, this query returns issues whose due date falls on or after Sunday at 00:00 EDT of the current week, based on Jira's default week settings.

Date stings

When you use a date string without a time component, Jira assumes the time is 00:00 (midnight) in your account's time zone.

created >= "2026-01-01"

For example, for a user in Montreal (EDT, UTC-4), this query returns issues created on or after January 1, 2026, at 00:00 EDT.

created >= "2026-01-01 23:59"

For a user in Montreal (EDT, UTC-4), this query returns issues created on or after January 1, 2026, at 23:59 EDT, using the YYYY-MM-DD HH:mm format.

duedate >= "2026-01-01"

This query returns issues whose Due date is January 1, 2026, or later. Because Due date is a date-only field, Jira ignores hours and minutes.

Increments

Relative increments such as -1d, -1w, and -1M represent calendar-based periods rather than exact elapsed time. For -1d, Jira calculates the date from the start of the day (00:00 or midnight) in the Jira server time zone, unless you specify an exact time.

updated >= -1d

For a user in Montreal, this query returns issues updated since 00:00 EDT yesterday. The result is the same regardless of when the user searchs in the Issue Navigator or open a saved filter.

Time-based values

Time-based values such as 24h represent exact elapsed time. Jira calculates an exact rolling time window based on the time when the query is executed.

updated >= -24h

This query returns issues updated during the previous 24 hours from the exact time the query is executed. For example, if a user in Montreal runs the query at 2:15 PM EDT, Jira returns issues updated since 2:15 PM EDT on the previous day.

No. JQL does not natively support querying sprint-specific changes, such as:

• Sprint start and end dates.

• Issues added to or removed from a sprint after it has started.

• Changes to the Sprint field.

• Issues modified while a sprint is in progress.

While JQL can search the current value of the Sprint field (for example, sprint in openSprints()), it cannot query historical sprint data, such as changes to sprint membership or other sprint-related events

No. JQL does not natively support querying the Start Date or Release Date of a version. These values cannot be used directly in JQL searches.

Yes. You can use JQL to pull issues based on the interval when worklogs were entered by using the following queries. However, there are several scenarios we need to address.

Time can be logged for an issue, before this issue transferred to another version. As a result, when

worklogDate > "2010-12-12" and worklogDate < "2010-12-12 14:00"

The above query results in an error within the Issue navigator

You can track issues added to an active sprint by using a custom field together with a Jira automation.

The automation below is triggered when a user logs work on an issue that is not assigned to the active sprint. It then adds the issue to the active sprint and marks it using a custom field. This allows you to identify issues that were added after the sprint began.

This solution is intended for a single active sprint on a single board. If you use multiple boards or run several active sprints simultaneously, create a separate automation for each board.

Create custom field and automation

As a Jira admin, complete the following steps:

1. Open Settings (gear icon) in the Jira navigation bar.

2. Select Work items.

3. In the sidebar, select Fields, then click Create new field.

4. Set Field type to Select List (single choice).

5. Name the field Addition to Sprint.

6. Click Add option and enter a value, such as Added or ✓.

7. Click Create.

Next, create the automation:

1. Open Settings (gear icon) in the Jira navigation bar.

2. Select System.

3. Select Global automation.

4. Click Create flow, then select Create from scratch.

5. Add the Work logged trigger.

6. Add a JQL condition with the following query:
   (sprint NOT IN (openSprints()) OR sprint IS EMPTY)

This query matches issues that are either not assigned to an active sprint or are not assigned to any sprint.

7. Add an Edit work item action.

8. Update the following fields (shown in the screenshot below):
   Sprint: Select the active sprint.
   Addition to Sprint: Select the value you created earlier.

9. Save and enable the automation.

Find all sprint additions

Use the following JQL query:

"Addition to Sprint[Dropdown]" IS NOT EMPTY AND sprint IN openSprints()

This query returns all issues in the active sprint that have been marked as additions after the sprint started.

Clear the custom field before the next sprint

If you do not clear the custom field, issues will continue to appear as sprint additions in future sprints. Create another automation to clear the field when a new sprint starts.

As a Jira admin:

1. Open Settings (gear icon) in the Jira navigation bar.

2. Select System.

3. Select Global automation.

4. Click Create flow, then select Create from scratch.

5. Add the Sprint started trigger.

6. Select the board.

7. Add a Branch rule for Issues in the sprint.

8. Add a JQL condition:

"Addition to Sprint[Dropdown]" IS NOT EMPTY AND statusCategory != Done

This query matches issues that were previously marked as sprint additions and are not yet completed.

8. Add an Edit work item action.

9. Clear the Addition to Sprint field by leaving it empty (shown in the screenshot below).

10. Save and enable the automation.

Keep a history of sprint additions

If you want to keep a historical record of issues added after a sprint started, export the results of the following query before starting the next sprint:

"Addition to Sprint[Dropdown]" IS NOT EMPTY AND statusCategory != Done

Before the next sprint begins, export the query results from the Issue Navigator to a CSV file, or create a Pivot Report for the query and export it to Excel, as shown in the following screenshot.

You can change the order of Fix Version (releases) values that are being referenced by functions, by modifying their order in Jira configuration.

For example,

Status

To modify the sequence in which Status labels appear along the horizontal X-axis of a Chart tab type, refer to the separate article provided by Atlassian.

Fix Version

To align Fix Version or release labels along the horizontal X-axis of a chart, follow these steps:

1. In the Jira sidebar, open Spaces.

2. Click the actions (•••) menu for the space used as the report source.

3. Click Space settings.

4. Click Versions in the sidebar.

5. On the Releases page, select all statuses from the dropdown next to the search box.

6. Click the Releases column until the arrow points upward, as shown in the screenshot below. This order determines how Fix Version values appear in the chart.

7. Review and update release names if necessary. When sorted, a release named 1A appears before A1, and A 1 (with a space) appears before A1 (without a space).

• Go to Releases: Open your project space in Jira and click on Releases (or Versions) in the left-hand project menu.

• Drag and Drop: Click and hold a release row, then drag it up or down. Place the earliest (oldest) release at the top and later releases further down.
  The earliestunreleastedversion() function uses the order of the "Versions" in the list NOT the dates associated with them.

  • Ensure to see the order Descending. The first version appearing will be used in the earliestunreleastedversion() function, where the oldest or next version to be release.

  • You query issues in my NEXT release. When not using sorting, the version at the bottom of the list is considered the “earliest.”

• The latestreleasedversion() function: ‘Version 2’ is the latest release because it is ABOVE Version 1 in the list (not because it has a later release date).

• Impact: This manual sequence defines the chronological order used across Jira for version lists, release reports, and search sorting

The Updated and Resolved fields displayed in the report use your desktop operating system's time zone. In contrast, the same fields in the Jira issue view use your Jira account time zone.

For example, a user resolves an issue while working in Jakarta. At that time, their desktop time zone is set to Jakarta. Later, the user returns to Montreal and changes their desktop time zone to Montreal, while keeping their Jira account time zone set to Montreal throughout the trip.

As a result, the Updated and Resolved values in the report differ from the values shown in the Jira issue view because the report uses the current desktop time zone, while Jira uses the account time zone.