Sequences

A sequence is a fixed series of emails on set delays. People start a sequence and finish it, and each pass through it is a run.

Sequences live under Emails → Sequences, because a sequence is a series of emails and nothing more. What decides who starts one is a flow.

On and off

A sequence has one switch. There is deliberately no separate draft or paused state — one switch, two meanings, and no third thing to reason about.

While a sequence is off:

• Nobody new can start it. A flow that tries logs the attempt and moves the person straight on rather than stalling them.
• Everyone already partway through stops receiving. Their scheduled emails hold, with the reason visible in the queue.

Turning it back on releases those holds on their original due times. Anything that came due during the pause goes out on the next tick, re-checking guards and send windows on the way. New sequences start off, so nobody can be started on something half-built.

Steps

A sequence's page has three sections: Emails (the steps), Settings (repeat runs, name and notes), and Guards (the checkpoints that can act on what it sends).

Each step is an email plus the delay before it, measured from the step before. Step one with no delay sends the moment the person starts.

Add step asks where its email comes from: blank, or from your library — and if from your library, whether this step shares that email or takes a copy of it. Sharing means editing it here changes it everywhere else it's used; copying means this step goes its own way. See Emails for what each one changes later. Change email… in a step's actions menu asks the same question, and leaves the email you're replacing in your library.

A step's actions menu also has Insert step before this and Insert step after this, so you can put a step where it belongs instead of adding it at the end and moving it up. Everything below the insertion point shifts down one.

Steps open in place: expanding one reveals the full email editor — subject, body, preview, and where else that email is used — without leaving the sequence. One opens at a time, so you're never editing two emails at once, and the step's own controls (the delay, its on/off switch, its actions menu) stay usable whether it's open or not.

Draft and active steps

A draft step doesn't exist as far as scheduling is concerned. People move through the sequence as if it isn't there, so nobody piles up waiting for an unpublished email.

When you activate a draft step:

• Anyone who hasn't yet reached that position gets it, slotted in on the cadence it would have had.
• People already past it don't get it retroactively.
• Nobody's existing scheduled emails move.

Unpublishing pulls the step back out of everyone's queue, and their remaining steps stay exactly where they were.

Editing a sequence people are in

Changing a delay, swapping an email, or reordering steps applies to future runs. People already in the sequence keep the plan they were given — their scheduled dates are something they can see, and moving them under their feet would make the queue a guess rather than a fact.

Repeat runs

Three modes, chosen per sequence.

What counts as already received

A person has received an email when there's a send record for that person and that email record. It survives editing the email and reordering the sequence — the identity is the record, not the content or the position.

Deleting an email and creating a new one with the same words is a fresh email, so everyone is eligible again. If you'd rather not delete it, the email's Reset sent status action makes everyone eligible from that moment on without losing the send history.

Runs

• A person can have at most one active run per sequence. The database enforces it, so two events arriving together can't both win.
• Starting a sequence writes the person's whole plan up front as real scheduled rows. Position is visible data, not something recomputed each time a job wakes up.
• A run finishes when its last step is sent or dropped — a guard dropping one step never stalls the ones after it.
• Finishing fires a sequence_completed event, which is an ordinary event: flows can trigger on it, and a flow step waiting on the sequence is released by it.