Getting it right · 08 · 7 min
Boundary events
An event attached to an activity’s edge: while this work is happening, something else may occur.
The border style changes the behaviour completely, and it is easy to miss when reading quickly.
Interrupting, solid border
The timer fires, the activity is cancelled, and the same token leaves the task along the boundary path. One token, redirected: nobody approves this invoice any more, the manager takes it over. The diagram runs twice, first approved in time, then with the 5 days passing first.
If "Approve invoice" isn't done in 5 days, the interrupting timer (solid border) cancels it and the token goes to "Escalate to manager". Otherwise it continues to "Pay invoice".
Non-interrupting, dashed border
The timer fires, the activity continues, and an additional token is spawned on the boundary path. Two tokens are now live: the reminder goes out while the approval is still open, and once it is approved the invoice is paid as usual.
After 2 days the non-interrupting timer (dashed border) sends a reminder as an extra token, while the approval keeps running and still ends in "Pay invoice".
Side by side, the two borders differ in one way that matters: what happens to the token already inside the activity.
| Border | Behaviour | Typical use |
|---|---|---|
| Solid double | Cancels the activity. One token, redirected. | Timeout that abandons the work; error handling |
| Dashed double | Activity continues. An additional token is spawned. | Send a reminder while still waiting; escalate without cancelling |
Both traps below come from reading that table too quickly.
After this module you can
- Distinguish interrupting from non-interrupting behaviour
- Account for the extra token a non-interrupting event spawns