Skip to main content
An automation is a trigger (the thing that starts it) plus a flow (what happens next). You build both on a visual canvas: drag in blocks, connect them, and publish. This page walks through building one, the blocks you can use, and the publish step that actually makes it live.

​
Build it

1

Start from a play, or from scratch

Forking a built-in play gives you a working trigger and flow as a draft you own. Starting blank gives you an empty canvas.
2

Configure the trigger

For a business preset (Token acquired, Swap completed, Liquidity added, and the rest), you supply just one thing: the token or contract to watch. The on-chain detail is set for you. Only the generic On-chain event trigger asks you to name a raw event. See Triggers and Conditions.
3

Lay out the flow

Add action, wait, and branch blocks and connect them in order. The flow runs left to right, following the connections out of the trigger.
4

Validate

Validation flags blocking errors, which you must fix, and softer warnings, which you can leave. It won’t let you publish something broken.
5

Preview

Preview estimates how many wallets currently match the trigger, with sample profiles. Run this before publishing. A trigger matching zero wallets is the most common cause of a silent automation.
6

Publish

Publishing creates the live version. Without it, nothing runs (more on this below).

​
The building blocks

Seven blocks make up a flow:

​
The messaging blocks

The three messaging blocks (send email, send in-app, launch campaign) send to the contact who triggered the flow by default, or to a specific list of wallets you name. Content is personalized per recipient, so an in-app push supports the same merge variables as email, like {{ greeting_name }}.
  • Send email uses a saved template, or a subject and body you type in. It needs at least one of those.
  • Send in-app uses a title and body, with an optional button (give it both a label and a link for the button to show).
  • Launch campaign kicks off a campaign you’ve already built, aimed at the recipient.

​
Wait

Pause the flow before the next step: a number of seconds, minutes, hours, or days, or “until 9:00am in this timezone.” Waiting contacts are parked and picked back up when the time comes, so a long wait costs you nothing while it sits.

​
Add tag

Tag the contact, one tag or several at once. Useful for marking who’s been through a flow so you can segment or suppress on it later. (There’s no “remove tag” step.)

​
Call a webhook (for developers)

The webhook block pings one of your own endpoints partway through a flow, so your systems can react to what happened. It’s the one developer-flavored block: it needs a public https URL, and it hands your endpoint the contact’s context. The full detail, payload shape, retries, and the security rules, is in Webhooks. This block sends out; to start an automation from your own system, see Contract-Based Flows.

​
Drafts and validation

The builder keeps your work-in-progress draft separate from the saved flow, so you can leave a block half-finished and come back to it. Saving to the main flow validates first, and a few things block a save: an empty flow, no trigger, an email step with nothing to send, a wait with no duration, or a branch with only one path out. A block that isn’t connected to anything is a warning, not an error, the flow still publishes, but that block never runs.

​
Publish

Publishing is what makes an automation run. The runtime executes the most recent published version of your flow. Setting an automation to active without publishing produces one that matches events, creates entries, and does nothing, the hardest failure to spot, because it looks live and the entry count climbs.Publish after every change you want live. Saving the flow is not the same as publishing.

​
When a step has trouble

Steps retry automatically a few times before giving up, and each step only re-runs the one that failed, not the ones before it, so nobody gets a duplicate email on a retry. Different steps handle trouble differently:
  • Send email skips, and the flow moves on, if your sending is paused or every recipient is suppressed. It only retries when some recipients exist but the sends error out.
  • Send in-app quietly drops wallets with no in-app session. It only fails if there’s nobody left to send to.
  • Launch campaign, add tag, and webhook retry, then give up if they keep failing.

​
Watching an entry

Every contact that enters an automation is an entry, and each entry records what happened as it moved through the flow. This is how you answer “did this fire, and where did it stop.” An entry is running, waiting (paused on a wait), completed, or failed, and its history shows when it was created, which steps it reached, which ran, and which were skipped and why (for example “sending paused” or “everyone suppressed”). When an email step sent nothing, check for a skip reason before assuming the trigger is broken. When an automation finishes, it also emits an automation.completed webhook event your systems can subscribe to.
Automation stats (entries, conversions, revenue) are derived from send and delivery records. “Entries” counts trigger matches; conversion and revenue are inferred from event names and metadata, so treat them as directional rather than as an accounting source.

​
Best practices

  • One trigger, one outcome. Add branches only after the primary path is verified.
  • Preview before publishing so you know the trigger matches a non-zero audience.
  • Name automations after trigger plus action, “Mint → welcome series” beats “Automation 3”.
  • Avoid overlapping automations targeting the same wallets on the same event.
  • Test with a real event, then check the entry’s history to confirm each step fired.