#Handle a failed step with an error boundary event
An error boundary event on a task, sub-process or call activity takes over when that step fails for good, stops it, and continues the process on its own path instead of failing the instance.
#What happens when the step fails
flowchart LR
S["Service task<br/>Book shipment"] -- "succeeds" --> N["Send confirmation"]
S -. "fails, after its retries" .-> E(("Error boundary"))
E --> H["User task<br/>Book it by hand"]
S -. "no boundary event" .-> F["The instance fails"]
- The step fails — for a service or send task only once its retries are used up.
- The error boundary event takes over. The step is stopped and does not continue.
- The process continues on the path that leaves the boundary event. The instance does not fail.
Without a boundary event, the whole instance fails, and it can be retried from monitoring.
#Add an error boundary event
- Drag an intermediate event onto the edge of the step, and change its type to an error boundary event.
- Draw a sequence flow from the boundary event to the steps that handle the failure.
The boundary event itself needs no configuration.
⚠️ The panel shows an Error group with Global error reference, Name and Code. None of them is used: the boundary event catches every failure, whatever the code.
#Which failures it catches
| The step | Caught when |
|---|---|
| Service task, message throw | The call still fails after the last retry; at once for a value that cannot be worked out or an incomplete configuration |
| Send task | The email is refused for good, or still fails after the last retry |
| Sub-process | A step inside fails and the inner part ends in an error |
| Call activity | The called run ends in an error, the target has no production deployment, or the nesting limit is reached |
| User task | Only when the form cannot be prepared. Completing a task is never an error, whatever the person entered |
| A multi-instance step | The first run that fails |
It does not catch:
- ❌ an error end event inside a sub-process or a called process — that ends normally;
- ❌ a failed tool call of an agent — the agent is told about it and carries on.
#What the boundary path knows about the error
Nothing. The error message and its code are in the instance's history in monitoring, but not in the process data — the steps after the boundary event cannot read them, and there is nothing to pick in the variable list. A gateway cannot choose a path by the kind of error.
#Retry from monitoring
A step with an error boundary event cannot be retried from monitoring: the view shows "An error boundary catches this error." instead of the retry button, because the boundary path is meant to handle it.
#What an error boundary event cannot do
- ❌ Catch a particular error only. There is no filter by code; the Code field has no effect.
- ❌ Pass the error on. The boundary path gets no error message or code.
- ❌ Other boundary events. Timer, message, signal, escalation, conditional, compensation and cancel boundary events cannot be deployed. For a time limit, see Wait for a while with a timer event.
- ⚠️ End without a path. A boundary event without an outgoing sequence flow still fails the instance, and the modeller does not warn about it.
- ⚠️ Stop the other runs of a multi-instance step. When one run fails, the boundary path starts, but the runs that are still going may continue.