Help · Content

Automations

An automation sends email on its own when something happens. Somebody joins your list, reaches checkout, places an order, or their parcel goes out for delivery — the automation starts for that person and carries on by itself from there. Some of those are things they did; some are things that happened to their order. Either one can start an automation.

That is the whole difference between an automation and a campaign. You decide when a campaign goes out. An event starts an automation. Either one can hold several emails; only the starting point differs.

Two things are worth knowing before anything else, because they are the two that surprise people. Nothing you change reaches anybody until you publish it, and no automation reaches anybody at all until you turn it on. They are separate acts, done in that order.

The Automations screen lists what you have built, most recently changed first. Each row carries the automation’s name, a sentence saying what starts it, its status, and how many people are moving through it right now.

Search narrows the rows by name. Type more than one word and every one of them has to match, wherever each of them falls and in any order. The Status pulldown narrows to Draft, Off, Live or Paused. Both keep their place in the address, so going back returns you to the view you were looking at.

Paging. Under the table you choose how many to show at a time — 25, 50 or 100 per page — and step through with Previous and Next. The line beside them says where you are: Page 3 of 5. Type a number in the box to jump straight to a page. The page you are on is part of the address, so opening an automation and coming back puts you back where you were, and the size you choose is remembered the next time you open this screen. Searching or changing the filter takes you back to the first page. The four numbers above the table always count your whole store, whatever the search or the page is showing.

The four words mean four different things, and the first two are the pair people get wrong:

A row marked Unpublished changes has edits waiting in it. That is not a warning — you can leave a change sitting for a week on purpose. It only means that what is running is not yet what you last wrote.

Pressing a name opens that automation’s own page — except on a Draft, which opens straight into the editor. There is nothing to report on an automation you have never published, and carrying on building it is what you came to do.

The at the end of a row holds everything else you can do to it without opening it: Edit, Turn on or Pause, Make a copy, and Delete. Turning one on asks first and says who will enter it from now on; pausing asks nothing, because it stops mail rather than starting it. Turn on cannot be pressed on an automation you have never published — it stays in the menu and says why, rather than disappearing. Delete asks before it does anything, and cannot be undone.

You only see what your seat can do. Turning an automation on is the one act that asks for more than the rest, so a seat that cannot do it is not shown the switch at all — here or anywhere else.

Create automation opens a set of starting points. Each one builds a real, working automation you can then change however you like, and each email inside it is a starting point rather than finished copy:

Welcome and Evergreen both start when somebody joins one of your lists, so on a store with no lists yet they cannot be built and say so:

Blank is the one that starts with nothing decided, and it means that literally: Which event opens with nothing chosen. Blank opens straight onto that question rather than onto an empty list of steps, because deciding what starts it is the one thing you cannot skip — and until you answer it, Publish and Turn on both say Choose what starts it. Nothing is running and nobody is entering while it sits there, so there is no hurry; what there is not, is an automation quietly set to something you never picked.

Browsed product and Added to cart both leave on their own, because the person has moved on to the next automation. Anybody who places an order after entering leaves either of them. Anybody who reaches checkout leaves both — from there they are Abandoned checkout's. And anybody who adds something to their cart leaves Browsed product, because from there they are Added to cart's. Two automations chasing one person about one product is what nobody wants.

Those rules show on the Automation filter card as a sentence rather than as rows you can edit. They are in force exactly as written, and Remove the rule takes them off if you would rather write your own.

Back in stock is named on the empty screen and is not yet something you can build. Nothing in this app records that a product came back, so there is no honest way to start an automation on it.

An automation opens as a column of steps with a map of the whole thing beside it. The column is where you work; the map is something you read and click, never something you draw on. Open a step and the column becomes that step’s panel, with Back returning you to the steps.

When the step you have open is an email, the space beside the column shows that email at the size it will be received.

Everything you change is saved as you go, into a working copy. The mark beside the name says where that has got to — Saving…, Saved, or, if something went wrong, Not saved yet — still trying. None of it reaches anybody. The version that is running is untouched until you publish.

The trigger card sits at the top of the steps, and it is the automation’s one setting. Opening it shows everything about how people enter and leave.

Starts when is the trigger itself, and it is the first thing the card asks. There are three kinds:

An event is not always something the person did, and the sentence says so. An order goes out for delivery because your carrier moved it, not because anybody pressed a button, so an event trigger reads When Out for Delivery happens rather than naming a person who did nothing. A list and a form are different — somebody really is added to a list, and really does fill in a form — so those two read When someone is added to Newsletter and When someone submits Signup.

