Not a linear drip sequence with branching bolted on. A proper node graph: triggers, sends, waits, conditions, operations and webhooks — wired however the flow actually runs.
Not "dozens of triggers" — twelve, named, so you can check right now whether the one you need is on the list.
There is no hidden linear sequence underneath. What you draw is what runs.
Condition nodes branch on open or click. That is the whole list.
We would rather you knew that now than after you had rebuilt your onboarding flow.
Plenty of tools imply that any field can gate any branch. Ours does not, and pretending otherwise would just waste your afternoon.
A condition asks one of two questions: did they open, or did they click. You can point it at a specific email or even a specific link, and give it a timeout — wait 48 hours for the click, then take the "no" path regardless.
In practice this covers most of what onboarding, re-engagement and nurture flows actually need. When you want to route on stored data instead, do it upstream: use the tag-added, tag-removed or attribute-update triggers, or a segment on the entry list.
An operation node acts on the contact as it passes through — which is how one automation feeds the next one.
Tag a contact mid-flow, and — because tag-added and tag-removed are themselves triggers — hand them straight to another automation.
Copy keeps them where they are. Move takes them out. Graduate a trial contact into the customer list without touching a CSV.
Set a custom field with equals, not_equals or contains. Your stored data stays current while the flow is still running.
Wait takes an ISO-8601 duration. Wait-until holds the contact to a point in time. Both are nodes, so both can sit anywhere in the graph.
Any HTTP verb, to any URL you control. Tell your billing system, your CRM, your Slack, your own database — while the flow is still in progress.
Send nodes pull from the same reusable template library your campaigns use. Build it once, use it in both. Templates →
Automations fail in boring ways: someone is stuck at a node, a webhook 500'd, a contact should never have entered. Every one of those is fixable from the contacts panel.
Each automation has its own contacts panel listing everyone currently inside it and where they are. From there you can manually trigger a contact into the flow, hold and unhold them, advance them past a node they are stuck on, retry a failed step, or retry-all when a downstream service was down and a batch of them failed together.
No support ticket. No waiting for someone else to run a script.
An automation is not one number. It is a graph, and each email inside it performs differently — so each one is measured separately.
Not an aggregate for the whole automation. The third email in the sequence has its own open rate and its own click rate, because that is the one you need to rewrite.
Where the engagement came from, per send node, built on GeoIP.
What bounced on that specific email, so a deliverability problem is traceable to a node rather than to "the automation".
The same infrastructure that has delivered 13.5M+ emails for 2,900+ businesses across 3.3M contacts under management.
A real graph. Nodes — trigger, send, wait, wait_until, condition, operation, webhook — connected however the logic requires, including branches that rejoin or end separately. There is no linear sequence hiding underneath the canvas.
Not with a condition node. Condition nodes branch on open or click only — optionally scoped to a specific email or a specific link, with a timeout. To route on stored data, do it at entry instead: the tag-added, tag-removed and attribute-update triggers all key off your data, and you can start an automation from a segmented list. We would rather tell you this up front than let you discover it halfway through building.
Open the automation's contacts panel. You can manually trigger a contact into the flow, hold and unhold them, advance them past the node they are stuck on, retry a single failed step, or retry-all when a batch failed together — usually because something on your side was down when a webhook fired.
Yes, two ways. The API-triggered trigger lets your application start a flow. The webhook node lets a flow call you back mid-run with any HTTP verb to any URL you control — so your billing system, CRM or database can act on the contact while they are still moving through the graph.
A wait node takes an ISO-8601 duration — two days is P2D. A wait_until node holds the contact to a specific point in time instead. Both are ordinary nodes, so they can sit anywhere in the graph, including on one side of a branch and not the other.
Individually. Each send node has its own report: opens, clicks, an open map, a click map, and a bounce log. An automation's performance is not one aggregate number, so we do not present it as one.
Twelve triggers, a real graph, and a panel that lets you unstick anyone.