Sequences

Sending is easy. Knowing when to stop is the product.

Anybody can schedule five emails. The damage in outbound is done by the sixth one — the one that goes out after they already replied, after the deal was won, after they asked you to stop. Oneop decides who is eligible before anything is scheduled, holds every send inside the limits you set, and exits the moment the outcome changes.

And because the sequence runs inside the CRM rather than beside it, the person it is contacting is the same record your pipeline, your inbox and your reporting already use. Nothing is synced back afterwards.

Start free Book a demo

No credit card. Free plan, 2 seats.

Enrollment — exited on reply

Dana Kim · Customer #10294

Enrolled from the CRM · checked against your rules first

Eligible

Step 1 · waited two days

The first step honours its own delay, not the moment of enrolling

Sent

Step 2 · personalized, then sent

One model call, metered · the written version ships if it is unavailable

Sent

They replied · step 3 never ran

Exited on arrival — there was no queued send to cancel

Stopped

9
Refusals between "enroll this person" and a scheduled first step
3
Independent layers that stop one step sending twice
0
Future sends waiting in a queue when a reply lands
1
Model call in a personalized send, metered against your workspace
2
Step types that create a task for a person instead of sending anything

Four decisions, in the order they are made

A cadence looks like a list of emails and is really a series of decisions, each of which can be got wrong in a way that costs you a prospect. Choose who to contact. Decide what happens next, and when. Personalize where it earns its keep. Stop when the outcome changes.

Eligibility is settled before anything is scheduledThe sequence, the person and your own enrollment rules are all checked on the server. A refusal comes back naming what blocked it, rather than a silent enrollment that quietly does nothing.
Each step waits for its own delay, including the firstAn enrollment carries one pointer to when its next step is due. Nothing is written out in advance, which is why there is nothing to unwind later.
The message is rendered, then optionally improvedWording and merge fields are resolved the same way every time for the same person, so a retry after a failure produces the identical email. AI, when a step asks for it, runs on top of that — and never instead of it.
The exit is checked at the moment of sending, not on a scheduleReplies exit on arrival. Suppression is re-read in the instant before the send, so an unsubscribe that landed thirty seconds ago still stops this message.

Enrolled
Sequence, person and your rules all checked server-side
Scheduled
One pointer to the next step — nothing written in advance
Rendered and sent
Inside your windows, caps and mailbox limits
Exited
Reply, bounce, unsubscribe, or a signal you chose

What is actually enforced in a cadence

Four mechanisms, in the order they happen to a prospect — and in the places where the builder lets you configure something the send path does not read, the field rather than a nicer sentence about it.

Decision 1

Who is eligible is settled before anything is scheduled

The expensive failures in outbound are enrollment failures — somebody contacted who is already in another cadence, or who has an open deal with your colleague. So the checks live on the server, and there are nine of them between pressing enroll and a first step existing.

Two are worth calling out. The sequence and the person are both looked up scoped to your workspace, which means anything belonging to somebody else is not refused — it is not found, which is a stronger property. And a sequence that is still a draft, or paused, refuses enrollment outright. That one exists because the alternative is a dormant cadence quietly accumulating a thousand people and then contacting all of them the moment somebody switches it on.

Your own rules sit on top of those, and when one of them blocks an enrollment the refusal names which rule did it.

Six enrollment situations and what the Oneop server does with each one
The situation	What happens
The sequence belongs to another workspace	Not found — it is looked up scoped to you, so it does not exist to you
The sequence is still a draft, or paused	Refused. A dormant sequence cannot quietly collect people and burst later
The contact belongs to another workspace	Not found — same scoped lookup, on the person as well as the sequence
They are already running in this sequence	Refused as a duplicate rather than started twice
Your rules say skip anyone with an open deal	Refused, with the rule that blocked it named in the response
A lead with no email address	Refused before enrollment, not discovered at the first send

Every row here is a refusal from the server, not a disabled button. A rule you can get around by calling the API directly is not a rule.

Decision 2

What happens next, and when

