Event Sub-Process
A sub-process with no incoming/outgoing flows, started by an event (message, error, timer…) occurring while its parent scope runs. Drawn with a dotted border.
The Event Sub-Process is the scope's standing guard: dormant until its start event's trigger occurs anywhere in the surrounding scope, then it runs — interrupting the scope (solid-border start) or in parallel with it (dashed-border start).
It centralizes cross-cutting handling — errors, inquiries, cancellations — that would otherwise clutter the main flow with boundary events everywhere.
When to use and avoid
When to use
To handle events that can occur at any moment during the scope: status inquiries, cancellation requests, errors.
To keep the happy path clean, concentrating exception handling in one visible place.
When the same trigger must be handled identically regardless of where the scope currently is.
When NOT to use
When the trigger relates to one activity only — a boundary event on it is more precise.
For ordinary sequential structure — embedded sub-process.
When no event can actually reach the scope — dead guard.
Business example
A standing handler for status inquiries
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 claim flow runs normally.
- The Event Sub-Process (highlighted, dotted border) sits apart, with no flows connecting it.
- Whenever a status inquiry arrives, its non-interrupting message start fires the handler in parallel — the claim work never notices.
Differences
Event Sub-Process vs Boundary Event
A boundary guards one activity; the event sub-process guards the entire scope and carries its own handling flow inside. Scope-wide policies → event sub-process; step-specific reactions → boundary.
FAQ
Which start events can it use?
Typed, catching starts: message, timer, error, escalation, conditional, signal, compensation, multiple — each interrupting or (except error/compensation) non-interrupting.
Why doesn't it have sequence flows to the rest?
By definition — it is activated by its start event, not by tokens flowing in; it lives alongside the flow, not on it.