Wait for an event
A wait pauses an existing run until an expected event matches or its timeout expires. Choose the wait type according to who produces the event.
This guide covers the Automations dashboard preview, which is not yet generally available.
Wait for a message receipt
- Add Wait for event after a send step's success path.
- Select the earlier action whose message you want to watch.
- Choose the supported event types and set a timeout.
- Connect Matched to the step that handles the receipt.
- Connect If time runs out, the timeout path, to the step that handles the missing receipt.
The wait watches the message created by that action in this run. A message from another run does not satisfy it. A receipt that arrives before the run reaches the wait can still be used.
The send must succeed on the path leading to the wait. A failure path cannot wait for a message that the send never accepted. Watched email and WhatsApp sends must address one recipient.
Wait for event does not wait for an arbitrary incoming reply. Use a Bird event trigger to start a separate workflow for a supported incoming message.
Wait for an application event
Use Wait for application event for an event such as payment confirmation or appointment cancellation associated with a particular business item.
- Configure the workflow's business key under Run overlap, such as an invoice ID.
- Add Wait for application event and specify its event name and incoming data fields.
- Set the timeout and any condition the event must satisfy.
- Connect the matched and timeout paths.
- Share the dashboard's connection requirements with the application owner, including the business key used to address this run.
The event name and key must match the configured values exactly. A matching name with the wrong key cannot resume the intended run. A condition can compare incoming event data with the run's starting data.
An event processed after the run starts but before it reaches the wait can be retained. An event processed before a matching run exists is not saved for a future run. Queue acceptance does not prove that a wait has resumed; inspect Runs.
Plan the timeout path
The wait's duration begins when the run reaches the wait. The run's 30-day time limit can end it earlier. A timeout means no qualifying event resolved the wait by its deadline; it does not prove the business event never happened.
Choose a timeout action that fits that uncertainty, such as recording a review outcome or asking a team to investigate. Preview both paths before publishing.
Pausing the automation stops new runs, while existing waits can continue. Cancel the run separately when its follow-up work should stop. If the same application event qualifies for cancellation and a wait in that run, cancellation takes precedence.