Error End Event
Ends the path by throwing an error that a surrounding scope must catch — the sub-process's way of failing loudly. Thick circle with a lightning icon.
The Error End Event terminates the current scope abnormally: it raises a named error upward, to be caught by an Error Boundary Event on the enclosing activity or by an error event sub-process. Inside a sub-process it is the standard way to say *this failed — handle it up there*.
When to use and avoid
When to use
Inside sub-processes, to signal failure to the parent explicitly.
To end validation dead-ends as *errors* rather than silent completions.
Paired with a catching construct — an uncaught error is a modeling smell.
When NOT to use
For normal negative outcomes (offer declined) — those are ordinary ends after a gateway.
At the top level with no catcher anywhere — behavior degenerates to an abrupt end.
When the scope should continue despite the problem — Escalation.
Business example
Failing a validation sub-flow
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Validate documents discovers an unrecoverable inconsistency.
- The Error End Event (highlighted) ends this scope by throwing “validation failed”.
- The parent's error boundary catches it and routes the case to correction — as shown on the Error Boundary page.
Differences
Error End vs None End after a gateway
A gateway + None End models an expected negative outcome; the Error End models abnormal termination that demands a handler. If the parent must react specially, throw the error.
FAQ
Who catches the thrown error?
The nearest enclosing catcher: an Error Boundary on the sub-process/activity or an error event sub-process of the scope.
Does it abort sibling branches in the same scope?
Yes — an error terminates its whole scope, not just the throwing path.