Which event is asked first, and it offers every event this app can produce, not only the ones your store has had. That is what lets you build the delivery automation before the first delivery: a name your store has not recorded yet is offered and marked no activity yet, which is a fact about your store rather than about the event. Names your own data already carries are offered too, including whatever an integration has been sending you. The field shows the event you chose; type in it and the list under it narrows to the names that match, then pick one with a click, or with the arrow keys and Enter. Escape puts back the event you had.

The event is named exactly as your data records it, never re-worded:

The parcel events, and the one thing to know before you build on them. A shipment reports its progress in nine steps, and each one is offered as its own event: Label Printed, Label Purchased, Confirmed Shipment, In Transit, Out for Delivery, Attempted Delivery, Ready for Pickup, Delivered Shipment and Shipment Failure. They all describe one parcel, so they all carry the same tracking number, and Delivered Shipment is the one that says it arrived — it is named that way so it is never mistaken for Delivered, which on a report of yours means an email the email provider accepted.

An order you call off is its own event tooCancelled Order, the moment you cancel one in your store. It keeps the spelling the other service gives it, so a store arriving from there finds one history rather than two.

Not every carrier reports every step, and some report none. These events are only as good as what your carrier tells your store, so an event here can sit at no activity yet for ever on a store whose carrier is quiet. Check the Metrics page before you build a sequence a customer would notice the absence of.

Tagging somebody in your store is an event here, and an automation can start on it. Two events cover it — Tag Added and Tag Removed — and each one carries the tag itself as a property called tag. So "when somebody is tagged VIP" is an event trigger on Tag Added with one rule under Only when the event says: tag is VIP.

That is how a tag you already keep by hand becomes a starting point. Tag your wholesale customers and they get the wholesale welcome. Tag somebody who left a review and they get the thank-you. An app of yours that tags people in your store starts your automation the same way, without either of you wiring anything up.

Three things are worth knowing before you build one.

Only a tag added in your store starts anything. These events come from your store telling us a tag changed. A tag that arrives any other way — a reconciliation we run to catch a store's tags up, or the day you first connect — starts nothing, deliberately: catching up on twenty thousand people's tags would otherwise send twenty thousand emails about things that happened years ago.

Nothing starts unless something actually changed — once we know what somebody already had. Re-saving a customer record can tell us VIP was added to somebody who has had VIP for a year. We compare it with what we already hold, and a tag that was already there is not news, so nobody enters twice because a team member opened their record. For anybody whose tags we have not seen before, we have nothing to compare with — the first time your store tells us a tag was added to one of them, that counts as news even if they have carried it for years. Before you point an automation at Tag Added, ask us to catch your store's tags up; after that, a re-save starts nothing.

A tag being taken away needs us to know what somebody already had. Adding is different: your store tells us the tag it was just asked to add, so Tag Added starts an automation whether or not we have heard about that person before. Tag Removed cannot work that way — a tag removed from somebody whose tags we have never seen looks exactly like nothing happening, so we record what your store told us and start nothing that first time. Every change after it is news as usual. This only affects people who were already in your store before you connected it; for anyone added since, we know from the start. If you want removals live for everybody, ask us to catch your store's tags up first.

The tag is matched exactly as your store spells it. VIP and vip are two different tags to this rule, because that is how your store keeps them. Copy the tag out of Shopify rather than typing it from memory.

Where it comes from is answered where there is one answer and asked where there is more than one. A few events can only ever reach you a single way — an order placed in your store, or a discount code this app handed out — and for those the card names that way instead of asking you to pick it. Most events can also be sent to this app directly by an integration of yours, so both doors are shown, both switched on, and either one is yours to turn off. An event this app does not produce at all — one only an integration sends you — is asked about for the same reason: there we cannot know.

Leave at least one door on. An automation starts only from the doors named on the card, so an event that can come from nowhere starts nothing.

Once an automation has been live, its trigger is fixed. Everything else about it can still change; the starting point cannot.

Automation filter is the rule for the automation as a whole, and the card says when it is looked at.

With no rule on it, the card says so rather than showing you an empty builder.

Being checked before every step, and not only at the start, is what makes it useful: an abandoned-checkout automation keeps somebody in it only while they have not bought, so the person who buys after the first email is never sent the second. Its rows can count in hours as well as days ("placed an order in the last 2 hours") — a segment's rows count in days only, because a segment is not standing next to a clock the way an automation is.

