Set Jira due dates with timer events

Set Jira due dates with timer events

Never miss a deadline again - with the aid of BPMN timeout events, deadlines are not just met - they’re mastered!

Learn how to integrate these powerful triggers into your Flower process and transform Jira into a proactive, deadline-mastering machine, that makes your team always stay ahead of the clock.

Drag & drop timer events in BPMN

Timer events can be used to set a due date on a Jira ticket in a graphically comprehensible way. In other words, we always use them in conjunction with a task as boundary events. To do this, simply drag the event symbol onto the desired activity in your process diagram, as shown in the graphic. You can then select the event type using the wrench icon: Timer boundary event (interupting or non-interupting).

Another interesting aspect of this BPMN model is the terminate end event, which sets all open user tasks to resolved as soon as it is reached.

Timers in action

If the process execution now reaches an activity that contains a timer boundary event, the issue property “flowerTimer” and the field “due date” are set on the Jira task, whereby duedate can be changed afterwards. Both values can be used in Jira search (JQL ), e.g. to create a board that monitors all escalated tasks.

• Resolution IS EMPTY AND duedate >= -7d
• Resolution IS EMPTY AND flowerTimer < now()

Setting the clock: Defining timers by providing a date or duration

Timers must be defined by providing either a time date, a time duration (cycle time durations are not supported in Flower):

Time date

A specific point in time defined as ISO 8601 combined date and time representation. It must contain timezone information, either Z for UTC or a zone offset. Optionally, it can contain a zone id.

• 2019-10-01T12:00:00Z - UTC time
• 2019-10-02T08:09:40+02:00 - UTC plus two hours zone offset
• 2019-10-02T08:09:40+02:00[Europe/Berlin] - UTC plus two hours zone offset at Berlin

Time duration

A duration is defined as a ISO 8601 durations format , which defines the amount of intervening time in a time interval and are represented by the format P(n)Y(n)M(n)DT(n)H(n)M(n)S. Note that the n is replaced by the value for each of the date and time elements that follow the n.

The capital letters P, Y, M, W, D, T, H, M, and S are designators for each of the date and time elements and are not replaced, but can be omitted.

• P is the duration designator (for period) placed at the start of the duration representation.
• Y is the year designator that follows the value for the number of years.
• M is the month designator that follows the value for the number of months.
• W is the week designator that follows the value for the number of weeks.
• D is the day designator that follows the value for the number of days.
• T is the time designator that precedes the time components of the representation.
• H is the hour designator that follows the value for the number of hours.
• M is the minute designator that follows the value for the number of minutes.
• S is the second designator that follows the value for the number of seconds.

Examples:

• P14D - 14 days
• P14DT1H30M - 14 days, 1 hour and 30 minutes
• P3Y6M4D - 3 years, 6 months, 4 days

Repeating time cycle intervals

A time interval is defined as a ISO 8601 repeating interval format , which is te same as a duration (see above) with an trailing expressions, that defines the number (n) of repetitions ‘Rn/’

Examples

• R3/P1W - 3 repetitions once a week
• R-1/P1W - indefinite number of repetitions once a week
• R0/P1W - no repetition, timeout after 3 days
• R1/P3D - no repetition, timeout after 3 days

Repetitions make sense especially in combination with throw events, which e.g. call a Jira automation to send a reminder email every 5 days. Of course, user task activities can also be on the timeout path, but these are not recreated each time, but simply reopened if they have been completed in the meantime.

The impact of interrupting vs. non-interrupting Timer Events

There are two different types of timer event that influence the behaviour of the process execution on the associated task. You can determine whether the timeout should interrupt the regular process flow (interupting) or not (non-interupting).

Interupting

In the case of an interrupting timeout, the process is not continued if the task is resolved at some point after the due date. This makes sense if the process is only to be executed in the escalation swimlane after the timeout.

Non-interupting

Whereas the non-interrupting timeout splits the process execution and continues to follow both flows. For example, if the escalation swimlane intervenes communicatively in the process, but then the original task continues to be processed regularly.

Timer Job

Timeout events in Flower allow the process to continue automatically when a defined due date is reached. However, there is also the possibility to manually trigger a job that identifies activities where the due date has already been exceeded and progresses the process accordingly.

Automatic Trigger of Timeout Job

The Flower BPM Engine automatically triggers the Timeout Job once per day at 00:00 UTC. The job processes all elements that match the following Jira Query:

flowerType = Activity AND Resolution IS EMPTY AND flowerTimer IS NOT EMPTY AND (duedate <= endOfDay() OR duedate IS EMPTY AND flowerTimer <= endOfDay())

This ensures that:

• All open activities (Resolution IS EMPTY) with a defined timeout (flowerTimer IS NOT EMPTY) are considered.
• The job triggers when the due date has passed (duedate <= endOfDay()).
• If no due date is set, the job uses the flowerTimer field (flowerTimer <= endOfDay()) as a fallback.

Why does Flower use flowerTimer?

In Jira, it is possible to define issue types that do not have a duedate field or where duedate is not available on the edit screen. In such cases, Flower cannot use duedate for timeout calculations, so we fall back to flowerTimer.

Once a timeout is processed, flowerTimer is automatically set to null, ensuring that the job does not repeatedly trigger the same timeout event.

This automatic execution guarantees that timeout events are processed reliably, even if the standard duedate field is unavailable.

Manually Triggering the Timeout Job

In the Flower Settings, you can manually start the Timeout Job. This job scans for all process activities where the due date has already passed and immediately triggers the corresponding timeout events.

This functionality is especially useful for testing processes during development. For example:

• You define a timeout with the expression P3D, meaning the process will continue in three days.
• Instead of waiting three days, you can:
  1. Let Flower create the Jira task.
  2. Manually change the due date of the Jira task to today.
  3. Run the Timeout Job manually.
  4. The process will now follow the timeout path immediately.

This allows you to simulate and verify timeout behavior without waiting for the actual time to pass.

Timer Filter & Jira Board Integration

The “Timer Filter” button provides quick access to a Jira board that lists all upcoming Jira tasks with an overdue due date. These tasks are the ones that will receive a timeout event the next time the job runs.

The same filter logic used in the Jira board is applied in the Timeout Job. This ensures consistency between manual reviews in Jira and the automated timeout handling in Flower.

By leveraging this manual execution, you gain more control over testing and process debugging, ensuring that timeout handling works as expected before deploying the workflow in production.

Automatically triger

Learn more

• ISO 8601 durations format 
• Due date in Jira