Deliverability, consent & FAQ
Every send in every workflow passes the same guardrails: consent, approvals, calling hours, frequency limits, and email hygiene. This page lists the rules — including the one you can't turn off — and explains every status you'll see in run history.
The one rule with no off switch
If a contact texts STOP, every workflow they're in halts. Immediately, all channels, all steps. The run's status badge reads Stopped · opted out. This is not a setting — you cannot turn it off, in nurture mode or anywhere else. It's a compliance rule, not a preference.
The check looks for an active opt-out, not a missing opt-in. A contact you only ever email has never texted STOP, so their email nurture keeps running normally — the halt fires only when someone actually opts out. (Each text or call step still requires its own real consent before anything sends; more below.)
"Stop when the contact replies" is a per-workflow setting — on by default, and you can turn it off for long-term nurture so one reply doesn't kill a 90-day drip. The STOP opt-out halt is different: it has no setting, and nurture mode doesn't bypass it.
Texts: consent plus the Approvals inbox
Texting a contact requires their prior consent. On top of that, every text a workflow wants to send — and every AI call — queues in your Approvals inbox first. You (or a teammate) release it; nothing reaches the contact until then.
There is exactly one exception: speed-to-lead calls. When you've enabled live dialing, a speed-to-lead call that passes every compliance gate can auto-approve and dial on its own — that's the point of speed-to-lead. Everything else waits for a human.
Business texting also requires carrier registration (A2P 10DLC) before your number can send at volume — the wizard walks you through it in Business texting.
Calls: the gates before a dial
AI calls and voicemail drops pass four gates before the phone ever rings:
- Consent — the contact agreed to be called.
- Do-Not-Call — numbers on your Do-Not-Call list are never dialed.
- Litigator scrub — numbers flagged as serial TCPA litigators are screened out.
- Legal calling hours — based on the contact's own phone number, not your office clock.
A speed-to-lead call that comes due outside legal hours is deferred to the next legal window, not dropped — the step holds and retries when calling becomes legal again. Calls that wait in the Approvals inbox check hours again at dial time, so a late approval never rings a phone at 9 p.m. A hard block (no consent, DNC, litigator) is different: the call is skipped and the run's step note says why.
Email hygiene, handled for you
Every workflow email automatically carries a CAN-SPAM postal footer, an unsubscribe link, and List-Unsubscribe headers (the one-click unsubscribe inboxes like Gmail surface). You never type any of it, and you can't forget it. Unsubscribes are honored through a suppression list — a suppressed address doesn't get workflow email, no matter what a workflow wants to send.
Frequency protection across workflows
A contact enrolled in three workflows shouldn't get carpet-bombed by all three. Every step that reaches a contact — email, text, AI call, voicemail, meeting link, webhook — passes a platform-wide send-fatigue check and a channel-coordination check first. These run across all your workflows together, so total contact frequency stays sane no matter how many automations a contact is in.
When a step is blocked by these limits, it isn't lost — it defers and retries once the limit clears. A short block retries within the hour; a contact in a longer cool-off simply waits until it lapses. Either way the run's note records the reason while it waits, and the step still fires.
Timing: business hours and your time zone
Wait steps can be told to land inside business hours — "wait 2 days, then next open hour" — or on a specific weekday and time. All of these anchor to your organization's booking time zone and open-hours window. The default is Eastern time, Monday–Friday, 9:00–17:00; set your own in your booking settings so waits land in your business day. If a wait's timing setup is ever invalid, it falls back to the plain delay rather than stalling the run.
Note the distinction: business-hours waits use your org's clock; legal calling hours use the contact's.
Why did my workflow stop? Why did a step skip?
First place to look: the run's step note. Every hop logs a short note — which node ran, what it did, and why something was skipped or deferred ("call deferred to calling hours", "SMS skipped (no SMS consent)", "goal met: booked"). Open the workflow's run history and read the note before guessing.
Every run carries one of four status badges — the note underneath tells the fuller story:
| Status | What it means in plain words |
|---|---|
| Running | Mid-flow. The next step is scheduled and will fire on time. |
| Completed | The run ended. That can mean the contact reached the last step, an exit goal fired (they booked, bought, gained a tag, or a field matched — the note reads "goal met"), or a Handoff step passed the deal to Autopilot to work toward the pipeline goal. The note says which. |
| Stopped · replied | They replied, so the workflow handed the conversation to you (or Arianna). This is the default "Stop when the contact replies" behavior. |
| Stopped · opted out | They texted STOP. Everything halted — the rule with no off switch. |
FAQ
Why did a step skip instead of sending?
The usual reasons: the contact hasn't consented on that channel, they have no phone or email on file, or a call hit a hard block (DNC or litigator scrub). The step note names the exact reason every time.
Why did a step fire later than its delay?
Three deliberate delays: a frequency limit deferred the send until the limit clears, a speed-to-lead call landed outside legal hours and is holding for the next window, or the step is a business-hours wait rolling forward to your open hours. Deferred is not dropped — the step still fires.
Can I turn off the STOP halt for one workflow?
No. It's not configurable anywhere — not in nurture mode, not per node, not per workflow. A contact who texts STOP is out of every workflow until they opt back in.
A contact replied but the workflow kept going — why?
That workflow has "Stop when the contact replies" turned off — nurture mode, meant for long drips where one reply shouldn't end months of planned touches. Every individual send still passes its own consent and frequency checks.
Does texting STOP also stop their emails?
The workflow halts entirely, so yes — no more steps fire on any channel for that contact. Separately, a contact who clicks unsubscribe in an email goes on the suppression list: workflow emails to them stop sending, and the step note says so.
Why did a run end at a "Handoff to Autopilot" step?
That workflow reached its Handoff to Autopilot step in terminal mode — its own steps are done, the run's note records the handoff, and the deal is now worked by the goal engine. That's the designed ending for speed-to-lead workflows in your niche suite, not an error.
Next steps
Follow up hard, stay compliant. The guardrails are on every send, automatically.
Open Workflows