Enter again? is the last setting on the card, because it is the last thing there is to decide: what happens the second time somebody does the thing. Once per person ever, after a number of days, or every time it happens.

Send email. A send step always has an email — it is made with the step and cannot exist without one. Its subject and its From name live with the email, so there is one place to write each, and Edit this email opens it in the email editor. The From name is who the person sees it from: leave it empty and the step sends under your store’s own From name from Settings → Store, or set one for this email alone — “Debra @ Mommy Makeup”, say, if a particular person should appear to be writing. Changes to the email reach people only when you publish the automation: a running automation keeps sending the email as it was at its last publish. The panel also sets which stream it goes on:

Wait. How long before the next step, in minutes, hours or days, up to a year. A wait can also be told to continue at a particular time of day, or only on particular days. Every one of those runs on your store’s clock, not the recipient’s, and the note beside the switch names the zone — Store time zone: America/New_York, for a store in New York.

Your store’s frequency limit still applies to what an automation sends. A single send step can be told to ignore it, but not on an automation that can be started from outside — the limit is what bounds how much a made-up event could send:

Split. Several paths, each with its own rule, and a last one that cannot be removed:

After a split, everyone carries on with whatever comes below it.

A Send email step can carry a rule of its own: Send this email only to. It is built from the same rows a segment is built from, and the note under the heading says what it does.

It is not the automation filter, and the difference is the whole point. The automation filter decides who is in the automation at all, and somebody who stops matching it leaves and is sent nothing more. A send filter withholds one email. Nobody leaves, nothing ends, and everything after it still happens for them.

Only a Send email step can have one. A wait has nobody to filter, and a split is already how you send different people different things.

The map marks a send step that is not going to everybody, and previewing as a person says, for that person, which emails would be sent and which would be skipped.

A rule built somewhere this panel cannot draw — imported from another tool, say — is shown to you as a sentence and left exactly as it is, rather than quietly rewritten into something simpler.

When you add a Send email step, the first thing offered is Start from a template: one of the templates your store has saved, with a search field over them. Writing a new email from a starting point is still there, as the other choice.

A copy is made, and the picker says so before you choose.

The template's content is copied into an email that belongs to this step, and there is no live link back: editing that template afterwards changes nothing this automation sends.

It goes the other way too. An email you built inside an automation can become a template: open it in the email editor, open Versions, and use Save as a new template on the version you want. What you get is a template like any other, and any automation or campaign can start from it.

A store with no templates yet is told so, and offered the blank email instead.

A step is draft or live. A message — a step that reaches somebody, which today means an email — has a third setting, Manual, and picks between the three from one pulldown on its panel: Draft, Manual or Live.

A draft message is skipped and everything else carries on, which is how you add a new email to something that is already running without anybody receiving it before you are ready:

New steps arrive as drafts for exactly that reason:

A live message goes to everyone who reaches it:

And a manual message holds everyone who reaches it until someone on your team sends it — see Manual messages below:

Turning a message on is something a marketer, manager or owner does — and setting one to Manual counts as turning it on. A viewer can read an automation and change none of it. Everyone else can build a message, write its email and publish it — and publishing a message that is on, or turning one on that was a draft, is the act that starts mail going through it, so it asks for the same permission as turning the automation on:

A wait or a split is not a message. Neither one reaches anybody, so turning one on asks nothing beyond being able to edit the automation at all — only the messages ask.

And nobody at Carpe Messaging can turn a message on for you, whichever role we are looking through while we help. We can write it and leave it a draft; the press is yours.

Nor can we publish into an automation that is already running. While we are helping, we can build an automation you have not started yet and publish it for you — that sends nothing, because nobody is inside it. The moment an automation is live or paused, publishing it changes mail that is already on its way to people, and that press is yours as well.

Turning a message back off never asks: stopping mail is never harder than starting it.

The automation is Draft, Off, Live or Paused. Only a live automation takes anybody in at all:

Publishing does not turn anything on, so an automation you have just published reads Off rather than Draft. That is the whole difference between the two words: Draft means there is nothing published to run, Off means there is and you have not started it.

Pausing stops everybody where they are. Nothing is lost, and resuming picks them up again:

A message set to Manual is a checkpoint. Everyone who reaches it stops there and waits, and nothing is sent to them until someone on your team looks and decides. Use it when you want to see who an email is about to reach before it goes — the first week of a new win-back email, say, or a message that offers a discount.

