> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshooting: outbound campaign blocked at the pre-send gate chain > Unblock an outbound campaign that refuses to launch — read the pre-send screen verdict, tell the hard-fail gates from the advisory warns, fix the blocked stage, and re-submit or send your campaign for approval. # Troubleshooting: outbound campaign blocked at the pre-send gate chain An outbound campaign that ships clean passes a short chain of pre-send checks before the first message or call goes out. When the chain finds something it reports a verdict instead of shipping: either the send is **blocked** outright (the pre-flight error codes name the gate class, so they show as `GATE_BLOCKED`-style refusals) or it ships with a **warning** (`GATE_WARN`-style advisories you acknowledge and proceed past). This page maps those verdicts back to the specific gate that fired and the tenant-owned fix for each. The gates themselves — their exact evaluation order, the specific error code each one returns, and which ones carry no opt-out — are the concept page [Voice pre-send gate chain](/concepts/voice-pre-send-gate-chain). This page is the runbook: it starts from the symptom (campaign will not launch, or launched with warnings) and ends at the control you own. ## 1. What pre-send screening does Pre-send screening is a built-in chain of safety checks that runs on every outbound campaign before launch, and per recipient before the send goes out. A launch, a batch send, and a dialer campaign all take the chain; nothing ships until the chain evaluates. The chain stages, in the order they evaluate on the outbound voice path: 1. **Emergency short-code reject** — platform-global, no toggle. 2. **TCPA federal dialing window** for US voice, and your **tenant opt-in quiet-hours gate** for sent-hours you configured yourself. 3. **FCC AI-voice written-consent gate** — synthetic or cloned voices need prior express written consent on record. 4. **Fraud-velocity guard and DNO caller-id reject** — premium-rate prefixes, spend and rate caps, and Do-Not-Originate caller IDs. 5. **Trunk caller-id reject** — the presented caller ID must sit in the trunk allow-list or your organization's DID list. 6. **Per-country rate window** — a sliding-window cap per destination country. 7. **STIR/SHAKEN attestation** — resolved and stamped, never a blocking gate. The full precedence table with per-gate error codes is on [Voice pre-send gate chain](/concepts/voice-pre-send-gate-chain). The launch-side result of this chain is what the campaign review step and, for orgs that require sign-off, the **Outbound → Campaign approvals** queue (`/outbound/approvals`) render as a blocked or warned launch. That queue exists for orgs whose campaign settings require supervisor approval before recipients are messaged — your supervisor (and an owner/admin) sees the same gate verdict there before approving. ## 2. Why a check hard-fails vs warns Every verdict falls into one of two classes, and the class decides what you can do about it: * **Blocked (`GATE_BLOCKED` class) — the hard fail.** The send does not go out. Resolution is one of two shapes: fix the underlying condition the gate names (a caller ID that is not in the trunk allow-list, AI voice without written consent, a list aimed outside the federal window), or — for the gates that are *tenant-owned* — adjust or retract the tenant control that fired (your quiet-hours window, your per-country limits, your DNO override). Platform-owned gates at a statutory floor — the TCPA federal window, the FCC AI-voice consent gate, the BAA send gate, the emergency short-code reject — are hard-fail by design and carry no skip toggle. The page will not let a supervisor "approve past" a platform-owned block; the approval surface exists to sign off on tenant-owned gates, not to commute federal ones. * **Warn (`GATE_WARN` class) — the advisory.** The chain found a condition you should see before shipping — a policy-scan finding on your message body, a destination that historically converts poorly, a sender pool concentration. Warn-gated sends ship after you explicitly acknowledge the warning on the review step (or, for approval-required orgs, after a supervisor approves the launch in the approvals queue). A persistent warn on a gate you configured to *warn-only* is your own setting working as configured; a warn on a gate you configured to *block* moves into the blocked class above. The distinguishing question is never "can I click past this" — it is **who owns the gate**. Codes or gates tied to the platform compliance floor fail hard and stay hard; tenant-owned controls carry the toggles, and the warn/block split on them comes from your own send-gates configuration. The per-gate ownership and fail-open vs fail-closed posture table is section 5 of [Voice pre-send gate chain](/concepts/voice-pre-send-gate-chain). ## 3. How the chain interacts with dedupe and the silent-unsubscriber sweep Two stages of the chain are about *who stays on the list*, and they run as part of the same pre-send evaluation — so a blocked verdict on a list issue is often one of these, not a compliance gate. **Retroactive dedupe.** The chain de-duplicates the recipient list before any send goes out: case- and format-normalized numbers that appear twice (an uploaded list overlapping your own updated contacts, a re-imported CSV with stale rows) collapse to one attempt. The dedupe is retroactive in the sense that it applies to records you already ingested — a launch after an import uses the *resolved* recipient set, not the raw uploaded one. When the review step reports fewer recipients than your upload carried, the difference is largely this stage; it is a warn-class reduction you acknowledge, not a blocked verdict. **Silent-unsubscriber sweep.** Contacts that unsubscribed without a keyword reply — carrier-reported opt-outs, suppression-list additions, imported unsubscribe files — are swept by the same chain stage before any send. A send to such a contact is not merely warned; the contact is removed from the recipient set, and if the sweep empties the list the launch blocks with nothing addressable. The fix is list-side, and both the dedupe check and the sweep use the same suppression and consent stores as the [consent and suppression model](/concepts/consent-and-suppression-model). A blocked verdict that survives fixing the compliance gates therefore usually means **no recipient remains addressable** after these two stages. Check the campaign's resolved-recipient count on the review step before reworking your caller-ID or consent records. If you want the same chain stages spelled out per recipient before you launch, run a dialer preview — the preview claims walk the same per-recipient predicates the full campaign will ([Troubleshooting: dialer preview, power, and predictive modes](/troubleshooting/dialer-preview)). The wizard-slide fallback for that preview (what each gate verdict means before you commit the full list) is the same runbook this page works. ## 4. Unblock the send — the decision path Work these in order; every one moves a blocked verdict toward a launch, or resolves a warn to a clean pass. 1. **Read the verdict code on the review step (or the approvals queue).** The pre-flight code names the gate class. Match it to the precedence table on [Voice pre-send gate chain](/concepts/voice-pre-send-gate-chain) — the same code the API returns is the code the queue shows. 2. **If the code is a platform-owned gate, fix the underlying condition.** Federal window — retime the send into 8 AM–9 PM recipient-local or shift recipients outside US ranges. FCC AI-voice consent — record prior express written consent before launch. DNO or trunk caller-ID — use a caller ID in the allow-list. There is no toggle; re-submit after the fix. 3. **If the gate is tenant-owned, adjust or retract your own control.** Quiet-hours, per-country limits, DNO overrides, warn/block split — open the send-gates settings, change the toggle, and re-run the review; the verdict flips class on the next pre-send pass. 4. **If the sweep left no addressable recipients**, re-import a clean list (dedupe collapses duplicates; suppression removals are terminal) and re-run the review. 5. **For approval-required orgs**, have an owner/admin approve in **Outbound → Campaign approvals** after steps 1–4 pass; the queue rejects at the UI the same gates the API rejects, so approve only resolves tenant-owned warns and tenant-toggled blocks. ## 5. When to escalate Escalate to support with: 1. **Your organization ID** — Settings → Organization, or `organizationId` from `GET /api/v1/me`. 2. **The campaign ID**, the mode (batch, dialer, drip), and the current status (`draft`, `pending approval`, `active`, `aborted`). 3. **The exact pre-send verdict** — the blocked or warn code verbatim, and the resolved-recipient count from the review step (for dedupe / sweep verdicts). 4. **The gate you believe is tenant-owned vs platform-owned** — if you disagree with the ownership split, that is a configuration question, not an outage. A persistent platform block on a tenant-owned control only trips when the control genuinely fails closed — match the code first; the escalation only helps once the ownership question is settled. ## See also * [Voice pre-send gate chain](/concepts/voice-pre-send-gate-chain) — the concept this page operationalizes: evaluation order, error codes, fail-open vs fail-closed posture. * [Troubleshooting: dialer preview, power, and predictive modes](/troubleshooting/dialer-preview) — the same per-recipient gate chain seen through preview claims. * [Consent and suppression model](/concepts/consent-and-suppression-model) — how the silent-unsubscriber sweep resolves recipients. * [Send gates](/compliance/send-gates) — the tenant-owned toggles (quiet hours, per-country limits, DNO overrides, warn/block split).