Disconnecting a mailbox
Disconnecting ends the connection, not the history. New mail stops arriving at that address and nothing more can be sent from it; the threads, messages, contacts, memory and audit entries it produced are canonical workspace records and remain exactly as they were. Anything held for that mailbox stops being sendable, which is the part worth planning for.
Two columns, and nothing in between#
| Stops | Is kept |
|---|---|
| Fetching new mail from that address | Every thread and message already canonicalised |
| Sending anything from that address | Contacts, identities and the relationships built from them |
| Write-back to the provider | Memory at every tier, including anything set on that mailbox |
| The mailbox's own health verdicts | The audit trail — what was decided, under which rule, and what happened |
| That mailbox as a fallback sender | Files, knowledge and facts drawn from its correspondence |
The asymmetry is the point. A mailbox is a source and a route, and canonical records are not owned by the source that produced them — the bridge copies into them, so removing the adapter removes nothing downstream. That is the same property that lets a provider be added without touching the engine, read in the other direction.
Work in flight#
- A held draft for that mailbox
- Stays visible in Needs You and can no longer be released, because approval sends through the mailbox the thread belongs to and that route is gone. Deal with these before disconnecting.
- A message already acknowledged by the provider
- Gone and unaffected. Disconnection does not recall mail.
- A message in the uncertain state
- Stays uncertain. Disconnecting removes the ability to learn any more about it, which is a reason to resolve uncertain sends first.
- A follow-up scheduled on that address
- Still due. Give the workspace another mailbox that can serve as sender, or the follow-up has no route.
- Threads that arrived on that mailbox
- Remain readable, searchable and attached to their people. They are simply no longer a place new mail can arrive.
The order that avoids a gap#
Clear the approval queue for that mailbox — approve or reject what is waiting.
Result Nothing is stranded in a state where a person keeps clicking approve on a message that has nowhere to go.
If this mailbox is the workspace's default sender, give another mailbox that role first.
Result Anything that starts a new conversation still has an identity to use. The primary mailbox covers the fallback order.
Stop mail being delivered to the address at your provider, or forward it somewhere that is connected.
Result Mail arriving at an address nobody reads is the failure that outlives the disconnection by months.
Disconnect the mailbox at
#/mailboxes.Result The row's fetching and sending end. Existing records are untouched.
Revoke Connect's access at the provider if the connection was OAuth.
Result The grant lives at Google or Microsoft, not here, so removing the mailbox row is not by itself a revocation.
Reconnecting later#
Connecting the same address again produces a working mailbox, and the workspace's existing threads and contacts are still there — they were never the mailbox's. What it does not do is retroactively fill the period when nothing was connected: mail that arrived while the address was disconnected is subject to whatever the provider still offers when the first pass runs.
The uniqueness check is what stops a reconnection becoming a duplicate row. That check is exactly what an empty workspace_id once defeated — find_by_key could not see an unstamped row, so the address looked unconnected and a second row would have been written for one real inbox. Both the list and the check now use the one query that can see such rows.
Questions#
Does disconnecting delete my conversations?
No. Threads, messages and contacts are canonical workspace records that outlive the connection. What ends is the ability to receive and send at that address.
Is disconnecting the same as revoking access at Google?
No, and doing only one leaves the other in place. Removing the mailbox row stops Connect using the grant; revoking at the provider ends the grant itself. For a clean exit, do both.
What happens to a draft that was waiting for approval?
It remains visible but cannot be released, because approval sends through the thread's mailbox. Clear the queue before disconnecting rather than after.