he Emit Signal node sends a targeted signal from one automation to a waiting automation. A signal is point-to-point — one emit resumes exactly one waiter. Attach a data payload for the waiter to read when it resumes, and set the cleanup option when the receiving wait is persisted.
Overview
Signals let one automation pause until another tells it to continue. The Emit Signal node is the sender side of that pair. It targets the signal precisely — by the destination automation, the specific waiting node within it, and a signal ID. When the signal arrives, the matched waiting automation resumes immediately. Because signals are point-to-point, a single emit wakes exactly one waiter; they do not fan out to multiple listeners. Use Emit Signal whenever one automation needs to unblock another — after an approval, after a child reports results back, or at the conclusion of a handoff between two flows.
Emit Signal node configuration
Operations
Emit Signal
Sends a signal to a waiting automation. Configure three targeting parameters and two optional ones:
Parameter | Required | Description |
|---|---|---|
Target automation | Yes | The automation that contains the waiting node to resume. |
Target waiting node | Yes | The specific wait node within the target automation to wake. |
Signal ID | Yes | Identifies which signal this is. Defaults to a standard value if not set. The emitter and waiter must agree on the same ID. |
Payload | No | Data to pass to the waiter on resume. The schema is descriptive — not strictly enforced at runtime. |
Cleanup | No | When the receiving wait is persisted (long wait), set this option so the saved signal state is freed after delivery. Without cleanup, persisted signal data lingers. |
Signal Routing
A signal is targeted, not broadcast. Routing uses three coordinates: the destination automation, the waiting node within it, and the signal ID. If you use several distinct signals from the same node, assign each its own ID so the right waiter wakes for the right event. Using the same default ID for multiple signals means only the intended waiter will receive the one it expects — ensure IDs are unique where multiple signal paths diverge.
Notes
Keep the following in mind when emitting signals.
One emit resumes one waiter — signals are point-to-point, not publish/subscribe. For fan-out, emit separate signals to each waiting automation.
The signal ID defaults to a standard value if not set. Assign distinct IDs when multiple signals originate from the same node.
The payload schema is described for the builder's convenience but is not strictly enforced at runtime. Design the receiving automation to tolerate missing or unexpected fields.
Emit-before-wait risk: for ordinary (non-persisted) waits, if a signal is emitted before the waiter has paused at its wait node, the signal can be missed. Use the long/persisted wait on the receiver for resilient hand-offs.
When the receiving automation uses a persisted (long) wait, set the cleanup option on Emit Signal so saved signal state is freed after delivery.
When coordinating multiple parallel branches, emit distinct signal IDs for each branch so that every waiter wakes for its own signal rather than competing for the same one.