Why is my campaign stuck on a condition step?
If your LinkedIn campaign has a condition step (the diamond-shape step that waits for a prospect to accept or reply before advancing) and your prospects look like they've gotten 'stuck' on it — or the dashboard's 'Reserved today' number is much higher than 'Completed today' — this guide explains exactly what's happening, why, and what to do.
What is a condition step?
A condition step is a branch in your campaign sequence that waits for a specific signal from LinkedIn before deciding which step runs next. The two most common condition types are:
• `linkedin_accepted` — wait until the prospect accepts your connection request
• `linkedin_replied` — wait until the prospect replies to your last message
A condition step has three parts:
1. The condition check itself (true / false / still-waiting).
2. A timeout (e.g. 'wait up to 7 days').
3. A 'false branch' — what to do if the timeout expires before the condition becomes true. This is the field labelled `condition_false_next` in the campaign editor.
What happens at the timeout when no false branch is set
If you leave the false branch empty (which is easy to do — the editor doesn't force you to pick one), the engine has no instruction for what to do when the timeout expires. As of April 30, 2026 (G4 fix, LL#265), the engine SAFELY TERMINATES the prospect at the timeout — it does not silently advance to the next linear step, because that would fire a 'send message' on a non-connection and LinkedIn would reject it with a 'cannot_message_non_connection' error. Safe-terminate is the right behaviour for account safety, but it's invisible to you — you only see 'X prospects ended' on the dashboard with no explanation of why.
This is the source of the 'stuck on condition step' confusion. The prospect isn't actually stuck — it's been quietly terminated because the campaign config didn't tell the engine what else to do.
Examples
• Example A — invite-then-message with 7-day wait:
Step 1: send_invite → Step 2: condition (`linkedin_accepted`, timeout 7 days) → Step 3: send_message
• If the prospect accepts within 7 days, condition returns 'true' → Step 3 fires.
• If 7 days pass without acceptance and `condition_false_next` is empty, the prospect is safely terminated.
• If `condition_false_next` points to a fallback step (e.g. send_inmail), the prospect runs that step instead.
• Example B — anti-pattern (do not do this):
Step 1: send_invite → Step 2: condition (`linkedin_accepted`, timeout 7 days, false branch → wait_accept)
This loops the prospect back to wait for the same acceptance the condition just said didn't happen. Our launch validator now blocks this.
The new launch validator (V5-5, May 2026)
When you click 'Launch' on a draft campaign, we now check every condition step before flipping the campaign to 'running'. We block launch and show an amber 'Fix this first' banner if:
• A condition step has a timeout but no false branch — you'll see: 'Condition step has no false-branch — non-acceptors will be terminated silently. Add a fallback step or confirm you intend to terminate.'
• A condition step's false branch points to wait_accept or another condition that depends on the same signal — you'll see: 'Anti-pattern: waiting for acceptance the condition just said didn't happen. Pick a different step type for the false branch.'
Each warning has a 'Fix' link that scrolls you straight to the offending step in the editor. The validator is amber (actionable) not red (destructive) — you can fix the warning and relaunch immediately.
The Reserved · Completed · Daily Cap dashboard split (V5-4, May 2026)
The LinkedIn account card on your dashboard used to show a single number — 'invites sent today' or 'messages sent today'. It now shows three numbers side by side:
• Reserved — how many enrollments the engine has lined up for today's window. These are queued but haven't sent yet.
• Completed — how many actions actually succeeded today. This is the ground-truth number that matches your LinkedIn inbox/sent items.
• Daily Cap — your account's safety limit (set by your ramp schedule and account age).
Reserved is always ≥ Completed because the engine reserves capacity at the start of the window and consumes it as sends complete. If Reserved=149 and Completed=31, that means the engine planned to send 149 today but has only finished 31 so far — the rest are still queued or waiting on per-account spacing. This is how the engine has always worked; we just stopped hiding the reservation count behind the completion count.
If you see Reserved much higher than Completed late in the day, it usually means the per-account spacing is throttling sends (account safety always wins over throughput) or your sending window is shorter than the engine needs to finish the queue. Neither is a bug.
What to do if you have already-stuck prospects
If you have prospects in `linkedin_status='condition_skipped'` from before the G4 fix landed, we ran a platform-wide cleanup on April 30 / May 1, 2026 (V5-3) that flipped them to `stopped` so they're cleanly out of the queue and don't show as 'pending' on your dashboard. The cleanup is one-shot — you don't need to do anything. Your active prospects (those who DID accept, or are still within their wait window) are unaffected.
Account safety (always wins)
Every fix on this page is DB-only — zero new Unipile API calls, no LinkedIn rate-limit risk, no account flags. The engine respects per-account daily/weekly limits, sending windows, and timezone exactly as you configured them. We never auto-shortcut a step, never auto-skip a wait, and never burn prospects to 'help' you. If a step terminates, it's because your campaign config (or the safety-wins rule) instructed it to.
When to ask support
• If you launched a campaign before the validator landed and are seeing 'X prospects ended' with no clear reason, email hello@warmysender.com with the campaign name. We'll check whether you hit the silent-terminate path and, if so, walk you through fixing the condition step's false branch and re-enrolling the affected prospects.
• If your dashboard's Reserved · Completed · Cap split looks wrong (e.g. Completed > Reserved, which should never happen), contact support — that's a counter desync we want to investigate.
References: LL#265 (G4 condition gating), LL#270 (state-drift acceptance reverter), LL#271 (`condition_skipped` cleanup), LL#272 (launch validator) in KEY-LESSONS-LINKEDIN.md. PRD: PRD-2026-04-30-LINKEDIN-AUDIT-V5-CLEANUP.md.