# 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.

- **Status:** Available
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/lapse-and-recovery/

## The flow, stage by stage

1. Trigger — the workspace stops being live for sending: a subscription ends, a trial expires, or a required pass runs out.
2. User or external event — customers keep writing throughout. That is the whole problem a lapse creates; the messages are fine, the silence is not.
3. Authentication and workspace resolution — unaffected. People sign in, switch workspace and read everything they could read before.
4. 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.
5. Canonical record — the records already in the workspace are untouched. Nothing is deleted, archived, downgraded or hidden.
6. 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.
7. Knowledge, memory and rules — intact throughout, and intact on the other side. Nothing has to be re-taught.
8. 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.
9. Action through a provider — nothing is handed to any provider while the gate is closed.
10. Result — recovery: the entitlement becomes live again, and the next pass picks up.
11. 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.
12. 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

1. 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.
2. 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.
3. 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.
4. 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.

> **Careful** Read the pre-lapse drafts before approving them. A reply written a fortnight ago answers a fortnight-old message, and sending it unchanged reads to the customer as though nobody had been listening since. Regenerating gives the model the newer messages; editing does not.

## 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.

## Related

- [When a plan lapses](https://connectbyjbrh.com/docs/account/lapsed-plan/)
- [The plan has lapsed](https://connectbyjbrh.com/docs/troubleshooting/plan-lapsed/)
- [Changing plan, end to end](https://connectbyjbrh.com/docs/workflows/plan-change/)
- [Usage and allowances](https://connectbyjbrh.com/docs/account/usage/)
- [Needs You](https://connectbyjbrh.com/docs/autonomy/needs-you/)
- [The mailbox disconnected](https://connectbyjbrh.com/docs/troubleshooting/mailbox-disconnected/)

## What this page is based on

- `backend/app/tenant_entitlements.py` — the live-plan gate and where it is read
- docs-source/sources/CHANNELS.md section 1 — held work, the read cursor and mailbox health
- docs-source/sources/GENERAL.md section 2 — the order the engine works in
- Connect capability registry (docs-source/facts.py)