Automation recipes

Quartz has no Automation trigger of its own. The bridge is a real Jira field. Once an SLA timer value is in one, Jira Automation watches it like any other field, JQL searches it, boards and filters sort by it, and dashboards count it.

Before you start

1. On SLA Fields, create an SLA field for the value the recipe needs (Status, Time remaining, Paused since, Percent of goal used, and so on) and point it at a Jira field. The field does not have to be on the request's screen for a rule to read it, where Jira lets Quartz write past the edit screen; the field's page says whether Jira takes the values. See SLA Fields.
2. Keep Field updates on As requests change, so the field changes within about a minute of a change on the request, and close to the moment a value changes with time.
3. For Time remaining and the other values that change with time, Automatic steps make a search on a threshold turn true close to the moment the SLA timer reaches it.

Quartz's search names (such as quartzBreachedCount) and Quartz's own JQL function, quartzSla(), need no setup at all and work in a rule that runs a JQL search, such as a scheduled rule. A rule's JQL condition is different: there quartzSla() matches nothing and shows no error, even though the condition's own check of the query says it finds requests (measured on a test site). In a JQL condition, use the SLA's exact token, which SLA Fields writes for you (see Check an SLA timer in a rule's JQL condition). The four built-in Quartz fields are read only: for a rule that acts on a change, use an SLA field instead.

The recipes below use the field names SLA Fields suggests when it creates the field for you ("SLA status", "SLA time remaining (min)", "SLA paused since", "SLA percent used"). If your field has another name, use yours. The SLA Fields page lists the same recipes, with Copy the search, and says when the field a recipe names does not exist yet.

Tell the team lead when an SLA timer breaches

Jira Automation watches the field, not Quartz. The field changes on the next update, and the rule runs from there.

• When: Field value changed · SLA status
• If: SLA status contains Breached
• Then: Add a comment, or send a Slack message from your own Jira rule

A queue of the requests at risk

A Jira filter or a board queue, refreshed as the field is.

"SLA status" ~ "At risk" AND resolution IS EMPTY ORDER BY priority DESC

Warn half an hour before a deadline

A scheduled rule on a JQL search. Minutes are working minutes, so it never fires overnight on a business-hours calendar.

• When: Scheduled, every 15 minutes, with a JQL search
• Then: Add the label deadline-soon, or e-mail the assignee, from your own Jira rule

"SLA time remaining (min)" > 0 AND "SLA time remaining (min)" <= 30 AND resolution IS EMPTY

Quartz's own alert rules can also do this without a Jira field: Before the goal on an alert rule acts a set time before the deadline. See Settings and alert rules.

Leave paused requests alone

A paused SLA timer is waiting on somebody else. The text ends in ", paused", so one clause takes them out of any rule.

NOT ("SLA status" ~ "paused")

Find everything that ever breached

Ever breached finds the requests whose SLA timer has breached, whether it is still running or has stopped, so a monthly review can list the requests resolved last month that breached. It reads the cycles the SLA counts: a breach before a reset, or in an earlier cycle of an SLA that counts the last cycle only, is not kept. The search finds only requests that carry Quartz's search property. A request that was already resolved when Quartz 5 started reading your site's changes carries none, and Update fields now does not add it, so the first monthly reviews after an install or an upgrade leave those requests out: for those months, use Reports. This one needs no field:

key in quartzSla("First response", "ever breached") AND resolved >= startOfMonth(-1) AND resolved < startOfMonth()

SLA Fields writes it for the SLA you pick, and also in the exact token form, which keeps working after the SLA is renamed (quartzSlaTokens ~ "qz4817e3s7").

Check an SLA timer in a rule's JQL condition

A rule can check an SLA timer before it acts. In a JQL condition quartzSla() matches nothing (above), so the condition uses the exact token, which stays the same when the SLA is renamed.

• When: Any trigger, such as a comment added to the request
• If: JQL condition, with the query below
• Then: Add a comment, or tell the team lead, from your own Jira rule

quartzSlaTokens ~ "qz4817e3s1"

The token names one SLA in one state on your site. On SLA Fields, under Automation and JQL, pick the SLA and the state and copy the token's row, or copy this recipe there.

Requests waiting on the customer

Paused since is the instant the SLA timer was paused. A queue sorted by it puts the request that has been waiting longest at the top. A paused SLA timer on a working-time goal has no deadline while it waits, so a Deadline field is empty and a search on it ("SLA deadline" < now()) never lists a request only because it is paused.

"SLA paused since" IS NOT EMPTY AND resolution IS EMPTY ORDER BY "SLA paused since" ASC

Which requests are more than 80 percent through their goal

Percent of goal used is a number, so one comparison finds them and a dashboard can chart how many there are.

• When: Scheduled, every 15 minutes, with a JQL search
• Then: Add the label watch-this, or tell the team lead, from your own Jira rule

"SLA percent used" >= 80 AND "SLA percent used" < 100 AND resolution IS EMPTY

Searches with no setup

key not in quartzSla(...) on its own finds every request where that SLA timer is not in that state, so it also finds every request the SLA does not measure, requests Quartz measures nothing on among them. That is why the row above names the SLA once more with key in quartzSla("Time to resolution").

These searches work in Jira's search, saved filters, queues, boards and the JQL search of a scheduled rule (each checked on a test site). In a rule's JQL condition, use the token form (above). Jira shows a mistake in a quartzSla() query, such as a state it does not know, on its search page; a rule or a script with the same mistake can find no requests and show no error, so try a query there first.

quartzSla() looks the SLA up by its name inside Quartz, so a rule or filter written on a name needs the new name after the SLA is renamed. The exact token form never changes: SLA Fields writes it for the SLA and state you pick (quartzSlaTokens ~ "qz4817e3s1"). See SLA Fields.

Slack and Microsoft Teams

Quartz sends email through Jira and writes notes and replies on requests. It does not post to Slack or Microsoft Teams itself. A Jira Automation rule that watches a Quartz SLA field can post there, as in the first recipe.

After the upgrade to Quartz 5

The built-in fields and every Status SLA field write Quartz's words: Breached, Critical, At risk, On track, Met, Measuring, Measured and No date set, with ", paused" on a paused SLA timer. A rule or filter written on "Breached (late)" or "No target" needs a look. Values change as Quartz rewrites them in the background.

Something unclear or wrong on this page? Contact support.