Error Boundary Event
Attached to an activity's border, catches an error raised inside it and diverts the flow; always interrupting — the activity is aborted. Double circle with a lightning icon.
The Error Boundary Event is BPMN's try/catch: it supervises one activity (or sub-process) and, if a matching error occurs inside, aborts it and routes the token down the exception path. Error boundaries are always interrupting — a failed activity cannot keep running.
When to use and avoid
When to use
To give a specific activity an explicit failure path (payment declined, integration failed).
On sub-processes, to catch Error End Events thrown inside them.
To keep the happy path linear while failures branch off visibly.
When NOT to use
For non-fatal warnings — use Escalation (which can be non-interrupting).
For scope-wide handling of the same error from many activities — an Error Event Sub-Process centralizes it.
To model business rejections that are normal outcomes — prefer an explicit gateway; errors are for abnormal terminations.
Business example
Handling a declined payment
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Charge credit card runs normally toward “Payment settled”.
- If the gateway declines, the task throws an error; the Error Boundary Event (highlighted) catches it and aborts the task.
- The exception path Offer alternative payment takes over and ends the flow separately.
Differences
Error Boundary vs Escalation Boundary
Error is fatal and always interrupts the activity. Escalation signals severity and is usually caught without interrupting. Abort-and-divert → Error; alert-and-continue → Escalation.
FAQ
Can an error boundary be non-interrupting?
No — the spec forbids it. An activity that erred cannot continue; the boundary always cancels it.
What errors does it catch?
A specific error code (if referenced) or any error from the attached activity (if left generic). Sub-process Error End Events are the classic source.