Guards

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?

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. 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.

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 automated send.
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 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.