Triggers
Any event the platform already emits can be a trigger: everycontact.*,
email.*, domain.* and mailbox.* event listed under
webhooks. Or a custom event from your own code:
Steps
Steps run in order. A wait schedules the rest for later rather than holding
anything open, so a run can wait a week without costing anything in between.
Enabling an automation resolves what its steps point at: the sender must be on
a verified domain, and any template or contact book must still exist. If one
does not, enabling is refused and the message names the step - better there
than as a run that fails quietly once per event.
Editing a running automation
A run executes the steps it started with. A wait can hold one for days, and editing the automation in the meantime does not reach back into runs already underway - they finish the sequence they began. New runs use the new steps.Runs and metrics
Each run records every step it took, with a timestamp and what happened. A failed step fails the run and says why; nothing after it runs. Disabling an automation cancels any of its runs that are waiting, rather than letting them finish - if you turned it off, you meant it. Not every failure is final. A step that failed for a reason that might pass - a webhook answering 502, a send that timed out - is retried with backoff before the run is given up on, and the run then says how many attempts it took. A step that failed for a reason retrying cannot fix - a webhook answering 404, an event with no recipient - fails the run immediately. Runs and custom events are kept for ninety days, which is the longest window the Runs and Metrics tabs offer. The Metrics tab counts runs by outcome over a window you choose.The recipient comes from the event. An email event names its recipient, a
contact event names the contact, and a custom event takes an
email field. An
event with no recipient still starts the run, but a step that needs one - send
email, add to contact book - fails it.