Where they wait. The automation's own page lists every Manual message with people waiting at it, and how long the oldest has waited:

Open one and you see what they would be sent — the email exactly as it was published, or the text's own words — and who is waiting and since when.

Release sends it to them. Choose some people and press Release, or press Release everyone at the top. They are not sent it by the press itself — they go back into the automation, which sends it to them on its next pass, one by one, the way it sends every message:

For a text, the sentence says they are texted it.

You release the email you are looking at. If a publish changes that email while the page is open, nobody is moved; the page says so and shows the new email, and you press again once you have seen it. If you release people and a publish changes the email before they are sent it, they go back to waiting, so nobody is sent an email nobody on your team released — unless that publish also set the message to Live, which sends it to everyone who reaches it. Release waits until the email has appeared on the page.

So releasing somebody never gets round anything: consent, unsubscribes, the automation's own rule about who stays in, a message's send filter, your quiet hours and the Frequency limit all still decide, exactly as they would for a live message. Release someone while the automation is paused and they are sent it when you turn it back on.

Skip moves them on without it. They are not sent that message and carry on to whatever follows it in the automation — the next wait, the next email — or finish, if it was the last step:

A wait after a Manual message counts from when you release them, not from when they arrived. Somebody who waited a week and is then released still gets the two-day gap you drew before the next email.

Who can release or skip. A marketer, a manager or an owner — the people who can turn a message on. A viewer can see who is waiting and change nothing. Nobody at Carpe Messaging can release or skip anybody for you, whichever role we are looking through while we help.

The publish dialog says which of these a publish will do, before you press it.

Out of the box, people wait at a Manual message until somebody opens the automation and sees them. If you would rather be told, a manager or owner can turn on Email the team when people start waiting at a Manual message in Settings. It is off until you turn it on.

When it is on, the moment somebody starts waiting at a Manual message that had nobody waiting, everyone on your team who can release them gets one email with a link to the people waiting. It is one email per queue, never one per person: nobody is emailed again about that message until everyone waiting there has been released or skipped.

Turning it on does not email you about queues that are already there. A Manual message whose queue starts after you turn it on gets an email. One that already has people waiting when you turn it on gets none until everyone waiting there has been released or skipped; the next person to arrive after that starts a new queue, and your team is emailed. Anybody already waiting is on the automation's page, as before.

Publish takes your working copy and makes it the version that runs. Before it does, it tells you which kind of publish this one is.

Nobody is inside an automation you have not started, so there is nothing to disturb and nothing goes out. The button says Publish, as it does everywhere, and the question tells you what this one does:

That is the ordinary act of getting an automation ready, and it is one of the things we can do for you while we are helping — see Draft and live, twice over, above. Once the automation is live or paused, publishing changes mail that is already going out, and everything below applies.

If you have only added steps, nobody is disturbed:

If you have changed, moved or removed steps, the people already inside have to be moved onto the new version, and the automation sends nothing to them while that happens. The screen names how many people that is and how long it usually takes — normally under a minute.

Publishing an automation also publishes the emails in its send steps, so what goes out is what you last saw:

That is worth reading twice, because it is the thing people get wrong. Editing a send step's email — even saving a version of it in the email editor — changes nothing that anybody receives. A live automation keeps sending the email it was published with until you publish the automation again. If a step's email has moved on without the automation, the step says so, and publishing is what makes it go out.

If anybody has been all the way through this automation before, publishing asks whether they should get the new steps: everyone, only those who finished recently, or no one — as long as you are somebody who can turn automations on.

This one emails people. It is the one question in the dialog whose answer puts mail in somebody’s inbox, so it is asked plainly and it says so:

"No one" is the answer that sends nothing.

If you cannot turn automations on, you are not asked. You can still publish anything that stays a draft — bringing people back is one of the two parts that email people, and neither is a piece this seat does. The other is turning a step on, under Draft and live, twice over above. The dialog says the count anyway, because it is worth knowing:

Publishing does not start an automation. Turn on does, and it asks once, naming what will happen and how many of the steps are live.

An automation that has never been published has nothing to run, and says so:

Turning an automation on is your store’s own act. Marketers, managers and owners can do it — the person who builds the automation is the person who starts it — and a viewer cannot. Nobody at Carpe Messaging can, either, however we are looking at your store to help you: we can shape what would be sent, and we can pause something for you, and that is where it stops. Pausing takes no confirmation, because it is the act that stops mail rather than starts it.

