Question 1

Why am I seeing 0 invites sent today even though the campaign is running?

Accepted Answer

Your daily counter that gates rate limits had drifted upward — historical inflation locked in an inflated value. The reconciler that's supposed to heal drift was using the wrong formula, so any inflation could only ever go up, never down. Net: the counter said 142, the reality was 12, the rate-limit gate blocked all new sends. Fixed early May 2026: the reconciler now authoritatively recomputes from event records and can heal downward. A one-shot heal script ran the same day (51 accounts scanned, 41 healed downward — top examples 142→12, 87→9, 73→7). If you still see the symptom, hard-refresh your dashboard (60s cache) and check the campaign-card per-step counter — that's always ground-truth. If those still disagree by more than 24h, contact support.

Question 2

Why does my dashboard show '0% accept' when I have replies?

Accepted Answer

Your dashboard was double-counting phantom-accept-reverted rows. An early-May reverter cleared the acceptance timestamp on rows where the original accept signal came from a cross-campaign signal leak. The event log still had the original invite-accepted event (deliberately kept for forensics), so the stats refresher's max-of-counters formula picked up the forensic event and double-counted. Fixed early May 2026: the events query now excludes events whose paired prospect row was reverted to Pending Accept. Backfill ran the same day (top examples 47→31, 89→79, 1,208→1,058). Hard-refresh your dashboard. Cross-check ground-truth against your LinkedIn inbox and the campaign-card per-step counter — both are always correct.

Question 3

Why does my follow-up message never fire after acceptance?

Accepted Answer

Your message template likely has a Liquid syntax typo — most commonly `{{company}` (one closing brace, missing the second). Liquid template parsing caught the typo at send time, the worker marked the job failed, and the orphan reconciler resurrected the enrollment on the next tick. As of early May 2026, Liquid syntax errors are caught at save time on the platform side. Every template-bearing field — invite note, message template, InMail subject + body, comment template, A/B variants — is validated before the campaign is saved. You'll see a soft amber Alert at the top of the editor + a red border on the offending field + a caret marker pointing at the typo. The Validate button on every step gives instant feedback without a save round-trip. Common typos: `{{company}` (missing one closing brace) → `{{company}}`; `{firstName}}` (missing one opening brace) → `{{firstName}}`; `{ {firstName}}` (no space between the braces) → `{{firstName}}`. Open the affected campaign, fix the typo, click Save, click Resume. Affected prospects retry on the next tick. No prospects are lost. No LinkedIn API calls were made on the failed attempts.

Question 4

Why does connecting a new account give a constraint error?

Accepted Answer

The Reconnect button was failing because five internal code paths were bypassing the canonical state-flip helper that records a paired audit entry. The audit-pairing safety check correctly rejected the missing audit, but the user only saw a cryptic error. Fixed early May 2026: all five paths now go through the canonical helper. Each site now records a paired audit entry in the same transaction; the safety check passes; the reconnect button works. A build-time guard prevents new bypasses from being introduced. A backfill cleared 14 stuck rows in the in-progress connecting state. Try reconnecting again — the button works first-try. If you still see an error, contact support immediately.

Question 5

Will my prospects be lost if my template has a syntax error?

Accepted Answer

No. Affected prospects sit in a Pending Template Fix state with the failure reason recorded for forensics. They retry on the next campaign tick after you fix the template and click Resume. No prospects are dropped, no quota is consumed, no LinkedIn API calls are wasted. The Liquid parse error fires before any LinkedIn call, so there's no rate-limit cost to retrying.

Question 6

Why does the Validate button matter if the server validates on save anyway?

Accepted Answer

Defense in depth + UX. The server-side validation is the load-bearing safety gate; the client-side Validate button gives you instant feedback without a save round-trip, so you can fix typos in the editor before clicking Save. Both use the same logic — there's no way for a typo to be 'OK at validate time but rejected at save time'.

Question 7

Will any of these fixes affect my LinkedIn account safety?

Accepted Answer

No. Every fix on this page is database-only — zero new LinkedIn API calls, no rate-limit risk, no account flags. The engine respects per-account daily/weekly limits, sending windows, and timezone exactly as you configured them. The reconciler fix actually IMPROVES safety by ensuring the rate-limit gate isn't blocked by stale inflated values; the audit-pairing fix means every status flip on your account is now forensically recorded. We never auto-shortcut a step, never auto-skip a wait, and never complete prospects to 'help' you. Account safety always wins over throughput.

Question 8

Why is my prospect's next-step scheduled days into the future?

Accepted Answer

When the daily counter was inflated during the counter-drift era (e.g. counter=142 vs reality=12), every spurious 'daily limit reached' trip pushed the prospect's next action one full sending day forward. Multiple cap-hits during a single inflated day compounded — one customer had three spurious cap-hits over three days, so their step-0 prospects ended up with next-action timestamps three sending-window days in the future. The early-May counter heal corrected the gate, but the historical schedule defers remained baked into the prospect rows. Fixed at the same time: a one-shot heal script re-clamps next-action timestamps for step-0 enrollments whose schedule is more than 24h ahead AND whose LinkedIn account had a downward-counter-heal within the last day. The paired send-job timestamp is updated in the same transaction. We are healing this automatically — you don't need to do anything. If you still see future-dated next-actions more than 24h ahead on step-0 prospects after the sweep, contact support.

Question 9

Why does my dashboard show acceptances but my campaign isn't progressing?

Accepted Answer

Webhook subscriptions are scoped per-session-token by our LinkedIn integration. When LinkedIn rotates the token and you reconnect, the OLD subscription is implicitly invalidated. Before the early-May fix, our reconnect path correctly flipped the account status back to connected but didn't re-register the per-account webhook subscription — so every reconnect silently dropped the relations webhook (new connection + invitation accepted by other party) for that account until the next platform-wide subscription refresh. Net: accept events landed upstream but never reached our database, so the dashboard showed 0 accepts even when prospects had accepted. Fixed early May 2026: the reconnect path now re-registers the full webhook event list after the account status flip succeeds. A daily audit job compares the active subscriptions against the connected-accounts list; any account missing the relations event triggers automatic re-registration with an internal alert. If you've reconnected in the last 30 days and your dashboard shows fewer accepts than your LinkedIn inbox, click Reconnect once more (the new path re-registers webhooks correctly), then wait 5 minutes for the audit job to back-fill any missed events from the polling fallback.

Question 10

Why does 'last activity' show an old date even though my campaign is sending?

Accepted Answer

The 'last activity' UI tile was wired to the session-refresh timestamp — a field updated by the session refresh job (every 5 min during business hours, less often outside). It reflects auth-flow health, NOT send activity. Same family as an earlier status-pill honesty fix where 'Connected on dd/mm/yyyy' could appear on a row that was actually disconnected. Fixed early May 2026: a new endpoint returns the most recent completed send time, derived on-demand. The UI tile now reads from this endpoint. Fallback chain: if no completed jobs in the last 7 days, falls back to the most recent LinkedIn event (covers replies and acceptance webhooks); falls back finally to the session-refresh timestamp only if both are empty. The pill's tooltip explains the source explicitly: 'Last completed send at HH:mm UTC' / 'Last LinkedIn event at …' / 'Last health check at …'. Hard-refresh your dashboard to pick up the new value.

Why isn't my LinkedIn campaign sending?

Why are some prospects parked waiting for a template fix?

What put them there

What saving a valid template does (auto-resume)

Why we surface this on the edit page

Common questions