An enrollment holds one thing about the future: when its next step is due. There is no list of pending emails written out in advance, which is the reason the last decision on this page is cheap — there is nothing to unwind. Each step schedules the one after it from its own delay, and the first step waits for its delay too, rather than firing the instant somebody is enrolled.

That first-step detail sounds pedantic and is the difference between a cadence you designed and a cadence that starts with an ambush. If you set the opening email to wait two days after enrollment, it waits two days — including for the two hundred people you imported this morning.

And what stops it happening too fast

A due step passes every limit below before it sends, and anything that fails moves the step rather than dropping it — so a sequence that hits a limit is late, never lossy.

The table is the honest version. Most of these are genuinely enforced. Two are not what the builder implies, and it seemed better to put them in the same table as the rest than to leave them out of it.

Seven sequence sending controls, where each is configured, and what the send path actually does with it
Control	Set	What the send path does
The delay before each step	Per step, in days and hours	Enforced — including the first step, which waits rather than firing on enrollment
Send windows, days and time zone	Per sequence	Enforced — a step due outside the window is rescheduled, not squeezed through
Emails per hour	Per sequence	Enforced, but counted across the whole workspace — two live sequences share one hourly budget
A daily cap, and a warm-up ramp	Per sequence	Enforced — the day is filled, then the rest moves to tomorrow
A daily cap on each sending mailbox	Per mailbox	Enforced — with no mailbox left today the sequence pauses and says so, and never falls back to a shared address
How many active sequences you can run	By your plan	Enforced when you activate one, inside a transaction, so two tabs cannot both win
A maximum number of enrollments	Per sequence, in the builder	Recorded and shown — but no send path reads it. Treat it as a note to your team, not a limit

Rows three and seven are the ones to read. A vendor’s send-limit table is only worth something if it also tells you which of the fields do nothing.

Decision 3

Personalize where it earns its keep, and nowhere else

A message is built in a fixed order, and the order is deliberate. Alternative wordings you wrote are resolved first, then merge fields are filled, then — only if that step asked for it — a model adjusts the result using what is actually known about this recipient. Then your signature, then link tracking.

The first two steps are derived from who this person is and which step this is, rather than from chance. That sounds like a detail and is not: it means a retry after a network failure renders the identical email rather than a second, different one, and it means an A/B result is attributable to the variant that produced it instead of to a coin flip nobody recorded.

The AI step is one model call, and four things about it matter more than the feature. It is metered against your workspace’s credits, so it shows up in your usage. What the recipient’s record contains is passed as data with an explicit instruction to ignore anything written inside it — a job title is an untrusted string. If the model is unavailable, the email you wrote goes out unchanged rather than the cadence stalling. And a suppressed recipient is caught before the model is called at all, so an unsubscribed address never costs a credit and never leaves your system.

One thing it is not: a step type. There is no “AI step” that writes a message from nothing. It is a toggle on an email you wrote, and the email you wrote is the fallback.

How one email is built

Always, in this order

Alternative wordings resolvedSame every time

Merge fields filledSame every time

Only if this step asks

One model callMetered

Model unavailableYour version sends

Then

Signature and link trackingApplied

Recipient suppressedRefused before the model

The last row is the one worth having. Checking suppression before the model call is the difference between a policy and a bill.

Decision 4

A reply ends it on arrival, because nothing was queued

Every outbound tool says sequences stop when someone replies. It is worth unpacking, because there are four questions hiding in that sentence and most products only answer one of them.

What counts, and on which channel. An inbound email, arriving through the webhook your mail provider posts to. That is the only path — there is no second mechanism quietly polling a mailbox, so if your inbound replies do not route through that provider, nothing detects them. We would rather you knew that before you built a quarter around it.

How the person is matched. By email address, against the contacts and leads in your workspace — and the workspace is worked out from the message that was originally sent to that address, not from anything the inbound message claims about itself. A reply nobody can attribute is left alone rather than guessed at.

When it stops, and what happens to pending work. On arrival, not at the next scheduled run. And the reason that is safe rather than merely fast is decision two: nothing was written out in advance. An enrollment holds one pointer to its next step, so ending it is not a cancellation — the next run simply does not select it.

