Email flow: automation that starts on an event

How it works

A flow has a trigger and steps. The trigger is something that happens to one person. The steps are what to do about it, in order, for that person alone. A post-purchase flow might read:

1. Trigger: purchase.
2. Send the thank-you email.
3. Wait 14 days.
4. If they bought again, stop here.
5. Otherwise, send the cross-sell.

Waits, branches and stops are what separate a flow from a fixed series of emails. A flow can also wait for something: a checkout reminder waits for the purchase, and branches when the wait runs out.

Why it matters

• Timing. An email sent because of what someone just did lands while it matters to them.
• Relevance. Branches mean a customer and a browser get different follow-ups from the same trigger.
• It runs on its own. Once it's live, every purchase, signup or cancellation gets handled the same way.
• Mistakes repeat too. A wrong branch hits everyone who passes through, so testing before going live matters.

How Mimeo handles it

A Mimeo flow starts on any event Mimeo receives: from your site, app or store through the event API, or from Mimeo itself, such as tag_added, field_changed and sequence_completed. Flows can also start on an approaching subscription renewal or end, or on a stretch of inactivity. Steps send an email, start a sequence, add or remove a tag, set a field, wait, wait at a gate, branch, fire an event, exit or prune.

Each flow is one validated JSON definition. You edit it in the diagram, or your agent edits it through the API or MCP. A dry run walks a real person through the flow with their real data and sends nothing. Activating checks the definition first, every activation is saved as a version you can roll back to, and pausing holds the emails already queued. See Mimeo terms for flows, triggers and runs in Mimeo's own words.