Email Sequences
The machinery under the canvas. Every lead carries a cursor of their own that moves forward a step at a time, parks where told, and cannot be talked into sending the same message twice.
One enrolment, one cursor, one claim before each send
the claim comes before the render- current node
- send_intro
- version
- v3, frozen at publish
- steps taken
- 4
- next run at
- now
- status
- active
- active
- waiting
- completed
- exited
- blocked
- suppressed
- holdout
Product figures from the platform’s own defaults - not customer averages
How it works.
A row per person, holding the place
It stores which box they are standing on, which frozen version they are running, how many steps they have taken and when they are due back. None of that lives in memory, so a deploy in the middle of a cadence costs nothing at all.
A sweep every minute over what has come due
A repeating job looks across every workspace for runs whose time has arrived under a sequence that is still live, then walks each one until it parks, ends, or is stopped. A hundred boxes is the ceiling for one pass; reaching it marks that run blocked instead of spinning.
The claim comes before the render, not after
Ahead of composing anything the engine inserts a row keyed on the run, the box, the version and the step counter. Where that row already exists the insert does nothing and the message is skipped. Because the counter moves, a genuine loop back around does legitimately send again.
Pausing stops the people already inside it
The sweep only picks up runs whose parent is live, and the single-run path checks a second time before acting. Pause it and everyone mid-flight stands still where they are. Set it live again and they resume from the identical box.
Two moments in every run.
Every run passes through the same seven. Email Sequences is the lit ones, and everything either side of it is a different page in this category.
- 01Trigger
the thing that happened first
- 02Enrol
how somebody gets onto it
- 03Wait
the pause, and what governs its length
- 04Branch
the fork, and which side is taken
- 05Act
the mail, the text, the task that goes out
- 06Measure
what counts as it having worked
- 07Exit
how somebody comes off it
The specifics.
8 facts- Run states
- Active, waiting, completed, exited, blocked, suppressed, and held back for a control group. Twenty characters of text with no constraint behind it, so the set is a convention the engine keeps rather than one the database enforces
- Sequence states
- Draft, awaiting approval, live, paused, archived. Only a live one accepts people or moves them, and archiving takes a finished cadence out of the list without disturbing the runs it left behind
- Sweep
- Once a minute, every workspace in turn, from the shared job runner
- Against duplicates
- A unique row on run, box, version and step counter, taken before anything is composed
- Step ceiling
- One hundred boxes per pass. Beyond that the run is marked blocked and the reason written down
- One place per sequence
- The same person cannot be put on the same sequence twice. A second attempt is dropped in silence
- With no outgoing server set
- The step is still recorded and the walk still proceeds. The row simply says it was not delivered
- Not the same as
- This is the walk itself. Drawing the shape it walks is the Sequence Builder
What starts this, and what it starts.
Automation is only ever a middle. These are the things that set it running and the things that run because of it.
More in Automation & Flows
12 capabilitiesSequences, dispositions and webhooks that act without being asked.
A unique URL per integration with HMAC signing, rate limits, payload caps and idempotency - plus a log of every delivery it ever accepted or refused.
Branch on whether they opened, clicked or replied, and on how the last call was dispositioned - so the next step answers what actually happened.
Weighted splits assigned by a deterministic hash of the enrolment, so a lead always takes the same arm no matter how often that step is run again.
Hold a lead for minutes or days between steps, clamped to the sending window you set, so that an overnight wait never lands at four in the morning.
Drop a call step into a sequence and it raises an assigned task on the lead's owner, with the outcome the rep logs coming back as a branchable answer.
Name a linked deal as the outcome that means the sequence worked. Reaching it stamps goal met on the run and takes the branch you wired behind it.
Twenty-six behaviours attach to wrap-up codes, and twenty codes ship already pointing at one, so ending a call the right way books the follow-up.
Six event types a CRM rule fires from: stage change, field update, new record, reassignment, schedule and inactivity, agreed in four places at once.
Send the email, assign the owner, raise the task, set the field, move the stage or call a webhook. Six modules, run in the order you stored them.
Eight comparison operators guarding each action, combined with AND and only AND, so a rule meaning either of two things is built twice, as two rules.
A text is a step on the same canvas as the email and the call task, written into the real thread and carried out by the number it is going out from.
A versioned path, a key minted once and kept as a hash, and the same role and profile model the interface runs on deciding what that key may touch.
The rest of the platform.
Five more categories, all on the same record and the same bill. Each card names three of its capabilities, so you can tell from here whether it is worth opening.
Automation & Flows
See email sequences on your own floor.
Thirty minutes, your numbers and your data. We will set email sequences up live and you can decide from the thing itself rather than from this page.
14-day trial · no card · migration included