Everything else that ends an enrollment

A reply is the one people ask about; it is not the only way a cadence should end. A bounce and a complaint exit regardless of how the sequence is configured, because those are not preferences. Suppression is re-read in the instant before every send, so an unsubscribe that landed thirty seconds ago still stops this message rather than the next one.

The signals you opt into — a click, a booked meeting, a deal moving stage — are evaluated as the next step comes due rather than the moment they happen. That is a real difference from the reply path and the table says so instead of grouping them together.

Six signals that can end a sequence enrollment, how each is detected, and what happens when it is
Signal	How it is detected	What happens
They reply	Inbound email, matched to a person by address inside your workspace	Exits immediately on arrival, not at the next tick
The address bounces	The delivery provider tells us	Exits — and this one is not optional, on any sequence
They unsubscribe or complain	Suppression list, re-checked in the moment before every send	The send is refused and the enrollment exits, however it was scheduled
They click, or book a meeting	Your own tracking on the links the sequence sent	Optional. When you turn it on, it is evaluated as the next step comes due
The deal moves	A stage change on the record the person belongs to	Optional, and evaluated the same way — at the next step rather than instantly
They reply while the enrollment is paused	The reply is recorded against them	It does not exit them. Resuming resumes the cadence — read the pause as a hold, not a stop

Row six is the caveat. Exiting applies to enrollments that are running; a paused one holds the reply against the person but resumes the cadence when you resume it.

Connected with Oneop

The cadence is running against your CRM, not a copy of it

The person a sequence contacts is the contact or lead your pipeline already uses, so an open deal can block an enrollment and a stage change can end one. Manual steps become tasks in the same queue as the rest of your work. Replies land in the same inbox your team already reads, the outcome is written to the record rather than to a separate outbound database, and the reporting counts the same rows. That is the whole argument for running outbound inside the business system instead of alongside it.

You are hereSequencesOutreach works from CRM and customer context under controlled automation.

The other 7 modules sit on the same record, and reach Sequences the same way:

Beyond the four

A step that reads what already happened

A branch step looks at whether this person opened, clicked, replied or booked, and then exits them, skips the next step, or jumps to a different one. It is evaluated once and logged like any other step, so a branch cannot loop.

Two subject lines, and the same person always gets the same one

A step can carry variants. Which one someone gets is derived from who they are and which step it is, not from a coin flip — so a retry after a network failure re-renders the identical email, and the result stays attributable to the variant that produced it.

A stalled sequence tells you why

No mailbox with capacity, a sending domain that has not verified, a task that could not be created: the enrollment holds the reason in plain words and retries rather than failing silently. A sequence that stops without saying why is the worst version of this software.

Manual steps land in the same task queue as everything else

A call step, an SMS step and a LinkedIn step create a real task for the person who did the enrolling, due the next day, carrying the message already merged with that recipient. They are prompts for a human, and we would rather call them that.

The sender is your workspace, not whoever pressed enroll

Sequence mail leaves from your workspace address, or — when you have connected sending mailboxes — from the next one with capacity today, chosen by how much each has already sent. Nothing is sent from a rep’s personal mailbox, so nothing breaks when that rep is away.

You hear when it ends, either way

The person who enrolled someone is notified when the cadence finishes and when a step permanently fails on them. Not a digest nobody reads — a notification against that contact, in the same place as the rest of your work.

The personalization pass in decision three is the only AI in a sequence. How models are metered, constrained and governed across Oneop is one page:AI governance.

Where the people come from, and what carries the send

People come from the CRM you are already filling — imported, captured, enriched, or synced from HubSpot. The send leaves through the mail infrastructure your workspace has connected, which is also what carries replies back in. And the outcome is written to the contact record, so the calendar invite, the task and the deal all read the same history.

See all integrations

Gmail
Microsoft 365
IMAP / SMTP
HubSpot
Postmark
SendGrid
Google Calendar
Webhooks

For the technical evaluator

The same prospect cannot receive the same step twice, and the last thing defending that is not application code.

Three independent layers, because the first two can each be defeated on their own — and one honest gap, named below rather than left for you to find.

