Lesson 3 of 3
What a Boundary Event is
A Boundary Event is attached to the edge (boundary) of a Task or Sub-process. It represents something that can happen while the task is running — an interruption, an error, a message arriving, a timer firing — that triggers an alternative path.
Boundary Events are BPMN's mechanism for exception handling. Rather than cluttering the main flow with conditional branches from every task, you attach the exception to the task itself and route it to its own handling path.
Interrupting vs. non-interrupting
| Type | Border | What happens | Use for |
|---|---|---|---|
| Interrupting | Solid | Cancels the task. The main flow stops and the exception path begins. | SLA breaches that escalate and cancel original work; errors that prevent task completion |
| Non-interrupting | Dashed | Starts a parallel action. The task and the exception path both run. | Reminders alongside ongoing tasks; monitoring actions that do not affect the task outcome |
Why the distinction matters
Cancelling versus parallel-running has very different business implications. An interrupting boundary event is an escalation — the original work stops. A non-interrupting boundary event is a notification — the original work continues. Using the wrong one produces a model that describes something different from what the business actually intends.
Common Boundary Event types
| Boundary Event type | Interrupting use case | Non-interrupting use case |
|---|---|---|
| Timer | SLA breach cancels task → escalate to senior | Reminder sent after 24h → task continues |
| Message | Customer cancels order → stop picking goods | Customer updates delivery address → note it, continue fulfilment |
| Error | Payment gateway returns error → handle failed payment | Not available — errors are always interrupting |
| Escalation | Escalation signal received → transfer to manager | Escalation notification sent → task continues at lower level |
Boundary Events as BA tools
From a business analysis perspective, Boundary Events make implicit process commitments explicit. A task without a Timer Boundary Event implicitly assumes it will always complete. A task with one says: we acknowledge this might not complete in time, and here is what happens if it does not. This converts undocumented risk into modelled process logic — and modelled process logic becomes a business requirement.
Example: A task 'Resolve Support Ticket' has a Timer Boundary Event (interrupting) set to 4 hours. When the timer fires, the task is cancelled and the flow routes to 'Assign to Senior Engineer.' This converts an informal SLA into an explicit escalation rule visible to every stakeholder who reviews the diagram.
✓ When to use
- Timer Boundary Event (interrupting) for SLA escalations that cancel and redirect the process
- Timer Boundary Event (non-interrupting) for reminders and monitoring alongside an active task
- Error Boundary Event on any automated task where a failure mode exists and requires a defined handling path
- Message Boundary Event when an external message can arrive during a task and must change what happens
✗ When not to use
- ✕Don't use Boundary Events for normal process decisions — those belong on Exclusive Gateways after the task completes
- ✕Don't add Error Boundary Events to manual (User) Tasks — they are primarily for automated (Service) Tasks
- ✕Don't leave Boundary Events unconnected — every one must have an outgoing Sequence Flow