Email Automation Workflows Explained (2026)

An email automation workflow is a rule that sends email without anybody pressing send. It has four kinds of part, and every platform in this category is built from the same four, however differently they are named: a trigger that starts it, a wait that holds it, a condition that decides which way it goes, and a send that does the thing.

Understanding that matters for a practical reason beyond tidiness. Platforms meter these parts, and they meter different ones — so the number of steps in your sequence is what decides which plan you need, and you can count it before you spend anything.

The trigger: what starts the run

Something happens, and the workflow begins. In practice, triggers fall into three families.

• List events — somebody subscribed, was added to a segment, or was tagged. Every platform supports these and they are the simplest to reason about.
• Email behaviour — somebody opened, clicked, or did not open within a window. Every platform supports these too, and they are less reliable than they were, because privacy features in mail clients now open messages on the recipient's behalf.
• Product or commerce events — somebody bought, abandoned a cart, started a trial, or created their first project. These need data sent from your product or store, and support for them varies enormously. Platforms built around this, such as Encharge, make it the centre of the product; general email platforms treat it as an integration.

The trigger is where most poorly performing automations go wrong, and almost never for a technical reason. A trigger that fires on "subscribed" sends the same welcome to somebody who found you through a careful comparison and somebody who typed an address to get a discount. Splitting that at the trigger is usually better than splitting it three steps later with a condition.

The wait: the part beginners skip

A wait holds the contact at a point in the flow — for an hour, three days, until next Tuesday, or until something happens. It is the least glamorous part of a workflow and the one that most changes how the sequence feels to receive.

Two kinds are worth distinguishing. A fixed wait counts time. A conditional wait pauses until an event occurs or a deadline passes, which is what you want for "give them two days to finish setting up, then help if they haven't". The second is considerably more useful and slightly less widely supported, and it is worth checking for by name on any platform you are evaluating.

The common mistake is having no waits at all, so a five-email sequence arrives over five hours. The second most common is having waits that ignore the reason for the sequence — a three-day pause in an abandoned-cart flow, by which point the cart is a memory.

The condition: where the branching happens

A condition checks something and sends the contact down one of two paths. Did they open the last email? Are they in this segment? Have they bought? Is the value of their order above some threshold?

This is where automation stops being a scheduled newsletter and starts being worth paying for, and it is also where the step count grows fastest, because every branch needs its own continuation. A single condition with two outcomes is three steps, not one — the check and both paths.

Keep branches shallow. A workflow with four nested conditions has sixteen possible paths and nobody, including its author, knows what all sixteen send. Where the logic genuinely needs that much nuance, it is almost always better as two workflows with a clear entry rule than one with a decision tree.

The send: the only part the reader sees

Everything above exists to get the right message to the right person at a defensible moment. The send itself is the simplest part of the workflow and the one worth the most of your attention, because no amount of branching rescues an email nobody wants.

One structural point rather than a copywriting one: a send inside an automation should be able to stand alone. Readers do not experience your sequence as a sequence — they get one email, possibly having ignored the last two — so an email that only makes sense as step four is an email that mostly does not make sense.

How platforms meter these parts, and why it differs

Now the part that costs money. Platforms ration this structure in three different units.

• Actions per automation. ActiveCampaign's Starter plan allows five actions per automation, where an action is any step — a wait, a condition, a tag or a send. It limits depth, not quantity.
• Number of workflows. GetResponse's Starter plan allows one custom automation workflow, of any depth. It limits quantity, not depth.
• Active journeys. Mailmodo's Lite plan allows one active journey, counting only what is running rather than what is built. HubSpot's free tier allows one automated action, and Starter up to ten.

These are genuinely different constraints and they suit genuinely different businesses. A shop with six simple triggers is fine under a depth limit and stuck under a quantity limit. A business with one elaborate onboarding flow is the opposite. Working out which you are is the single most useful thing you can do before choosing a plan.

Counting your workflow before you buy

1. Write the sequence as a list, one line per step, including every wait and every condition. Do not summarise — "then follow up" is not a step, it is three.
2. Count the lines. That is your action count, and it is what a depth-limited plan measures you against.
3. Count the separate sequences you want running at the same time. That is what a quantity-limited plan measures.
4. Add the branches: each condition's second path is its own set of steps.
5. Take both numbers to the pricing page and find the plan whose cap exceeds them, with room to grow.

Ten minutes of this beats any amount of feature-comparison reading, because it converts "I want good automation" into two integers you can check against a published limit. The comparison of what each platform's plans actually allow is laid out for exactly that, and if a person will pick up the conversation when the sequence ends, the CRM-plus-automation page covers the suites built for it.