When a plan lapses
A lapsed plan closes the metered gate, not the door. Sending stops, ingesting new mail stops and model work for the workspace stops, each with a plan message rather than a technical error. Everything already in the workspace stays exactly where it is — threads, people, memory, knowledge, held drafts and dated follow-ups — and the mail nobody has fetched yet is still sitting at the provider, unread and unskipped.
What the gate actually checks#
Metered work asks three questions before it starts, and a lapse is a failure of the first two. They are asked at the moment work is reserved, which is why a lapse looks like an immediate, quiet stop rather than a screen full of errors.
- Is this workspace live? Only two states count as live: an active subscription and a trial that has not ended.
- Has the trial run out? An end date in the past reports as expired even while the stored status still reads otherwise, so nobody is misled by looking at the wrong field.
- Where a plan requires a current pass alongside the subscription, is that pass still valid? An expired one refuses in the same shape as an inactive subscription.
What stops, in the order you notice it#
| Activity | During a lapse | Why |
|---|---|---|
| Sending on any channel | Refused, with a plan message | Sending is a metered event, and metering asks the plan question first |
| Fetching and storing new mail | Refused; the read cursor does not move | Ingest is metered too. Not moving the cursor is what keeps the unfetched mail recoverable |
| Model work for the workspace | Refused | Model calls made on the workspace's behalf are a metered dimension in their own right |
| Reading what is already there | Works normally | Nothing about reading is metered; the records are the workspace's own |
| Signing in and switching workspace | Works normally | Identity and membership are platform concerns, not plan concerns |
| Deleting or exporting your own records | Works normally | A lapse is a commercial state, never a lock on your data |
The order people actually notice is usually the reverse of that table: a reply that does not go, then a quiet inbox, then the realisation that Connect has not written anything since yesterday.
What is held rather than lost#
- Held drafts
- Stay in Needs You with the message they answer. They are not discarded and they are not sent later on their own; a person still approves them once the workspace is live again.
- Dated follow-ups
- Keep their date and their reason. One whose date passes during a lapse becomes late rather than cancelled, and is visible as late.
- Unfetched mail
- Stays at the provider. Because the read cursor is not advanced on a refusal, the next successful sync starts where the last one really finished.
- Suppression and do-not-contact
- Stay in force throughout. A lapse never relaxes a compliance rule, and the Assistant cannot clear a do-not-contact entry in any state.
- Standing instructions and rules
- Untouched. They describe how Connect should behave, and they resume describing it the moment work resumes.
What is never deleted#
A lapse removes permission to spend, not the right to your own records. Threads and messages, people and companies, opportunities and support cases, memory at every tier, knowledge sources and their facts, files, the decision log — all of it remains in the workspace, readable and exportable, for as long as the workspace exists.
Two things do decay on their own during a long lapse, and neither is a deletion. A provider connection can go stale because the provider expires its own authorisation, which shows as a mailbox needing reconnection rather than a missing mailbox. And a draft written before the lapse can become an answer to an older message, which is why the queue shows when a thread has moved on.
Coming back#
Recovery is not a restore: nothing was archived, so nothing is unpacked. The plan becomes live again, the next engine pass finds the same held work in the same order, and the read cursor picks up where it stopped. The full sequence, including what resumes first and what a person should check before letting it run, is in A lapsed plan and its recovery.
Questions#
Does a lapse delete my data?
No. A lapse is a gate on metered work — sending, ingesting and model calls. Every record already in the workspace stays readable and exportable, including the decision log. Retention is a separate matter with its own rules; see Data retention.
Will messages sent to me during a lapse be lost?
Not at the provider. Connect stops fetching, and because a refusal never advances the read cursor, the messages stay where they are and are collected on the next successful sync. What is genuinely lost is the time: nobody replied while the workspace was not live.
Do held drafts send themselves when the plan comes back?
No. A held draft is held because a rule said a person decides, and that rule is unchanged by the plan state. Coming back live restores the ability to send; it does not grant approval on anyone's behalf.