Error Event Sub-Process Start (interrupting)
Starts an Event Sub-Process that handles an error raised anywhere in the surrounding scope; always interrupting — the normal flow is aborted. Single thin dashed?? No: drawn with a thin border circle containing the error icon, inside the event sub-process.
Placing an Error Start Event inside an Event Sub-Process turns that sub-process into the scope's error handler: whenever a matching error is thrown in the surrounding process, the handler starts and the normal flow of that scope is interrupted (error handling is always interrupting — a scope cannot continue as if nothing happened).
This centralizes error handling that would otherwise require boundary events on many individual activities.
When to use and avoid
When to use
To handle the same error uniformly wherever it occurs in the scope.
To keep the happy path clean, moving error handling off to the side.
For end-of-scope cleanup that must run when processing fails.
When NOT to use
When the error concerns one specific activity — an Error Boundary Event on that activity is more precise.
For recoverable situations where the normal flow should continue — errors always interrupt; consider Escalation for non-interrupting severity.
As a substitute for fixing systematically failing steps.
Business example
Centralized validation-error handler
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- The main flow processes an order normally.
- If any step throws a validation error, the Error Start Event (highlighted) of the event sub-process fires.
- The handler notifies the customer; the interrupted main flow does not resume.
The dotted-border sub-process is the event sub-process; it has no incoming or outgoing sequence flows.
Differences
Error Event Sub-Process vs Error Boundary Event
The boundary catches errors from *one* activity; the event sub-process catches errors from the *whole scope* it lives in. Prefer the boundary for step-specific recovery, the event sub-process for scope-wide policies.
FAQ
Can an error event sub-process be non-interrupting?
No. Error handling always interrupts the scope — the spec forbids a non-interrupting error start. For non-interrupting severity signalling, use Escalation.
Where does the flow go after the handler finishes?
Nowhere in the interrupted scope — it ended with the error. The handler's end completes the scope (typically followed by the parent reacting).