
Set Jira Due Dates with Timer Events
Escalate and Remind with Timeout Boundary Events
Set Jira Due Dates with Timer Events
Timer events make deadlines part of your process. You attach a timer to an activity, and Flower sets the due date on the Jira work item. When the deadline passes, the process continues on a separate path, for example to escalate the work item or to send a reminder.

Add a Timer Boundary Event
In Flower, a timer is always a boundary event attached to an activity:
- Drag the event symbol onto the activity in your process diagram, as shown in the graphic.
- Click the wrench icon and select the event type Timer boundary event, either interrupting or non-interrupting (see Interrupting vs. Non-Interrupting Timer Events).
- Define when the timer fires (see Define the Timer).
- Connect the boundary event to the activities of the timeout path, for example in an escalation swimlane.
Each activity can only have one timer boundary event.
The model in the graphic ends with a terminate end event. As soon as it is reached, it closes all open work items. Learn more in Terminate vs. Regular End Events.
What Happens at Runtime
When the process reaches an activity with a timer boundary event, Flower sets two values on the Jira work item:
- The due date field. You can change it later in Jira.
- The work item property
flowerTimer, which Flower uses to control the timeout.
You can use both in JQL, for example to build a board that monitors work items with a deadline:
| JQL | Finds |
|---|---|
Resolution IS EMPTY AND duedate >= -7d | Open work items whose due date is not older than seven days |
Resolution IS EMPTY AND flowerTimer < now() | Open work items whose timeout date has passed and has not been processed yet |
Flower can only set the due date if the Due date field is on the edit screen of the work type. This is the default in most cases. Ask your Jira administrator to check it if necessary.
Without the due date, the timeout still works, because Flower then uses flowerTimer (see Timer Job).
Define the Timer
A timer is defined by one of these:
- a time date: a fixed point in time
- a time duration: how long to wait
- a repeating interval: how long to wait, and how often to repeat
Time Date
A time date is a combined date and time in the ISO 8601 format. It must contain time zone information: Z for UTC or a zone offset. Optionally, it can contain a zone ID.
2019-10-01T12:00:00Z: UTC time2019-10-02T08:09:40+02:00: UTC plus two hours2019-10-02T08:09:40+02:00[Europe/Berlin]: UTC plus two hours, Berlin
Time Duration
A time duration is defined in the ISO 8601 durations format : P(n)Y(n)M(n)DT(n)H(n)M(n)S.
Replace each n with a number. The letters stay and are designators. You can omit every part you do not need.
| Designator | Meaning |
|---|---|
P | Period: every duration starts with it |
Y | Years |
M | Months (before the T) |
W | Weeks |
D | Days |
T | Separates the date part from the time part |
H | Hours |
M | Minutes (after the T) |
S | Seconds |
Examples:
P14D: 14 daysP14DT1H30M: 14 days, 1 hour, and 30 minutesP3Y6M4D: 3 years, 6 months, and 4 days
Jira only stores a date as the due date, not a time. A duration shorter than one day results in a due date of today, so the timeout is already due.
Use P0D to test the timeout path. The timeout fires with the next timer job run, which you can start manually (see Run the Timer Job Manually).
Repeating Interval
A repeating interval is a duration with a prefix Rn/, where n is the number of repetitions. The format is the ISO 8601 repeating interval .
| Expression | Meaning |
|---|---|
R3/P1W | 3 repetitions, once a week |
R-1/P1W | Indefinite repetitions, once a week |
R1/P3D | 1 repetition, every 3 days |
R0/P1W | No repetition, timeout after one week |
Repetitions are especially useful with throw events, for example to call a Jira automation that sends a reminder email every 5 days (R-1/P5D).
A repeated timeout can also lead to a user task. Flower does not create a new work item each time, but reopens the existing one if it has been completed in the meantime.
Interrupting vs. Non-Interrupting Timer Events
The type of the timer event decides what happens to the regular process flow of the activity:
| Interrupting | Non-interrupting | |
|---|---|---|
| After the timeout | Only the timeout path continues | Both paths continue |
| Resolving the work item later | Does not continue the regular flow | Continues the regular flow |
| Typical use | The process continues only in the escalation swimlane | The escalation swimlane intervenes, while the original work goes on |
You can also attach a non-interrupting timer event to an activity without continuing the process from there (see Regular Second Task in the graphic).
This only sets a due date on the work item, which you then handle directly in Jira.
Timer Job
Timeout events let the process continue automatically when the due date is reached. A timer job does this work: it finds the activities whose timeout is due and continues their processes.
Automatic Run
The Flower engine runs the timer job once a day at 00:00 UTC. It processes all work items that match this query:
flowerType = Activity AND Resolution IS EMPTY AND flowerTimer IS NOT EMPTY AND (duedate <= endOfDay() OR duedate IS EMPTY AND flowerTimer <= endOfDay())This means:
- Only open activities are considered (
Resolution IS EMPTY) that have a timeout (flowerTimer IS NOT EMPTY). - The timeout fires when the due date is today or in the past (
duedate <= endOfDay()). - If a work item has no due date, Flower uses
flowerTimerinstead (flowerTimer <= endOfDay()).
After a timeout has been processed, Flower clears flowerTimer, so the job does not trigger the same timeout again.
Why does Flower use flowerTimer as well?
Some work types have no due date field, or the field is not on the edit screen. Then Flower cannot rely on the due date. flowerTimer makes sure that timeouts work in every case.
Run the Timer Job Manually
On the Timers tab of the Flower Settings, click Run timer job once. The job immediately processes all activities whose timeout is due. Only Jira administrators can run it.

This is useful for testing processes during development. For example, you define a timeout of P3D. Instead of waiting three days:
- Let Flower create the Jira work item.
- Change the due date of the work item to today.
- Run the timer job manually.
- The process follows the timeout path.
If the due date field is not available for this work type, use P0D for your test instead.
Timer Filter
The Timer Filter button on the same tab opens a Jira search with the query above. It shows the work items that the next job run will process. The manual run uses the same query, so what you see in the filter is what Flower processes.
Summary
- A timer boundary event sets a due date on the work item and starts a timeout path when the date passes.
- You define the timer by a date, a duration, or a repeating interval in ISO 8601.
- An interrupting timer continues only on the timeout path, a non-interrupting timer on both paths.
- The timer job runs daily at 00:00 UTC. You can run it manually in the Flower Settings to test your process.
What’s Next?
- Search Flower Data with JQL: Find work items with timers.
- Terminate vs. Regular End Events: Learn how a process ends.
- Due date in Jira : Atlassian’s guide to due dates.
- ISO 8601 durations : The format for time durations.