Signal Boundary Event
Reacts to a broadcast signal while the activity runs — e.g. a global freeze or reprioritization — interrupting the work or firing a parallel path. Double circle with a triangle.
The Signal Boundary Event subscribes one running activity to a broadcast: when anyone throws the matching signal, this activity reacts. It is the tool for organization-wide interventions — “stop all dispatches”, “switch to contingency mode” — that must affect work in flight.
When to use and avoid
When to use
To make in-flight work responsive to global announcements (freeze, recall, contingency).
When many different activities across processes must react to the same broadcast — each simply wears the boundary.
For coordinated pausing/aborting during incidents.
When NOT to use
For addressed communication about one case — Message Boundary.
When the reaction belongs between activities — an intermediate signal catch on the path.
As a data-threshold monitor — Conditional Boundary.
Business example
Halting dispatch on a product recall signal
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Dispatch order is executing normally.
- Quality broadcasts the signal “product recall”: the Signal Boundary (highlighted) interrupts the dispatch.
- Quarantine shipment takes over on the exception path.
Differences
Signal boundary vs message boundary
The message targets this specific instance (correlated). The signal hits every subscribed activity everywhere — no correlation, maximal reach. Broadcasts are blunt instruments; use them for genuinely global facts.
FAQ
Do all instances react to one signal?
Yes — every active activity wearing a matching signal boundary reacts, across all instances and processes.
Interrupting or non-interrupting?
Both allowed. Freezes/aborts are interrupting; informational reactions can be non-interrupting.