One JQL Filter Consistent Triage Across Jira Boards and Automation

Why one saved filter stops triage drift

JQL (Jira Query Language) is the language Jira uses to select issues by project status priority assignee labels and dates. It powers filters boards dashboard gadgets filter subscriptions and automation conditions. Because the same JQL string works in all of those places a saved filter becomes a single definition of what needs triage that every consumer can reference.

When triage logic lives in three places a board query a gadget and a rule each copy can silently drift. A priority change a status rename or a label addition requires edits in three spots and teams often forget one. The result the board shows 12 issues needing attention the dashboard shows 9 and the automation rule pings people about tickets the board never surfaces.

Writing the query once and saving it as a shared filter means every consumer the board the gadget the rule reads the same definition. Edit the filter once and all consumers update immediately.

The worked example daily high-priority unassigned sweep

Suppose a team wants a daily sweep that catches high-priority issues unassigned for more than three days. The JQL:

project = ENG AND status = Open AND priority = High AND assignee is EMPTY AND created <= -3d ORDER BY created ASC

Two things make this filter stable. First, created <= -3d is a relative date created at least three days ago so the filter never needs a hard-coded date edited. JQL also offers functions like startOfDay() and endOfWeek() if calendar-aligned windows are preferred. Second, assignee is EMPTY targets the exact gap triage exists to close.

Save this as a shared filter (Issue search Save as set permissions so the team can view it). Then wire it into three places:

• Board or saved-filter gadget the team sees the live triage queue.
• Filter subscription the results land in inboxes on a schedule for people dont live in Jira.
• Automation rule a scheduled trigger runs the same JQL then acts on the matches.

The automation rule scheduled trigger JQL condition action

In Jira Cloud (and Automation for Jira on Data Center) rules follow a trigger condition action shape. For the sweep:

1. Trigger Scheduled once per day with Run a JQL search and execute actions for each issue in the query enabled. Paste the same JQL or reference the saved filter with filter = ENG triage sweep if the edition supports it.
2. Action 1 Assign issue to the current on-call engineer or a round-robin group available as an assignment option in Cloud.
3. Action 2 Add a comment noting the issue was auto-assigned by the triage sweep so the assignee has context rather than a mysterious notification.

Before enabling the schedule use the rules manual run or audit log to confirm the JQL matched the expected issues and the actions fired. The audit log is ground truth it shows the trigger the matched issue set and any per-issue failures.

Trade-offs and limits worth knowing up front

Usage limits are a design constraint. Jira Cloud automation allowances vary by plan tier and each issue a scheduled rule acts on can count against the monthly limit. A daily rule over a large backlog can burn through a Free or Standard plan allowance quickly. Check your plans current automation limits page before committing to a high-frequency schedule daily may need to become twice-weekly.

The rule actor needs permissions. Automation rules execute as a rule actor (by default the Automation app user or a user you choose). If that actor lacks permission to transition assign or comment in the target project the rule can silently skip issues the audit log will show it but only if you look. Test against a permission-restricted project if your instance uses them.

JQL is not SQL. There are no joins across issue sets and no aggregation. If you need counts-by-assignee trends or cross-project rollups JQL alone wont get you there thats an export or marketplace-app problem. JQL selects issues it does not analyze them.

Syntax varies by edition. Cloud and Data Center do not support identical operators and functions in every case so verify the exact JQL in your own instances issue search before wiring it into a rule.

Verify before you trust

1. Run the JQL in issue search in a test project and eyeball the result set are the right issues in and the wrong ones out?
2. Save and share the filter then confirm the board gadget and the automation rule return the same count.
3. Trigger the rule manually and read the audit log entry check the matched issues and that both actions succeeded per issue.
4. After the first scheduled run re-check the audit log and your automation usage meter.

Start with one filter and one rule. Once the counts agree across board subscription and automation youve got a triage definition the whole team can trust and exactly one place to change it when the definition evolves.