Campaigns and bulk send

Why ship schedule-time persistence before the runner that fires scheduled sends?

Two reasons that point the same direction. First, the operator workflow shape. Even without the runner, persisting a scheduled time is useful as a planning marker — “this campaign is ready, I've set it for tomorrow at 10am” — and the operator can rely on the schedule metadata when they come back to send. Stripping the schedule field entirely until the runner ships would force operators to track the planned time on a sticky note instead. Second, capturing intent now means when the runner lands, every scheduled campaign already on the table starts firing at its configured time without needing anyone to re-enter the schedule.

The cost is the gap documented above — until the runner ships, schedule is a planning marker, not an unattended dispatch. That cost is real, which is why the honest disclosure leads with it.

Why two send paths — /marketing/campaigns with a saved row, and /marketing/bulk-email without?

Two different operator intents. The campaign path is for sends you want to reference later — the campaigns list shows every campaign with its stats, the audit log records the send, the row gives you something to point at when answering “what did we send last month?” The bulk-email path is for one-off sends where the campaign-row overhead is friction — a quick announcement, an ad-hoc test, an unstructured outreach to a small group.

Both surfaces honour the same recipient picker and record to each customer's Communications tab the same way, so the per-customer touchpoint history stays complete regardless of which path you used. The only difference is the persisted row at the tenant level.

What happens if the send fails partway through — do the first half get the message twice when I retry?

The concurrent-send guard prevents that case. A Send-now claim flips the campaign to status: sending before any dispatch; while in sending, a parallel send is blocked at the row level. If the dispatch fails mid-batch, the catch block reverts the status to draft — but the recipients who already received the message are recorded on their Communications tabs.

On retry, the operator can either accept the recipients who already received the message and repeat the campaign (effectively double-touching them), or use the recipients-already-touched data on the Communications tabs to define a smaller custom segment for the retry that excludes them. Practically, most marketing-batch failures hit recipient-validation issues rather than the middle of the dispatch loop, so the partial-state recovery is rare.

Channel — does the campaign builder pick between email and WhatsApp automatically, or do I commit to one upfront?

Commit upfront. The campaign builder at /marketing/campaigns is the email channel; the WhatsApp-campaigns surface at /marketing/whatsapp-campaigns is the messaging channel. The recipient picker is the same on both, but the channel-specific configuration (subject vs. message body shape, opt-in / consent gate, template content) differs enough that the surfaces are kept distinct.

For most outreach where channel is genuinely fungible, run the same campaign content through both surfaces — same segment, same message, dispatched through both — so customers receive the message on the channel they're reachable on. The Communications tab on each customer consolidates the touchpoint regardless of which channel delivered it.

When can I trust scheduled-send to fire on time?

Today: not at all. The scheduled-send runner is part of the same cron-runner layer that the automation execution loop depends on; both ship together. Until then, treat the schedule field as a planning marker and Send-now manually at the planned time. We'll update this page and the problem-page diagnosis when the runner lands; the last_verified date in the page frontmatter will move forward and the honest disclosure block will shift to past-tense.

If scheduled-send (or automation execution) is load-bearing for your store right now and the manual workaround doesn't fit your workflow, let us know — the cron-runner work is actively being scoped and tenant-pain feedback is the input that raises priority.

Scheduled campaign sits in scheduled past its configured time without sending

Symptom: a campaign you scheduled for an earlier time still shows status: scheduled; no “sent” row appears, no recipients received the message. Cause: expected today, documented in the honest disclosure section above. The runner that reads scheduled campaigns and dispatches them at the configured time isn't wired up yet. Fix:open the campaign and click Send now. The campaign dispatches immediately. Until the runner ships, schedule-then-walk-away isn't reliable — schedule-then-send-manually-at-the-planned-time is.

Send-now returns “No recipients found for this campaign”

Symptom: the Send now action returns the error and reverts the campaign to draft. Cause:the recipient picker's filter expanded to zero customers at send time. Several candidates: (1) the chosen segment's count was non-zero at picker time but the underlying customers no longer match the rule (e.g. Inactive 90+ days, and the customers were touched in between); (2) the chosen tags no longer match any customers; (3) the channel-specific filter (email present, phone present) removed everyone. Fix: open the campaign, re-confirm the recipient selection, maybe widen the cohort (different segment or broader tags). Hit Refresh on the segment card if you suspect the count drifted; pick a different segment if the original is now empty.

Campaign is stuck in sending status and won't let me retry

Symptom: a Send-now attempt failed (timeout, browser closed mid-send, network blip) and the campaign row is now in status: sending with no clear way to recover. Cause: the concurrent-send guard prevented the stuck state from double-blasting the list, but the catch-block revert to draft didn't fire (rare — usually because the page closed before the revert path executed). Fix: contact support with the campaign ID. We can read the audit log to confirm whether any send actually went out, and reset the row to draft (if no send) or sent with the recorded recipient set (if a partial send completed). The Communications-tab rows on affected customers are the source of truth for who actually received the message.

Edit on a sent campaign returns “Cannot edit a sent or sending campaign”

Symptom: the Edit affordance on a campaign card returns the guard message. Cause: the campaign has already been sent (or is currently sending). The row is locked because the historical accuracy of the recipient list, subject, and body would otherwise be lost — a sent campaign needs to read as the campaign that actually went out, not as a later edit. Fix: create a new campaign — Duplicate from the campaign list copies the recipient filter, subject, body, and template binding into a fresh draft you can edit and send. The original sent campaign keeps its historical record intact.

Stats show a high failed count after a campaign send

Symptom: the campaign sent successfully but the stats panel shows a meaningful percentage of failed recipients. Cause: several candidates. (1) Invalid or stale email addresses on the recipient list (rolled-up accumulation of typos, abandoned addresses, and consent-revoked recipients). (2) Provider rate-limiting on large sends — some providers cap concurrent dispatches. (3) Channel-specific bounce flags on the recipient's provider. Fix: expect a small failed count on every send. If the count is meaningfully high (over 5% of recipients), check the recipient list for stale addresses and consider a cleanup pass — the customer detail pages on the failed recipients will show the bounce-flag status. For rate-limiting, batch the send across smaller segments rather than one large one.