Skip to main content
Three things shape who flows through an automation:
  • A trigger decides who enters.
  • Filters narrow that entry to the ones you care about.
  • Branches decide where they go once inside.
This page covers all three in plain terms.

​
On-chain triggers

These start a flow from something that happens on-chain. Over twenty are business presets, each built around a moment that matters, plus a generic catch-all for anything a preset doesn’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.
A couple of presets take one extra input. Large transfer asks for the amount that counts as “large,” so set it to a meaningful size for your token. The lending, staking, and NFT presets watch the specific contract or collection you name.

​
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.

​
Off-chain triggers

These fire on things that happen in your audience and your messaging, no chain activity required. Ten are available: Most of these fire on their own, from real activity in your workspace, so there’s nothing to wire up. A few have details worth knowing:
Two triggers are easy to confuse:
  • Health factor crossed is about a wallet’s on-chain lending position. You set the chain, the lending pool, and the threshold, where 1.0 means liquidation, so a value like 1.2 warns the borrower while they can still act. Use it for at-risk-borrower and liquidation-rescue flows.
  • Lifetime value crossed is about a contact’s estimated dollar value to you, and has nothing to do with lending. In the builder this one is currently labelled “Health factor threshold” (a naming fix is on the way), so pick it by the description, not the label.
Also, Date reached uses your team’s timezone, not each contact’s, so “9:00am” means 9:00am where the flow was built.

​
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:
A contact enters an “entered a segment” automation only once, ever. Removing and re-adding them to the segment won’t re-trigger it. If you need a flow people can go through more than once, use a different trigger, or have your system send a fresh event each time.

​
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.