Escalation Boundary Event
Attached to an activity (usually a sub-process), catches an escalation raised inside it. Often non-interrupting: the sub-process keeps working while the parent reacts. Double circle with an arrowhead.
The Escalation Boundary Event is the catching side of the escalation channel: a child sub-process throws “needs attention”, and the parent — via this boundary — reacts. In its common non-interrupting form (dashed border), the child continues while the parent handles the alert in parallel.
When to use and avoid
When to use
To let a parent react to a child sub-process's alert without aborting the child.
For supervisor-intervention patterns triggered from inside long work.
To surface severity levels that are not failures.
When NOT to use
For fatal conditions — Error Boundary.
Between different participants — escalations don't cross Pools.
When no one throws an escalation inside — the boundary would never fire.
Business example
Supervisor steps in on a delayed handling
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Handle claim (sub-process) works the case; internally it throws the escalation “handling delayed” when its target slips.
- The Escalation Boundary (highlighted) on its border catches it — without interrupting the handling.
- Supervisor intervention runs in parallel to unblock the team.
Differences
Escalation Boundary vs Error Boundary
Same shape idea, opposite temper: Error always interrupts (the work failed); Escalation usually doesn't (the work needs help). If the child should keep running, escalation is the channel.
FAQ
Where does the escalation come from?
From an Escalation Throw (intermediate) or Escalation End Event inside the attached activity/sub-process — matched by escalation code when specified.
Can it be interrupting?
Yes, both forms are legal. Interrupting means the sub-process is aborted when escalated — use deliberately.