Writing and running rules

Open Recurring work items in the project menu. The sections below follow the editor's own headings, so nothing here has to be translated back to the screen in front of you.

The rules table

Four columns: Rule, Schedule, Next run and Status. Status is active, paused or completed, with a second failing lozenge when the daily health check has seen this rule fail repeatedly.

Each row offers:

History — every past run and the next few. See reading the run history.
Next runs — the upcoming occurrences on their own.
Run now — create the issue immediately. Offered only on an active rule; see Run now.
Edit, Duplicate, Pause / Resume, Delete.

History and Next runs are available to anyone who can see the project. The rest appear only if you may schedule here; if you cannot, the page says so rather than hiding the table.

The table shows 50 rules at a time, with Load more rules beneath it.

Pausing is not deleting, and resuming does not owe you a backlog. A rule paused for a month recomputes its next run from the moment you resume it — it does not wake up owing four weeks of issues.

Rule name, summary and issue type

Rule name is how you find the rule; it is also what the automatic label on every created issue is named after, so every issue a rule has ever made stays findable.

Issue summary is the title of the issue itself. Left empty, the rule name is used — which is fine until you have twelve identical rows in a backlog, so this is the field most worth putting a token in.

Issue type is read from the project. If you pick a subtask type here, the rule must be given a parent issue under What the issue says, and the Subtasks section disappears — a subtask cannot have subtasks of its own.

What the issue says

Description — the issue body. The same tokens work here, and a blank line starts a new paragraph.
Reporter — defaults to whoever created the rule. Worth leaving set: with no reporter the issues come from the app itself, which reads as spam in a backlog.
Assignee — optional. Left empty, the issue is unassigned.
Priority — offers The project default as an explicit choice, so "I did not set one" and "I chose Medium" stay distinguishable.
Parent issue — a key such as KAN-12. Required when the issue type is a subtask, optional otherwise.
Labels — separated by commas or spaces. Every issue also gets a label naming this rule, whether or not you add any of your own.
Other fields — see custom fields.

Due date

A due date is stored as an expression, never as a fixed date — a literal date would put the same due date on every issue the rule made for years. The dropdown writes the expression for you:

No due date Nothing is set.
The day it is created Due on the day of the run.
1 day after
3 days after
1 week after
2 weeks after
1 month after
An expression I write myself Reveals a field for any token expression. It is counted from each run, not from today, and it has to end in .date.

If the rule moves off a non-working day, the due date moves with it.

When it repeats

The rule editor's schedule section: Repeats set to Every week, an interval, a weekday multi-select, a time and IANA time zone, a start date, the four non-working-day options, and the live Next runs list beneath. — Everything on this page in one screen. The **Next runs** list at the bottom updates as you type, so the schedule can be checked before the rule is saved.

Four patterns:

Every day
Every week Choose one or more weekdays; the rule fires on each of them.
Every month, on a date Choose a day of the month, 1 to 31.
Every month, on a weekday Choose an ordinal and a weekday — the second Tuesday, the last Friday.

Every N sets the interval, from 1 to 366, and counts in the pattern's own unit: days, weeks or months.

The ordinals available to Every month, on a weekday are:

First
Second
Third
Fourth
Last Genuinely the last one in the month, so it lands on the fourth or the fifth depending on the month.

Months without the day you chose

Choosing a day above 28 raises a question February will ask every year, so the editor asks it straight away — In months without that day:

Use the last day of that month The 31st becomes the 28th, or the 30th, and the run is recorded as moved to month end.
Skip that month entirely No issue that month at all.

Time, time zone and start date

At is a wall-clock time, and Time zone is a real IANA zone — so a rule set for 09:00 Europe/London stays at 09:00 through the clock change rather than drifting to 10:00. The zone field is searchable and accepts any zone the runtime knows, not just the ones listed.

Runs happen within about five minutes of the time you choose. The scheduler wakes every 5 minutes, so 09:00 means 09:00–09:05 and not 09:00:00. Nothing is ever missed by it, only slightly late.

Starts is where counting begins — "every 2 weeks" means every second week from this date, not from today.

If it falls on a non-working day

