# Guards

Send-time checkpoints: what stops an email going out, the four escalating actions, scopes, and the built-in suppression guard.

A guard is a checkpoint about the person, checked in the instant an email is about to send. It answers one question: should this go out right now?

> [!NOTE]
> **Guards never act on their own.** They don't run on a schedule and they don't react to anything — they exist only at the moment of a send. If you want something to *happen* when a person changes, that's a [flow](https://mimeohq.com/docs/usage/flows). Guards are passive filters, not trigger-and-action rules.

They live under **Automation → Guards**, which is also where they're edited. A flow or sequence page lists the guards that can affect its emails, read-only, so there's one place they're changed.

## What a guard can do

The four actions escalate.

### Pause & wait

The email waits and goes out in the minute the condition clears. The person's run stays exactly where it was.

**Everything behind it shifts too.** When the paused email finally sends, the rest of that run moves by however long it waited — so a three-day hold doesn't compress the rest of the sequence into a burst.

### Skip & continue

This one email is dropped and the run stays on its original schedule. Nothing behind it moves, and a dropped step never stalls the ones after it.

### Cancel sequence

The person's run is canceled along with everything still ahead of them. A flow step waiting on that sequence is released — a cancellation is a way of finishing, and stranding them at the step forever would be worse.

### Exit flow

The run is canceled and the person leaves the surrounding flow entirely. The exit is recorded on their timeline with the guard's name on it.

> [!NOTE]
> **When several guards match the same email, the most severe wins.** Exit flow beats cancel sequence, which beats skip, which beats pause — pausing and then canceling the same run would be incoherent, and your most emphatic instruction is the one to honor.

## Scopes

A scope decides which emails a guard can see at all.

- **All emails** — every email Mimeo sends: broadcasts, sequences, and flows alike.
- **Emails with a label** — which is how "don't pitch to members" stays narrow.
- **Emails from a flow or sequence** — only what that one scheduled, including the emails of any sequence the flow started.

## Conditions

A guard's condition uses exactly the same vocabulary as a flow's if/else and gates — [see the flows guide](https://mimeohq.com/docs/usage/flows) for the full list. Anything genuinely complex is a named code predicate rather than a deeper settings screen.

## The built-in suppression guard

Unsubscribed people don't get automated email. This checkpoint is always on and can't be edited, disabled or deleted — it's the floor everything else stacks on top of.

It's listed on the Guards page so drops can be attributed to something you can see rather than disappearing into a log. Enforcement lives in the sending code, so it applies even to test sends.

## Recent activity

What each guard actually did, and why, with the value it saw: *"Field current_track is muted (muted)"*. Transitions only — a row that stays held tick after tick is logged once, not sixty times an hour.

Turning a guard off releases whatever it was holding, and those emails go out on the next tick. A hold with no guard behind it would be a queue row nobody could explain.

## Two guards worth copying

**Give people a mute button.** A field like `current_track` set to `muted`, with a Pause & wait guard scoped to the flow that does the drip. Someone who needs a break stops receiving and picks up exactly where they left off, with the cadence intact.

**Don't pitch to people who already bought.** A Skip & continue guard on the `pitch` label, conditioned on the tag or subscription that means "already a customer". They stay in the sequence and keep getting everything else; only the pitch is dropped.