A lapsed plan and its recovery, end to end
Recovery is not a restore. Nothing was archived during the lapse, so nothing is unpacked: the workspace becomes live, and the next engine pass does what it always does — fetch, then think, then act — on exactly the work that was waiting. The one thing worth doing first is reading the held queue, because drafts written before the lapse are answers to older messages.
The flow, stage by stage#
- Trigger — the workspace stops being live for sending: a subscription ends, a trial expires, or a required pass runs out.
- User or external event — customers keep writing throughout. That is the whole problem a lapse creates; the messages are fine, the silence is not.
- Authentication and workspace resolution — unaffected. People sign in, switch workspace and read everything they could read before.
- Ingest — refused while the workspace is not live, and the mail read cursor is deliberately not advanced, so nothing at the provider is skipped past.
- Canonical record — the records already in the workspace are untouched. Nothing is deleted, archived, downgraded or hidden.
- Reasoning — model work for the workspace is metered, so it stops too. Connect does not quietly keep thinking on a workspace that is not live.
- Knowledge, memory and rules — intact throughout, and intact on the other side. Nothing has to be re-taught.
- Autonomy and approval — unchanged by the lapse. Held drafts stay held; a lapse is not an approval and coming back live is not one either.
- Action through a provider — nothing is handed to any provider while the gate is closed.
- Result — recovery: the entitlement becomes live again, and the next pass picks up.
- Relationship, timeline and memory — timelines show the gap honestly. A lapse is visible in the record as a period with nothing in it, which is what actually happened.
- Audit, usage and Needs You — refusals were recorded as they happened, so the log explains the quiet period rather than leaving it unexplained.
What resumes, in what order#
Restore the workspace to a live plan.
Result Nothing happens yet. The gate is read at the next metered event, not at the moment of payment.
Let the next sync run.
Result Mail is fetched from where the cursor really stopped. A long lapse means a large first sync; that is the cost of not having skipped anything.
Let the engine think.
Result The backlog is classified and drafted in priority order rather than arrival order, because priority is what the engine reads when it picks work.
Work the queue.
Result Held drafts — the ones from before the lapse and the ones just written — are approved, edited or rejected by a person. Nothing sends itself as a consequence of the plan being restored.
What the customer on the other end experienced#
Nothing bounced and nothing was rejected. Their messages arrived normally at your provider and sat there. From their side a lapse looks exactly like a business that stopped replying — which is the honest description of it, and the reason a lapse is worth resolving in hours rather than days.
Anything that was suppressed, unsubscribed or marked do-not-contact stayed that way throughout. A lapse never relaxes a compliance rule, so recovery cannot accidentally send to somebody who had opted out during it.
Two things to check before letting it run#
- Mailbox health
- A long lapse gives a provider time to expire its own authorisation. A mailbox that needs reconnecting shows as a health verdict rather than as missing mail; fix it before judging the first sync.
- Follow-ups that came due
- Dated commitments that passed during the lapse are late rather than cancelled. Decide which are still worth honouring before a queue of them executes at once.
- The runtime mode
- If somebody set the workspace to Draft only while it was not sending anyway, it is still in Draft only afterwards. That is often the reason nothing sends after a successful recovery.
- The first day's allowance
- A backlog can spend a daily counter quickly. Sending stops at the limit and resumes at midnight UTC — expected, but worth knowing before it is mistaken for a second lapse.
Questions#
Will Connect send a burst of old replies when the plan comes back?
Only if a person approves them. Held drafts are held by an autonomy rule, and no commercial change answers a human decision. In Auto within rules, newly written replies do go out — which is precisely why the queue and the mode are worth checking before the first pass.
How far back does the first sync go?
To wherever the read cursor genuinely stopped. Because a refusal never advances it, the cursor still points at the last message that was actually processed, so the gap is collected in full rather than skipped.
Is there anything I have to re-teach Connect?
No. Knowledge, memory, standing instructions, autonomy rules and the business profile all survive a lapse untouched. The only things that can need attention are provider connections, which expire on the provider's schedule rather than yours.