Key takeaway
An email automation workflow is six things: a trigger, an entry condition, actions, delays, branches, and exits. The emails are the easy part. I've almost never seen one break in the middle where the effort goes; they break at the edges, at who gets in and what pulls them out. Yahoo wants an unsubscribe honoured within two days, and a step already queued doesn't care. Make every exit a check that runs at each step.
What an email automation workflow is.
An email automation workflow is a standing rule set: a trigger that enrolls somebody, an ordered run of actions and delays, branches that send different people down different paths, and exits that take them out of it again. It runs without anybody pressing send. The steps in between are where the build time goes, and they're hardly ever what breaks. What breaks is the rule at either end: who gets enrolled, and what stops the run early. I've been building email platforms for over a decade, and the workflow that went wrong was never the copy. It was somebody enrolled twice, or somebody who unsubscribed at step two and got step three anyway.
The distinction worth making once is against a campaign. A campaign has a send date and one audience. A workflow has an entry rule and an audience of one person at a time, arriving whenever they qualify, which might be nine months from now.
A workflow is a rule you won't read again for a year.
The six parts every workflow is made of.
Every workflow, on every platform, is six things. The screens differ and the vocabulary differs, and the parts don't.
- The trigger: the event that makes somebody a candidate, which is a thing that happened rather than a thing that's true.
- The entry condition: the test applied at that moment, which decides whether a candidate is actually enrolled.
- The action: what the workflow does at a step, usually a send and sometimes a tag, a field update, or an event.
- The delay: the wait between two steps, either a fixed duration or a wait for something to happen.
- The branch: the split that sends two people down two paths, on a test evaluated when they reach it.
- The exit: the rule that removes somebody, evaluated at every step rather than once at the door.
They come in pairs, and each pair has its own failure mode. A trigger with no entry condition enrolls everyone who ever qualifies, including the person who signed up in 2019 and never opened anything. An entry condition with no trigger never fires, because nothing tells the workflow to look. A delay with no exit keeps sending to people who are already gone.
Naming the six is most of the work, and it's the step every builder skips for you. A canvas draws these things and nothing else, so the boxes and arrows are a rendering rather than the rule itself.
Two of the six aren't separate objects on some platforms. Entry conditions get folded into the trigger, and exits get called goals or suppressions. The parts are still the same six whatever the screen calls them.
Entry: who gets in, and whether they can get in twice.
Entry is three questions rather than one, and most builders only ask you the first out loud. The first is whether the same contact can enter this workflow a second time. Re-entry is a setting, the default differs by platform, and almost nobody checks which one they got. A workflow that can enroll the same person twice sends them the same welcome twice, and the second arrives while the first is still running. That's the most common way a workflow embarrasses somebody in public.
The second is what happens to people who already qualified before you switched it on. Some platforms enroll that backlog on activation and some ignore it, and the difference is a quiet Tuesday against four thousand people getting a welcome email eighteen months late.
The third is what happens to somebody who qualifies again while they're still inside. If a customer abandons a second cart on day two of a three-day cart workflow, the platform either queues a second run, restarts the first one, or drops the new event. All three are defensible. Only one is what you meant.
The answer isn't to turn re-entry off. A workflow that runs once per contact is wrong for anything recurring, and a cart flow that fires once in a customer's lifetime is worse than none. Decide per workflow which of the two this one is, and write that decision down next to the trigger.
Delays, and why timing is the part that ages worst.
There are two kinds of wait and they don't behave the same way. A fixed delay is a duration, and it does what you expect: two hours is two hours, and everybody who enters the step leaves it two hours later. A wait-for-an-event delay is conditional, and it only releases somebody if the event happens while they're inside the wait. An event that already happened doesn't count, and an event that happens a minute after the wait expires doesn't count either. That isn't a bug, it's what a window means, and it catches people out because a diagram draws both kinds as the same box.
The fixed kind is where the rot sets in. Timing gets written on the day you build the flow, against the buying cycle you had that quarter, and nothing ever revisits it. A two-hour cart delay and a two-day cart delay are different products: one is a nudge to somebody still at their desk, and the other is a reminder to somebody who has been to work and back. Both are reasonable. Only one was chosen on purpose, and after a year I'd bet against yours being the one.
A delay is also where people pile up. Every contact standing inside a step is somebody your next edit reaches, which is a different problem and the one the testing section below is really about.
Branches, and when a branch should have been a second workflow.
A branch evaluates its test at the moment somebody reaches it, not at enrollment. That's the whole definition, and it's the half that gets missed: a branch on "has purchased" and an entry condition on "has purchased" are different rules, and for a person who bought something on day two they give different answers. The entry condition asked in the past tense. The branch is asking now.
So the judgment is about when to split at all. Split where you'd genuinely write a different email. Don't split where you'd write the same email with a different first line, because that's a personalization variable wearing a branch costume, and it doubles the paths to do what a merge tag already does. Every branch past the second one halves the chance anybody tests the paths, and the untested path is the one a real customer finds.
Past about two branches you don't have a complicated workflow, you have two workflows sharing a trigger. Build them as two. They're easier to read, easier to change, and you can switch one off without touching the other, which is the thing you'll actually want to do at four on a Friday afternoon.
Exits, and the ones that have to interrupt a step already queued.
An exit is a rule that takes somebody out of the workflow, and there are four kinds doing four different jobs.
- The goal exit: they did the thing the workflow was for, so the rest of it is now selling something they already bought.
- The consent exit: they unsubscribed, which has to stop the next step and not just the next campaign.
- The deliverability exit: a complaint or a hard bounce, which suppresses the address rather than pausing the workflow.
- The staleness exit: they no longer match the entry condition, and the workflow keeps checking rather than assuming.
The mechanism is the point: an exit is a check that runs at every step, not a filter at the door. Somebody who unsubscribes at step two has steps three through six already queued behind a delay, and a suppression applied to campaign sends alone won't reach them. I'm blunt about the staleness exit specifically: a list gone unengaged for a year and still getting queued isn't a workflow problem, it's a decision nobody's made yet. Keep emailing it and you risk cooking your whole domain's deliverability for lists that were never the ones causing trouble.
The clock on that check isn't yours to set. Yahoo asks senders to honor unsubscribes within two days, and Google's sender guidelines ask bulk senders for one-click unsubscribe alongside a visible link in the body, plus a spam rate that stays below 0.10% and never reaches 0.30%. Build to two days. It's the tightest number published, a queue that clears in two days clears in anybody's window, and the alternative is carrying two deadlines in your head and using the wrong one. The one-click signal itself is standardized in RFC 8058, which defines the List-Unsubscribe-Post pair and the handling of the request without manual intervention.
Two days is a deadline written for the mailbox provider's benefit, and it isn't the honest answer inside a running workflow. The honest answer is the next step, whenever that falls.
Test the paths that never run.
Testing a workflow is five checks, and "test thoroughly" isn't one of them.
- Enroll a test contact that qualifies. Confirm the trigger fires and the entry condition passes, which are two separate things that fail separately.
- Walk the branch nobody expects. The "didn't click" path is the one that ships broken, because somebody testing their own workflow always clicks.
- Unsubscribe halfway through. It's the only way to find out whether the exit runs per step or only at the door.
- Shorten every delay, then put them back. A workflow tested with its real delays is a workflow tested next month.
- Enroll the same contact again. Confirm the re-entry behavior is the one you decided on rather than the one the platform shipped with.
The other half of this is that editing a live workflow is a release, not a tweak. People are standing inside your delays right now, and changing a step changes what happens to them next on a schedule the canvas doesn't show you. Adding a step at the end is safe, because nobody has reached it. Changing one in the middle isn't, because half the people in flight have passed it and half haven't, and you've just given the two halves different journeys.
None of this covers what the email says. A workflow can be mechanically perfect and still send a bad message to the right person at the right moment. The mechanism is what stops a flow embarrassing you. The copy is still your job.
Write the workflow down before you draw it.
The six parts fit on one page. Trigger, entry condition, actions, delays, branches, and exits, with the re-entry decision sitting next to the trigger and the exit checks listed once. That's a document, and it's shorter than the canvas that renders it.
A workflow that exists only as a drawing in one account can't be reviewed by somebody who wasn't there, copied to a second brand without redrawing it, or compared against what it was last quarter. Written down, it can be all three. It can also be built, because a description precise enough to review is a description precise enough to act on. That's what MCP-first means here: every Nitrosend capability is an API endpoint and an MCP tool before it's a screen, so campaigns, flows, contacts, templates, and segments are things an agent creates, changes, and explains back to you. Every platform in this category was designed for humans clicking buttons, and an agent bolted onto a canvas is still a canvas.
A canvas is genuinely better for seeing a branch laid out, and below a certain size none of this pays for itself. Two workflows you drew last month don't need a specification.
If nobody on your team can say what pulls a contact out of your welcome flow, the problem isn't the builder. The flow was never written down. Nitrosend builds triggers, steps, and branches from that description, through the MCP server, the API, and the CLI. Start free, write your welcome flow down as six lines, and see whether it builds back the same.
Visual builders hide the complexity of automation. We built a "beautiful drag and drop layout" for our own platform, a project we covered on SaaS District. The interface makes the final product look obvious. You still need to write the rules down in plain text before you start moving boxes around.
Go deeper
Sources
- Yahoo Sender Best Practices: the two-day deadline for honoring an unsubscribe, the spam-rate threshold, and the one-click list-unsubscribe requirement for marketing mail.
- Google, Email sender guidelines: the 0.10% spam-rate target for bulk senders and the 0.30% ceiling, and one-click unsubscribe with a visible link in the message body.
- RFC 8058: the one-click signal for the List-Unsubscribe header, the List-Unsubscribe-Post pair, and handling the request without manual intervention.
Common questions
A campaign has a send date and one audience: you pick a list, you pick a moment, and everybody gets it. A workflow has an entry rule instead of a send date, and an audience of one person at a time. Somebody enters it whenever they qualify, which might be tonight or nine months from now, and the workflow runs its steps for them alone.
An event: a signup, a purchase, a form submission, a page visit, a date arriving, or a custom field changing value. The test is that a trigger is something that happened, not something that's true. "Bought in the last 30 days" is a segment; "placed an order" is a trigger. Confusing the two is why some workflows never fire and others enroll the entire list at once.
That depends on the platform, and it's worth settling before you activate anything. Some enroll the whole backlog the moment a workflow goes live, so every contact who has ever met the entry condition starts at step one that afternoon. Others only look forward and enroll nobody until a fresh event arrives. The first behavior is how somebody who signed up two years ago gets a welcome email today. If you can't find the setting, switch the workflow on with an entry condition narrow enough that the backlog is a handful of people you could name, then widen it.
There's no universal number, and picking one is the wrong way round. Count the things you have to say before the exit condition is met, and that's your answer. For most welcome workflows it lands at three or four. If you're adding a fifth because the flow looks thin, you're writing to fill a diagram rather than to reach somebody.
Long enough that the previous email has had a chance to be seen, which for most programs means a day or more between sends rather than hours. There are two kinds of delay and they behave differently. A fixed delay is a duration and does what you expect. A wait-for-an-event delay only releases somebody if the event happens while they're inside the wait, so an event a minute after it expires doesn't count.
No, and the two work at different levels. Suppression sits on the address and applies to everything you send, so it stops mail from any campaign or any flow. A workflow exit applies to one contact inside one workflow, and it leaves them free to enter anything else they qualify for. Neither one implies the other: an address can sit on a suppression list while a workflow still counts that contact as enrolled, and a contact can leave a workflow with nothing suppressed at all. Exit somebody when you want them out of one flow, and suppress the address when you want them to stop hearing from you entirely.
A welcome workflow. The trigger is unambiguous, the audience has just told you they want to hear from you, and the exit condition is easy to name. It's also the one where a mistake shows up fastest, because it's the first thing a new subscriber ever sees from you. Build that one, write its parts down on a page, and the second workflow starts from a document rather than a blank canvas.
Judge it on the thing it exists to cause rather than on opens. A cart workflow is working if more carts get finished, and a welcome workflow is working if more new subscribers make a first purchase or a first login. Then look at the two numbers that tell you it's misfiring rather than underperforming: how many contacts are sitting in each step right now, and how many left through each exit. A workflow nobody exits and nobody finishes is stuck in the middle somewhere.