Escalation End Event
Ends the path while raising an escalation to the parent scope — finish here, but flag it upstairs. Thick circle with a filled arrowhead.
The Escalation End Event combines completion with a severity flag: the current path ends, and an escalation travels up for a parent catcher (boundary or event sub-process) to act on. Unlike Error End, it does not represent failure — the work concluded, but attention is required.
When to use and avoid
When to use
When a sub-process concludes a path in a state that management should see (e.g. approved with exceptions).
To end fallback branches that upstream supervisors track.
As a softer alternative to Error End when nothing actually failed.
When NOT to use
For failures — Error End.
When nobody upstream would catch it — an escalation without a catcher is dead weight.
For notifying other participants — Message End.
Business example
Concluding with a flag for the supervisor
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Apply fallback procedure resolves the case through the exceptional route.
- The Escalation End Event (highlighted) ends the path and raises “fallback used” to the parent.
- The parent's escalation catcher logs the occurrence for the quality review, without treating it as a failure.
Differences
Escalation End vs Error End
Error = the scope failed; handling is mandatory and interrupting. Escalation = the scope finished but flags severity; catchers are often non-interrupting. Choose by whether the outcome is a failure.
FAQ
Does the escalation interrupt the parent?
Only if the parent catches it with an interrupting construct — commonly it doesn't; the parent just reacts in parallel.
Can the escalation carry a code?
Yes — escalations are identified by code so catchers can filter which ones they handle.