The three layers, and the gap

Layer one — nobody else can pick it up. When a run selects the enrollments that are due, it takes a short exclusive lease on each one in the same database statement that finds it, skipping any row another worker already holds. Two runs overlapping — a scheduled tick and somebody pressing run now — cannot both take the same enrollment. On its own this is not enough, because a lease has to expire, and a slow send can outlive one.

Layer two — a step that already finished is not re-run. Before executing, the run checks whether this enrollment already has a final result recorded for this step. If it does, the enrollment is advanced without executing anything. This catches the expired-lease case in the ordinary path. On its own it is still not enough, because two workers can both read “no result yet” before either writes one.

Layer three — the database refuses. There is a uniqueness constraint on the pair of enrollment and step, applying specifically to results recorded as sent. A second attempt to record one is not an error to handle; it is a no-op, and the code that lost the race treats it as “already sent” and moves on. This is the layer that matters, because it does not depend on any worker remembering to check anything, and it holds across restarts, across concurrent runs and across code that has not been written yet. A send result is written the instant the provider accepts the message, not at the end of the step, so the window in which that constraint is the only thing standing there is as short as it can be made.

The gap. One case is not covered and we are not going to pretend otherwise. If the mail provider accepts a message and the call then fails on the way back — a timeout after delivery rather than before it — no result was recorded, so a retry sends it again. That is the classic at-least-once boundary and it is a real duplicate, not a theoretical one. It is bounded to that window, it requires a failure after acceptance rather than before, and closing it properly means the provider handing back an identity we can record before we lose the connection. We would rather state the shape of the remaining hole than round the guarantee up.

Why this is the guarantee we surface. Because duplicate outbound is the failure that costs you the prospect rather than the afternoon. Nobody forgives a vendor twice for the same email, and a duplicate does not throw, does not appear in an error rate and does not show up in a demo — you find out from the reply. The only durable defence is a constraint that exists whether or not the code remembers, which is a thing you can ask a vendor to point at rather than describe.

What it costs

The row that actually shapes how you work is the third one: how many sequences you can have active at the same time. That one is genuinely enforced — it is checked when you activate a sequence, inside a transaction, so two people activating at once cannot both slip past it, and you are told which plan allowance you have reached rather than finding a sequence quietly refusing to run. Draft and paused sequences do not count against it, so you can build ahead of the limit.

See full pricing

Which sequence capabilities are included on each Oneop plan
Plan	Sales sequences	Rules that route who owns a lead	Active sequences at once	Contacts you can enroll from
Free $0	Not included	Not included	1	500
Starter $19	Included	Not included	2	2,000
Pro $59	Included	Included	10	5,000
Business $129	Included	Included	50	25,000

Frequently asked

Do sequences really stop when someone replies?

Yes, and it is worth being precise about it, because this is the sentence every outbound tool prints and almost none of them qualify. A reply means an inbound email. It arrives through the inbound mail webhook, and that is the only path — there is no separate mailbox poller quietly doing the same job, so if your replies do not route through the mail provider that handles your inbound, nothing detects them. The person is matched by email address against the contacts and leads in your own workspace, and the workspace itself is worked out from the message we originally sent to that address, so a reply that cannot be attributed to a workspace is left alone rather than guessed at. The exit happens when the reply arrives, not at the next scheduled run. And the reason that matters less than you would think is the fourth part of the question: there is no queue of pending sends. An enrollment carries a single pointer to when its next step is due, so stopping it is not a matter of cancelling anything — the next run simply does not pick it up. One honest boundary: this exits enrollments that are running. If you had paused someone, a reply is recorded against them but does not exit them, and resuming them resumes the cadence.

Whose email address do sequences send from?

Your workspace’s, not the individual rep’s. If you have not connected sending mailboxes, everything leaves from the one workspace address. If you have, each send picks the next mailbox with capacity remaining today, weighted so volume spreads rather than piling onto one address, and each mailbox’s daily cap is counted durably so a restart or two runs at once cannot overshoot it. If no mailbox has capacity left, the sequence holds and tells you why — it never quietly falls back to the shared address, because that is exactly the moment deliverability gets destroyed. This is a deliberate difference from the per-user mailbox connection elsewhere in Oneop, where a rep’s own Gmail or Microsoft 365 account sends and receives their one-to-one email. Outbound at volume is a workspace capability, so nothing here breaks when a rep is on holiday.