A row on the Automations screen opens that automation’s own page — unless it is a Draft, which opens the editor instead — and that page is where you find out what it is actually doing. It names what starts the automation, whether it is on, and what is happening inside it right now. Edit opens the editor from here, and the switch that turns an automation on and off is on this page as well as in the editor, so you can stop something without opening it up.

It is a report, so anybody who can read your store can read all of it. Turning the automation on is still the one act that asks for more, and a seat that cannot do it is shown no switch at all rather than one that refuses.

A deleted automation still has this page, and it says so. Its badge reads Deleted, there is no switch on it — there is nothing left to turn on — and the line under the badge says that nobody is in it and nothing more will be sent from it. That line is the whole page: the report below it is not drawn at all, because deleting ended every run, and three zeros over "nobody is waiting" and "nobody was turned away in the last thirty days" would be a measurement of something that can no longer happen.

Three numbers: how many people are moving through the automation right now, how many have been all the way through it, and how many left it before the end. A zero is a measurement rather than a gap — it means nobody is in that state.

Under the progress numbers is what this automation's email did: six counts for the automation as a whole — Sent, Delivered, Opened, Clicked, Bounced and Marked spam — and then the same six for each step, one row apiece, in the order the steps run.

Sent is everything that left: what was delivered, what bounced, what was marked spam, and what is still on its way. Tests you send yourself are counted nowhere here, because a test is a message to you rather than to your audience.

Delivered shows a dash rather than a zero until something has come back. Your email provider confirms each message separately, and a zero nobody has confirmed is not a zero — it is a question with no answer yet, and the dash says so where a zero would have lied.

Opens are the one number to read loosely, and the sentence beside them says why:

A step you have since removed keeps what it sent. Those emails were sent, so they are still counted — together, in one last row for steps that are no longer in this automation, because the names of those steps went with them.

Not sent, and why is underneath: every email this automation did not send, counted by reason, in the same words the Refusals page uses.

Two things are deliberately not counted here, and the page says so rather than leaving you to wonder:

These counts are everything the automation has ever sent, not a date range. An automation that has sent nothing yet shows zeros, which is a measurement rather than a gap.

Where those people are standing. One row for each step somebody is waiting at, how many are waiting there, and when the next of them moves. The times are on your store’s clock, like every other time in the app. A step nobody is waiting at is not listed, and somebody whose next step is already due is shown as due rather than given a time.

One row can say On a step the last publish removed. Publishing a change that took a step out does not throw away the people who were standing at it — they are moved onto what you published, and until that finishes they are here, under that name rather than under a step that no longer exists. Everybody in that position is one row, however many removed steps they came from, with the soonest of their times. The row goes when the move finishes. A row that stays is the sign a publish did not finish, and the page says that above.

Held lists the people whose next email is waiting on a rule of your own rather than on the automation: your store’s frequency limit, the hours you send in, or the days you send on. These people are still getting it. Each of those clears by itself, and nothing here is dropped.

They are also counted in the waiting numbers above, because somebody held is somebody still waiting at a step. So do not add the two together — held is a note about some of the people already counted, not a second group.

Who reached the trigger and was not let in, and why. It counts people, not attempts, over the last thirty days: somebody the automation turned away four times in that window is one person here rather than four. The window is named on the screen, and it is there because these records are kept and would otherwise pile up without end.

A wall of "the site had not seen them yet" means the tracking on your storefront is not reporting. That automation only reaches people your site saw before they checked out, which is the whole reason it is defensible, and if that sighting never arrives nobody is entered — quietly, with no error anywhere. If that number is large and the others are small, tell us: the tracking is something we set up with you rather than something to fix on this screen.

Publishing a change that moved or removed steps has to move the people already inside onto the new version, and while that is happening this page says so and says how many have moved so far. It cannot say how many are left, because that is not something it counts — what it can tell you is that the move is running and how far it has got. Nothing goes out from the automation to those people until it finishes. A publish that only added steps stops nobody, and the page says that instead: people carry on and meet the new steps when they reach them. The editor says the same thing while you are working in it.

If the move could not finish, the page says so, and what to do about it is to publish again. Until somebody does, the people still inside carry on running the version they were already on — which can still contain a step you removed.

The abandoned-checkout starting point mails people who got as far as checkout and never gave you consent to email them. That is lawful in some places and not in others, so this one automation asks somebody to read the position and accept it before it can go live:

