How Flowable timer events handle deadlines and escalations
A process owner who needs a reminder after three days, an escalation when a task breaches its service level, or a monthly run that must not be lost during a restart is asking for timers that live in the process state, not in a scheduler beside it. In Flowable, the BPMN engine handles this through timer start events, timer intermediate catch events and timer boundary events attached to activities. A timer start event starts new instances on a schedule, an intermediate timer pauses a running instance until a duration or date passes, and a boundary timer watches an activity such as a user task and fires when its time runs out. Because the timer is a job in the database, it survives restarts and can be picked up by any node in a cluster.
The choice between in-process timers and an application-side scheduler is mostly about where the state should live. Use a Flowable timer when the deadline belongs to a specific process instance, when the next step depends on what happened in the meantime, or when you need the audit trail of the process history to show that a reminder or escalation fired. The async executor, documented in the Flowable advanced docs, runs timers from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database, so an expired lock is recovered and another node takes the job. Confirm the exact timer definitions, duration syntax and cycle support for your engine version in the Flowable docs before you commit a model to production.
Choose interrupting or non-interrupting behavior before you model the first escalation. An interrupting boundary timer cancels the activity it is attached to, which suits a hard deadline, while a non-interrupting timer leaves the task open and lets the process send a reminder or raise a second flow. Decide who owns the deadline value (a process variable, a configured setting or a calculated date), how time zones and business calendars are handled, and what should happen if a node is down when the timer is due. Ask your Flowable implementation partner to show these choices in a test deployment, and confirm your database and clock behavior against the Flowable configuration documentation, because timing precision depends on the database in use.
Choosing timer start, intermediate and boundary events
This table compares the three places a Flowable timer can sit: a timer start event, an intermediate catch timer, and a boundary timer on a task. Read each row to match the placement to the job, then check what the timer does to the activity it is attached to and which configuration mistake is most likely.
| Timer placement | When it fits | What happens to the attached activity | Main configuration risk |
|---|---|---|---|
| Timer start event | Scheduled processes that begin a new instance on a timetable, such as a nightly reconciliation or a periodic review | Nothing is attached, so no work is interrupted; each firing creates a new process instance | Repeating cycles starting more instances than the business expects after a restart or a long outage |
| Intermediate catch timer | A deliberate wait inside a flow, such as a cooling-off period or a pause before the next step | The token waits at the event and the flow continues only when the duration or date is reached | Waiting on a fixed date or duration that is not time zone aware, so the wake-up time differs from what operations expects |
| Boundary timer, interrupting | Hard deadlines where the work must stop once time runs out, such as an approval window that closes | The attached task is cancelled and the flow follows the timer path, so unsaved user work on that task is lost | Choosing interrupting by default, which can cancel a task a person was still completing |
| Boundary timer, non-interrupting | Reminders and escalation notices that must not disturb the person still working on the task | The task stays active and the timer path runs in parallel, creating a second branch that must be closed | Repeating non-interrupting cycles that pile up reminder tasks if the original task is never completed |
| Boundary timer on a service task | Limits on how long an external call or delegate may run before the flow takes a fallback path | The running service call is interrupted from the process view, so the external system may still complete its work | Assuming the external side effect is rolled back when the timer fires |
| Timer duration format | Expressing relative waits and recurring intervals in the ISO 8601 form the engine accepts | Determines how far ahead the timer fires after the token arrives or the instance starts | Mixing durations, dates and cycles, or relying on a variable expression that resolves to an invalid value at runtime |
| Async executor dependency | Any timer that must fire on time across several nodes running the engine | Timers are picked up by the async executor, so a delayed or stopped executor delays every timer on the cluster | Assuming a timer fires exactly at its due time when the executor is busy, misconfigured or not running |
ISO 8601 durations, dates and cycles in practice
A fixed duration is the most common timer expression in reminder and SLA models. It is written as an ISO 8601 duration, such as a number of days, hours or minutes preceded by the letter P for period and T for time, and it is measured from the moment the engine reaches the timer event. The clock starts when the token arrives, not when the process was deployed or when the business record was created, so the model must be read with that starting point in mind.
- Starting point: The duration counts from token arrival at the boundary or intermediate event, which can differ from the date a case was logged.
- Expression location: The value is set in the timer definition of the BPMN model and can be supplied as an expression that reads a process variable.
- Variable-driven values: When a variable sets the duration, confirm how the engine evaluates it at runtime and what happens if the variable is missing.
- Restarts: Confirm in the Flowable docs that a restart of the engine does not reset a running duration, and test it in your environment.
- Short durations: Very short timers depend on the async executor's polling, so they may fire slightly late.
Confirm the exact expression grammar and variable evaluation rules against the Flowable BPMN documentation for your engine version before you publish models.
An absolute date timer fires at one fixed point in time, written as an ISO 8601 date and time. It suits scheduled activities such as a policy review on a known date or a contract expiry that is recorded as a specific day. Because the value does not move, the main risks are time zone interpretation and data entry errors in the variable that supplies the date.
- Fixed point: The timer fires once at the stated instant, so it does not recalculate if business dates shift later.
- Variable input: When the date comes from a form or integration, validate its format and time zone before it reaches the engine.
- Past dates: Decide what the model does when the computed date is already past at token arrival, and test that path explicitly.
- Audit trail: Record the date value in process variables so reviewers can see what the engine was asked to wait for.
- Reassignment: Changing an absolute date on a running instance usually needs an operational procedure, so plan that workflow before go-live.
Ask your team to document how absolute dates are created, validated and stored so the value reviewed in the model matches what fires in production.
A repeating cycle timer fires on a recurring schedule, written as an ISO 8601 repeating interval that combines a repeat count with a duration. Cycles are used for periodic reminders, recurring escalations and scheduled processes that restart on a timetable. They differ from a single duration because each firing creates another run of the timer, so the engine's behavior at each repetition must be understood before the model is used for reminders that reach people.
- Repeat count: The count sets how many times the cycle runs, and an open-ended cycle needs an explicit stop condition in the model.
- Interrupting or not: Whether a boundary cycle interrupts the activity or runs alongside it changes how many reminders a person receives.
- Start events: A cycle on a timer start event creates new process instances on each firing, which affects volume and downstream load.
- Load on the executor: Many cycles across many instances add jobs to the async executor, so size it with the expected volume.
- Verification: Test a short cycle in a non-production environment and count the firings against the expected schedule.
Confirm the cycle syntax and the behavior of start event cycles against the Flowable docs for your version before rollout.
A repeating timer does not end by itself in a model unless its design says so. Ending behavior has to be planned as deliberately as the schedule, because a cycle that outlives its business reason keeps creating jobs, notifications or new instances. Most stop conditions come from the surrounding process, such as a task completing, a message arriving or a boundary event being cancelled when the activity ends.
- Activity completion: A boundary timer on an activity is cancelled when the activity completes, which is the simplest end condition.
- Explicit stop path: Model a path that a completed status or a message triggers to end the cycle when the activity itself runs longer.
- Count exhaustion: A finite repeat count ends the cycle after its last firing, so confirm the final firing is what the business expects.
- Stranded instances: Check for instances left waiting after a cycle ends unexpectedly, because they can hold data and resources.
- Operations: Give operators a way to find and cancel recurring timers that no longer have a business owner.
Review each cycle with the process owner and record the stop condition in the model documentation.
Time zones and daylight saving changes are where timer behavior most often surprises teams. An expression written without a clear offset can be read against the server's local zone, and a duration that spans a daylight transition may not match a wall clock reminder. Regulated processes often require that reminders and deadlines match the jurisdiction of the customer or the business unit, so the zone rules must be settled before go-live.
- Server zone: Confirm which time zone the engine and the database use, and whether it matches the business zone of the process.
- Offset notation: Use explicit offsets in absolute dates to remove ambiguity, and test how the engine parses them.
- Daylight transitions: Test a duration that crosses a daylight change and compare the firing time with the expected local time.
- Database precision: Some database versions limit timestamp precision, so check the configuration notes for the database you use.
- Container clocks: Verify the time zone and time synchronization of every node, since clustered engines must agree.
Confirm all zone and daylight handling against the Flowable configuration and BPMN documentation for your version, and document the result in your test evidence.
Setting up timers in a Flowable deployment
This sequence takes a timer model from configuration to a verified recovery test, so the team knows the async executor fires timers, the job tables hold them, and a second node can pick up work when a lock expires. It is meant to run in a test environment before any production rollout.
Confirm the async executor is enabled and sized
The engineer responsible for the Flowable configuration checks that the async executor is enabled in the engine configuration and that its thread pool and job acquisition settings match the expected load of the test environment. Timers and asynchronous jobs are run by this executor, so a disabled or undersized executor means timers never fire. Record the configuration values in the change ticket. The step is done when the configuration file or environment properties show the executor enabled and the values are reviewed by a second engineer. Confirm the exact property names against the Flowable configuration documentation for the version in use.
Model the timer event and its expression
A process designer adds the timer event to the BPMN model, choosing a timer start, intermediate catch or boundary event, and enters the timer expression as an ISO 8601 duration, date or cycle. The designer also decides whether a boundary timer is interrupting or non-interrupting, because that choice changes what happens to the attached task when the timer fires. Expressions that read process variables should be tested with sample values so an unexpected format does not fail at runtime. The step is done when the model validates in the modeler and a reviewer has confirmed the timer type and interruption behavior against the reminder or escalation requirement.
Deploy the model to a test database
The platform engineer deploys the process definition to a test environment that uses the same database type as production, since job table behavior depends on the database. Supported database types are listed in the Flowable configuration docs, and MySQL versions below 5.6.4 lack millisecond precision, which matters for timer accuracy. Start the engine and confirm the deployment appears in the repository tables without errors in the startup log. The step is done when the process definition is listed as deployed and the engine reports no startup exceptions.
Verify timer jobs appear in the job tables
Start a process instance that reaches the timer event, then query the job tables to confirm a timer job exists with the expected due date and the correct process instance reference. The engineer compares the due time with the expression result, which catches time zone or format mistakes early. If no job appears, check that the executor is running and that the instance reached the timer activity. The step is done when a timer job row matches the expected due time for at least one test instance.
Fire a test timer and confirm the outcome
Shorten the test duration or move the due date in the test database so the timer becomes due, then let the async executor pick it up. The tester confirms the job is executed, the process moves along the timer path, and the expected reminder, escalation or scheduled action happens. For a non-interrupting boundary timer, the tester also confirms the original task remains active. The step is done when the test log and the process history show the timer fired once and the downstream path matches the design.
Confirm a second node recovers an expired lock
Run two engine nodes against the same test database. Lock an unexecuted timer job on the first node, stop that node or let its lock expire, and confirm the second node acquires the job after the lock expiration time passes. The async executor stores lock owners and lock expiration times in the database, so this test shows whether a node failure delays or drops escalations. The step is done when the job is executed exactly once by the second node and no duplicate history entries appear.
Record the verification evidence for review
The engineer collects the configuration values, the model version, screenshots or query output of the job rows, the test timer log, and the lock recovery result into the release record. Operations and the process owner review the evidence together, and any open questions about retries or failed jobs are assigned to a follow-up item. The step is done when the reviewers sign off and the record names the Flowable version and database used for the test.
Interrupting versus non-interrupting escalations
Each timer on a Flowable model answers a few design questions before it answers any technical one: does the deadline end the work, does a reminder run beside it, and who inherits the work when time runs out. The cards below walk through those decisions in the order a team usually meets them, and flag what to test before the model reaches production.
Cancel the work item or not
An interrupting boundary timer on a user task closes the task when the duration elapses and sends the token down the timeout path. A non-interrupting timer leaves the task open and fires alongside it. Decide this per activity from the business rule: a claim that must be decided by a date is usually interrupting, while a reminder to an approver who can still act is usually non-interrupting. Confirm the choice in the model diagram with the process owner, because the two behaviors look similar on screen.
Reminders that run alongside work
A non-interrupting timer is the usual way to send a reminder while the user task stays active. The reminder path should write a notification or update a status variable, then end without changing the task's assignee or outcome. Check that the reminder path cannot complete the task by accident, and that the user can still finish the task after the reminder has fired.
Modeling repeated reminders
Repeated reminders need a cycle expression on a non-interrupting timer, or a loop that reschedules a one-shot timer. Each choice has different effects on how many times the reminder fires and when it stops. Decide the stop condition before the build starts, such as the task completing or a maximum count being reached, and test both paths. Confirm with the engine version you plan to run how cycle expressions behave after restarts.
Reassigning work on escalation
An escalation path often moves work from a first-line queue to a supervisor or group. Model the reassignment as an explicit service or user task step on the escalation branch rather than relying on the reminder to change ownership. Record who held the task before and after the change, because audit and support teams will ask. Check that the new candidate group exists in your identity source and that the change is visible in task queries.
Variables set when a timer fires
Variables written on the timer path are visible to the rest of the process only after that path runs, and interrupting timers may discard values the task was carrying. Set escalation level, timestamps and reason codes as explicit process variables on the timer branch. Test the timer path with a realistic variable set, and confirm which values survive when the task is later completed or cancelled.
Timers on subprocesses and multi-instance activities
A boundary timer on a subprocess or multi-instance activity applies to the whole scope, so an interrupting firing ends every running instance inside it. Decide whether the deadline should cover the whole batch or each item, and model the two differently when needed. Test partial completion, since some items may finish before the timer fires and others may be cancelled mid-flight.
Questions teams ask before timers reach production
What drives the effort to build Flowable timers?
The effort depends mainly on how many deadlines exist, how each one behaves when it fires, and how many systems the escalation touches. Each timer needs a defined duration or cycle, a decision on whether it interrupts the activity it is attached to, and a clear outcome such as a reminder, a reassignment or a status change. Timers that trigger notifications through external services add integration and testing work. Business rules for working calendars, time zones and exceptions add more analysis. Ask any partner to break the estimate down by deadline type, not by a single total.
Can an in-house team build Flowable timer escalations themselves?
Yes, a team with Java and BPMN experience can build them, since the Flowable open source engines are licensed under Apache 2.0 and the timer events are part of standard BPMN modeling. The harder part is the operational knowledge: how the async executor fires timers across nodes, how lock expiration recovers jobs, and how to test behavior under restarts and load. Ask whether your team has already run the async executor in a clustered deployment. If not, a fixed-scope build with a clear handover can close that gap, and your engineers should review the models and tests before go-live.
What does a partner need from our team to start?
A partner needs the business rules behind each deadline, not only the diagram. Prepare the list of processes that need timers, the SLA definitions with their durations or cycles, the owners who receive each escalation, and the systems that must be notified. Access to a non-production environment with your database type, such as PostgreSQL, Oracle or Microsoft SQL Server, and to your identity source is also needed. Name the person who signs off on each escalation rule, because unclear ownership is the most common source of rework.
How long does a scoped timer build take?
Duration depends on the number of deadlines, their interaction with other process features, and how many environments must be validated. A small set of reminders on one process is far shorter than a set of interrupting escalations spread across many processes with notifications and reporting. No duration is set in advance for this page. Ask for a written timeline tied to the agreed deadline list, with milestones for model review, test runs against the async executor and a production readiness check.
What happens to running timers during a Flowable upgrade?
Running timers are stored as jobs in the database, so an upgrade must be planned around them rather than ignored. Check the release notes for the version you move to before the change, because major releases can change the Java, Spring and Jakarta baseline that the engine runs on. Test in a copy of production data that timers still fire at the expected times, and confirm how pending jobs are handled during the switch. Flowable's 8.0.0 release notes describe an upgrade to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3, which affects any timer-bearing application on Spring Boot 3. Confirm the exact upgrade steps with your partner and the vendor documentation for your version.
Does the timer build include migrating active processes from Camunda 7?
Only if it is written into the scope. Flowable's engineering blog describes migrating Camunda 7 and Activiti data in place, including active process instances and history, and offers the free Flowable LEAP tool to report ahead of time what a migration involves. Run that report before estimating the timer work, because existing timers on active instances may need checking or conversion. Treat any migration of running timers as a separate deliverable with its own test cycle, and ask the partner to state whether it is included in the quote.
What should a fixed-scope quote for timers include?
A fixed-scope quote should list each process and deadline covered, with its duration or cycle, its interrupting or non-interrupting behavior and its escalation outcome. It should name the deliverables, such as BPMN models, delegates, tests and runbook entries, and state what the client must provide. Ask which environments are in scope, how the async executor will be tested across nodes, and what happens to timers during any upgrade or migration. Also ask what is one-time work and what recurs under a support retainer, and which changes to the deadline list would trigger a change request.
How DeployOpen scopes timer and escalation work
Timer and escalation work starts with a written scope, not a model. Before any build begins, DeployOpen and the client agree in writing on which processes carry timers, which deadlines they enforce, who receives each escalation, and what happens when a deadline passes without a response. The scope lists each timer start, intermediate and boundary event, its ISO 8601 duration or cycle, whether it interrupts the activity it guards, and the business owner who signs off the rule. It also records the calendar the deadlines follow, such as business hours, time zones and public holidays, because those choices change every duration in the model. Scope and timelines are agreed before work starts, so the client knows what is included and what a change would cost.
Implementation then happens inside the client's own infrastructure, against the client's own database and deployment pipeline. DeployOpen models the processes, configures the timers, and tests them in environments the client controls. Tests cover the boundary cases that cause most production incidents: a timer firing while a task is being completed, a second node picking up an expired lock, a clock change during a long-running cycle, and an escalation that must not fire after a task is closed. The team also confirms how the async executor behaves in the client's cluster, since timers depend on it to fire. Clients should confirm the target Flowable version and database type early, because those decide which timer behavior and deployment steps apply.
After go-live, timers and escalation paths usually need ongoing attention as policies change, staff rotate and new SLAs appear. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, so the client can keep changes to deadlines under the same written process as the original build. Clients should ask for the scope document, the test cases covering each deadline and escalation, and the handover material for their operations team, and should confirm with their own risk and operations owners who signs off each deadline before the work is accepted.
