Automations
An automation reacts to something that happened: a form submission, a new contact, a delivered email. It is a graph — one trigger, then conditions, waits and actions wired together — drawn on a canvas.
For the shape of the stored object and how the engine walks it, see the Automations guide. This page is about the editor.
The list
Each automation shows its trigger as a sentence ("When Form submitted — 2 conditions, branching flow") and carries two independent badges:
| Badge | Question it answers |
|---|---|
| Draft / Published | Is it finished? |
| Active / Paused | Is it switched on? |
Both are required to run. A draft never runs whatever the other badge says, which is why Pause and Resume are disabled on a draft and the list shows the draft badge in preference.
The canvas
New automation opens the editor at /automations/new; Edit opens an existing one. You give it a name, an optional description shown in the list, and a trigger.
Triggers are grouped: Forms (form submitted), Contacts (created, updated, deleted), Email (queued, scheduled, delivered, failed), Domains (created, verified, verification lost, deleted) and Channel messages (sent, failed).
From the trigger, you add nodes. There are three kinds.
Condition
Filters on the event payload. Each row is a field, an operator — equals, does not equal, contains, exists — and a value. All rows must match to take the ✓ true branch; otherwise the ✕ false branch runs.
Fields are dot-paths into the event: data.values.plan for a form field, data.properties.plan for a contact property.
Wait
Pauses that branch before it continues — an amount plus a unit (seconds, minutes, hours or days). Everything downstream of the wait resumes later.
A wait can outlive the automation's settings
When a wait resumes, the engine re-checks that the automation is still active and still published. Unpublishing something mid-wait stops it there.
Action
Three types:
| Action | Settings |
|---|---|
| Send email | A published template, a subject, a recipient path (e.g. {{ data.values.email }}), and a From address — a local part plus one of your verified domains. |
| Send channel message | One of your channels, and the message text. |
| Call URL | An HTTP endpoint of yours. |
The editor is honest about what will not work: a template that is not published is labelled "Unpublished template — will not send", and the From picker says so when you have no verified domains. Both would otherwise fail silently at run time, since an automation has no caller to hand an error to.
Every string setting accepts {{ dot.path }} placeholders resolved against the triggering event.
Wiring
A condition node has two outgoing edges — ✓ true and ✕ false. Every other node fans out over all of its outgoing edges. A node that is incomplete says so on the canvas ("Incomplete — click edit to finish"), which is how you find what is blocking a publish.
Node positions are saved with the automation, so the layout you arrange is the layout you come back to.
Draft and publish
New automations in the editor start as drafts, and Save keeps them that way. A draft is held only to the graph's integrity — ids that are unique, edges that land on nodes that exist, correct branch labels, no cycles — so half-built work has somewhere to live.
Publish applies the full rules: exactly one trigger, at least one action, every node reachable, and every node's settings filled in. When the graph does not satisfy them the button is disabled with the reason, rather than letting you press it and collecting a server error.
Unpublish warns first: the automation stops reacting to its trigger until you publish it again.
Creating one through the API is the other way round
POST /v1/automations defaults to published — a client that posts a complete automation expects it to run. It is the editor that asks for a draft.
Runs and metrics
Opening an automation gives you three tabs.
Overview is the graph and its settings, read-only.
Runs is the history. A run is recorded whenever an action node was reached, and it lists one entry per visited node with that node's id, type, status and reason — so a run that did nothing tells you which condition sent it down the false branch. A failing action does not stop the nodes downstream of it, so a run can be partly successful, and the counts say so.
Metrics aggregates: runs over time, a breakdown per action type, and the failure reasons behind them.
The loop guard
Events caused by an automation carry the id of the automation that caused them, and the engine skips those entirely. That is what makes it safe to trigger on email.delivered — an automation that sends email cannot feed itself forever.
It is a blanket rule, so it is worth knowing the other half: no automation triggers on another automation's output either. You cannot chain two automations by having one react to what the other sent.
Quota
Automation runs count against a monthly quota, checked per automation rather than once per event — so one event fanning out to several automations stops at the ceiling instead of overshooting it. Once over, matched automations are skipped with no actions and no run recorded, until the count resets next month. Owners and admins are emailed at 80% and again at the limit.