Which days those are is the project's setting, not this rule's; the editor prints the project's answer under the control rather than offering a second one that could disagree with it. What this rule does about them:

Run on the day it falls on, working day or not The default. Nothing moves, and the working-day calendar is ignored entirely.
Move it to the next working day A Saturday run becomes Monday. The due date moves with it.
Move it to the previous working day A Saturday run becomes Friday — the usual choice for anything that has to be done before a period starts.
Skip it entirely — create nothing that time The occurrence is recorded as skipped and the schedule carries on to the next one.

A rule that has never been told otherwise uses Run on the day it falls on, working day or not.

Next runs

The panel beside the schedule lists the next 5 occurrences, live, as you type. It is computed by the same code that executes the runs, so it cannot promise something the scheduler would not do — including the moves: a date shown here as moved off a weekend really will be.

When it stops

Never It runs until you pause or delete it.
After a number of runs The table shows the count so far. A manual run counts towards it.
On a date The last run is on or before that date. It must be after the start date.

A rule that has reached its end shows completed and stops on its own. It is not deleted, and its history stays readable.

If a run is missed

A run can be missed while the app is uninstalled, unlicensed, or down. This is what happens when it comes back:

Create one issue, for the most recent missed run The default, and almost always the right answer: you get the ticket, once, without a Monday morning of duplicates.
Create nothing, and resume at the next run For anything where a late ticket is worse than no ticket.
Create one issue for every missed run For rules where each occurrence is a distinct piece of work that still needs doing.

The default is Create one issue, for the most recent missed run.

If the previous issue is still open

Whether the next run creates its issue while the last one this rule created is still open.

Create it anyway The default. Issues accumulate whether or not anyone closes them.
Create nothing until the previous issue is closed Stops a neglected recurring task turning into forty open tickets.

The default is Create it anyway. A run held back this way appears in the history as skipped and names the issue that held it up. The schedule itself does not move, so the run after it is still due at its usual time.

Subtasks

Subtasks are created under each issue the rule makes, in the order you list them. They share the issue's labels, priority, reporter and due date, so those are set once, above.

Each subtask has its own summary, description, issue type and assignee. A rule may create at most 10 subtasks per run.

Two states the editor will tell you about rather than leaving you to guess: a project with no subtask issue type cannot have any (nothing can be added, and it says so), and a rule whose own issue type is a subtask has this section replaced by an explanation.

Other fields

The editor reads the project's create screen for the chosen issue type and offers what it finds — text, numbers, dates, users, and single or multiple choice. Required fields with no value are called out before you can save.

Two things worth knowing:

Field types the editor cannot render yet are listed by name rather than hidden, so you know what is not being set.
A field already holding a value this editor cannot show is kept exactly as it is when you save. Editing a rule never silently empties a field it does not understand.

Run now

Run now creates the issue immediately, without waiting for the schedule. The confirmation says what it is about to do before it does it:

It creates an issue straight away, from the template on this rule.
The next scheduled run does not move. This is an extra run, not an early one.
It counts as a run: it appears in the run history and in the completed-run count.

On a rule that stops after a number of runs, the third sentence instead names the limit and how many have run so far — a manual run brings it one closer to stopping. And on a rule set to wait for the previous issue to be closed, a fourth sentence warns that if the previous issue is still open, nothing will be created; the history will say which issue.

Importing from Jira Automation

If you already schedule issues with Jira Automation, the rules can be brought across.

In Jira, open Project settings → Automation, then the ⋯ menu → Export rules.
On the project's Recurring work items page, choose Import from Automation and paste the whole downloaded file.
Press Check the file. Nothing is created yet. You get a per-rule report: which will import, which will not and why, and any notes about what changed in translation.
Press Import.

Imported rules arrive switched off. Nothing fires until you read a rule and switch it on — which is the point of importing in two steps rather than one. Check the reporter, the schedule's time zone and any translated notes first.

What does not carry over, because it has no equivalent here: JQL conditions, smart values that refer to a triggering issue (there is no triggering issue — the schedule is the trigger), and branches or actions other than creating an issue. Each is named against the rule it came from rather than dropped silently.