One named person accepts it, once, for that automation, and the screen records who and when. Until then:

There is no geography check. This app does not work out where a person lives and hold the email back. Accepting is your decision about your own audience, and it is per automation rather than a setting for the store.

The person who accepts is the same person who can turn the automation on. We cannot accept it on your behalf.

And one honest limit. This automation only reaches people your site saw before they checked out, because that sighting is what makes the whole thing defensible:

If the tracking on your storefront is not working, checkouts arrive with nothing behind them, and those people are simply not entered — quietly, with no error anywhere. If an abandoned-checkout automation is live and almost nobody is going into it, that is the first thing to check.

A send step’s panel has Send test, which mails the email you are looking at:

A test goes through the same checks a real send does, so it can be refused for the same reasons, and the refusal names the reason for that person.

Every publish is kept. The Versions drawer in the automation’s menu lists them with who published each one and when.

It covers which steps exist and how they are set. An email’s own history lives with that email, in its editor.

Restore on a row loads that version back into your working copy. It publishes nothing and it mails nobody — what is running keeps running until you publish again. It replaces the whole working copy, so any unpublished change you had is gone, and the question says so before it happens.

The name at the top of the editor is the name. Press it, type, and press Enter or click away to keep it; Escape puts the old one back. An empty name is refused and the name you had stands. Two automations in one store cannot share a name.

Make a copy is in the editor’s menu, beside Versions. It gives you a new automation holding the same trigger, the same steps and a copy of each email, named after the one you copied, and it opens the copy so you know it happened. The copy is a draft: it is not live, it has published nothing, and nobody is in it.

Copying is also the way past the one thing that cannot change. Once an automation has been live its trigger is fixed, because the people already inside it entered on that trigger. The rest of the trigger card still changes — who it narrows to, how often somebody can re-enter — but the starting event does not. Make a copy and change it there.

If the automation you are copying mails people who reached checkout, the copy still needs somebody to read and accept that position on it. A signature is not a thing that copies.

Delete is at the foot of the same menu, and it is the one act in the editor that cannot be undone. Everybody moving through the automation stops where they are and gets nothing more from it, it comes off your Automations screen, and there is no way to bring it back. It asks first and says all of that before it does anything.

There are two of these behind the one word, and the question tells you which one you are about to get. If the automation has never been published and nothing has ever run in it, there is no history to keep, so Delete really deletes: the automation and its steps leave your store and the question says so. Everything else — anything you have published, even once, and anything people have moved through — is kept instead. It comes off your Automations screen and stops sending, and you can still open it and read what was in it. Either way, nothing you have already sent is touched.

Deleting from inside the editor takes you back to your Automations screen, because the automation you were editing is not there any more.

What it has already sent stays. Those emails are still in your reporting and still on each person’s profile, where the row names the automation and says it was deleted. You can still open a deleted automation and read what was in it — its page says View the steps, and the editor opens with everything showing and nothing to change: no Publish, no way to add or move a step, and a line at the top saying why. If what you actually want is for an automation to stop sending for now, that is Pause, and a paused automation can be turned on again.

Preview sits in the editor's header, beside the switch that turns the automation on. Search for anybody in your store, and the map answers for them: whether they would enter and why not, which boxes their path never reaches, and what would happen at each email.

Nothing is emailed, and the window you pick the person in says so. It is a question, asked of the same checks a real send would go through, and it writes nothing down.

The boxes that person's path never reaches are drawn with a dashed edge and their name struck through, and the line under them says they are not on that person's path. It is meant to be unmissable: a box that is merely fainter reads as less important, when what it means is "not this person".

It offers everybody, including people who have unsubscribed, people whose address must never be mailed and people whose identity was never confirmed — because "why is this person not getting my welcome email" is exactly the question this answers, and a search that hid them would hide the answer.

Each email box says one of three things: it would be sent, it would not be sent and why, or it is held until a time. Held means your store’s frequency limit — that person had an email too recently — and the time is on your store’s clock.

Your store has a frequency limit: how long somebody waits between marketing emails, whatever sent them. It covers campaigns and automations together, so two automations cannot both reach the same person within the gap.

It is on Settings → Email, under How often the same person gets an email. A send that would come too soon waits until the gap has passed rather than being dropped. An owner or a manager can change it — turn it off, or choose a gap from an hour to a week; a marketer and a viewer see what it is. A change applies to everyone at once, including people an automation is already holding back.

So that nobody goes looking for a control that is not there: