Intermediate Signal Catch Event
Pauses the flow until a matching broadcast signal is thrown somewhere. Double thin circle with an outlined triangle.
The Signal Catch Event subscribes a waiting instance to a broadcast: the token waits until *anyone* throws the matching signal, then continues. Perfect for synchronizing on organization-wide facts without direct coupling.
When to use and avoid
When to use
To hold work until a company-wide fact occurs (“budget released”, “window opened”).
To synchronize many instances on a single announcement — all waiting tokens resume together.
To react to facts produced by processes you don't control directly.
When NOT to use
For an addressed reply from a partner — Message Catch.
When the fact may have happened before you started waiting — signals are not retained; check state with a gateway first.
When only one specific instance should react — broadcast wakes them all.
Business example
Waiting for the annual budget release
Open this example in the HEFLO process editor and explore the diagram from the inside.
Open in the HEFLO editor →Step by step
- Prepare purchase plan drafts everything that depends on budget.
- The Signal Catch Event (highlighted, outlined triangle) waits for finance to broadcast “budget released”.
- When the signal fires, Execute purchases proceeds — as do all other waiting instances across the company.
Differences
Signal Catch vs Conditional Event
Both react to something 'out there'. The Signal reacts to an explicit broadcast someone throws; the Conditional reacts to observed data state with no thrower. Announcement → Signal; rule over data → Conditional.
FAQ
If ten instances wait for the same signal, how many resume?
All ten — a broadcast wakes every waiting catcher, which is often exactly the desired behavior.
Are signals persisted for late subscribers?
No. A catcher that subscribes after the throw missed it. Model re-announcements or check state if that matters.