What stops someone from being enrolled?

Quite a lot, and all of it on the server rather than in the form. The sequence has to exist in your workspace and the person does too — both are looked up scoped to you, so anything belonging to someone else simply is not found. The sequence has to be active: enrolling into a draft or a paused sequence is refused outright, which is what stops a dormant cadence collecting a thousand people and then firing at all of them the moment somebody switches it on. Somebody already running in that sequence is refused as a duplicate. Your own rules are applied next — skip anyone already in another sequence, skip anyone with an open deal, never re-enroll, or only re-enroll after they have exited — and if one of them blocks it, the response names which. And a lead with no email address is refused at enrollment, rather than sitting in the cadence until the first send discovers it.

Which of the send limits are actually enforced?

Most of them, and we will name the one that is not. Step delays are enforced, including the first step, which waits for its configured delay instead of firing the moment someone is enrolled. Send windows, sending days and the time zone are enforced by rescheduling rather than by squeezing a message through the edge of the window. The daily cap and the warm-up ramp are enforced per sequence, and each sending mailbox’s own daily cap is enforced separately. How many sequences you can have active at once is enforced by your plan at the moment you activate one, inside a transaction, so two people activating at the same time cannot both slip past. Two caveats. The hourly limit is set per sequence but counted across the whole workspace, so two live sequences share one hourly budget rather than getting one each. And the maximum-enrollments field in the builder is recorded and displayed but is not read by anything that sends — treat it as a note to your team until it is, and we would rather write that down than let a field in a form imply a cap that does not exist.

Which parts of a sequence are AI?

One, and it is optional per step. An email step can be marked for personalization, and when it is, the already-rendered message — merge fields filled, wording chosen — is passed to a model along with what is actually known about the recipient, and comes back adjusted. Four things about how it is wired matter more than the feature itself. It is metered against your workspace’s AI credits like everything else, so it is visible in your usage rather than free-and-untracked. Whatever the recipient’s own record contains is passed as data with an explicit instruction not to follow anything written inside it, because a company name is an untrusted string and a prospect who puts instructions in their job title should not get to rewrite your email. If the model is unavailable or slow, the send goes out with the message you wrote instead of failing — the cadence is never held hostage to a model. And if the recipient is suppressed, that is checked before the model is called at all, so an unsubscribed address costs you nothing and has nothing about it sent anywhere. How models are governed and constrained across Oneop is a separate page: AI governance.

What happens when a send fails?

It depends on whether it failed before or after the message left, and the distinction is the whole answer. A failure before sending — a mailbox with nothing left today, a domain that has not verified, a recipient who cannot be resolved — releases the enrollment and retries it on the next run, holding a readable reason in the meantime so you can see what is stuck rather than wondering why a sequence went quiet. A failure that is permanent, or a last attempt, records the step as failed, moves the enrollment on rather than leaving it wedged, and notifies whoever enrolled that person. What is never recorded is a send that did not happen: a message the provider refused is not written down as sent, which is what keeps your reporting honest and your next step from scheduling off a fiction.

Do SMS and LinkedIn steps send anything?

No, and the builder offering them alongside email makes that worth stating plainly. An SMS step and a LinkedIn step create a real task for the person who enrolled that contact, due the next day, carrying the message already merged with that recipient’s details so it is ready to send by hand. A call step does the same. They sit in the same task queue as the rest of your work rather than in a separate sequence to-do list, which is the point: a cadence that mixes automated email with human touches should put the human touches where that human already looks. When automated delivery on those channels exists, this page will say so. Right now they are prompts, and calling them anything else would be a lie you would discover on day two.

Run outbound that stops when it should.

Build one cadence against contacts you already have. Or book a walkthrough and we will show you an enrollment refused by your own rules, a step held outside its send window, and a reply ending a sequence the moment it arrives.