- A trigger decides who enters.
- Filters narrow that entry to the ones you care about.
- Branches decide where they go once inside.
On-chain triggers
These start a flow from something that happens on-chain. Nine are business presets, each built around a moment that matters, and one is a generic catch-all for anything the presets don’t cover. On EVM chains they fire automatically: the platform watches the contract for you and turns matching activity into automation entries, with nothing to index or configure. See Contract-Based Flows. On Solana, on-chain events are sent in through the Automation Trigger API, a developer task.Business presets: pick your token, done
For a preset you supply one thing: the token or contract to watch. The rest, which on-chain moment to look for, is chosen for you. No event to pick, no signature to paste.
You also pick the chain to watch, though it’s usually filled in from your project settings. That’s the whole setup: pick your token, publish.
Generic on-chain event
When no preset fits the moment, the generic On-chain event trigger lets you name the event yourself. It’s the escape hatch, and the one on-chain trigger where a developer may need to help you match the right event. Everything you set has to agree with the incoming event for the flow to fire.Filters: narrow who enters
A trigger can be narrowed with filters, simple conditions on the details of the event, so only the entries you care about get in. For example: only mints (a transfer from the zero address), or only events where a certain field is present. Filters check for things like “equals,” “is not,” “is one of a list,” “contains,” and “is present.” Every filter you add has to pass. Comparisons ignore case and spacing, so wallet-address capitalization never trips you up.For a numeric threshold, “more than $100,” say, use a branch later in the flow rather than a trigger filter. Trigger filters don’t do greater-than or less-than comparisons.
Custom event triggers
Anything your product does can start a flow. Send a custom event, a signup, a deposit, a plan upgrade, and match it by name. Always name the events you want to match; leaving it blank matches every custom event. The full path, from firing the event to the user seeing an in-app push, is in Custom Events.Lifecycle triggers
Three triggers fire on things that happen inside your audience:- Entered a segment. A contact joins a segment you’re watching.
- Opened an email. A recipient opens a campaign email (optionally, one specific campaign).
- Health score crossed a line. A contact’s health score rises above, or falls below, a number you set.
These, and custom events, fire when your system tells the platform they happened, through the Automation Trigger API. The platform doesn’t invent them on its own.
One entry per event
Each matching event creates one entry, one contact moving through the flow, and duplicates of the same event don’t re-enter. One consequence worth planning around:Branches: route entries down different paths
A branch splits the flow so different contacts take different routes, for example, send an in-app push to anyone with a connected wallet, and an email to everyone else. A branch tests what’s known about the entry so far, and that grows as the flow runs. After a send-in-app step, a branch can check whether the push was delivered; after an add-tag step, it can check the contact’s tags. Rules are checked top to bottom and the first match wins; anything that matches nothing follows the default path.Branches can compare numbers (greater or less than) that trigger filters can’t, and they read the contact’s live context rather than the original event. A branch needs at least two paths out, so draw both connections in the builder.