# Removing a workspace, end to end

Removal is layered, and there is no single button that performs it. Access ends first: a workspace that is not active resolves no session, so every screen closes at once. Provider connections are revoked separately at each provider. Erasure of the stored records is an operator action taken outside the application's screens, deliberately, so that nothing performs it by accident.

- **Status:** Available (operator)
- **Audience:** owner
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/workspace-deletion/

## Three separate things people mean by 'delete'

**Ending access** — The workspace stops being active. Session resolution refuses immediately for every member, on every device, without waiting for a session to expire.
**Stopping the flow** — Provider connections are revoked. Fetching and sending end at the provider, which is the only place they can genuinely be stopped.
**Erasing the records** — The stored rows are removed. This is not exposed as a screen or an endpoint anywhere in the application, and it is not something a customer session can reach.

Conflating the three is the usual source of trouble. Ending access looks like deletion from the inside and changes nothing about what is stored; revoking a connection stops the future and touches nothing in the past. Being explicit about which one is wanted is most of the work.

## Stage by stage

1. Trigger — the operator decides a workspace should be removed, usually because an account has ended or was created in error.
2. User or external event — the members are still signed in at this point. The first thing they experience is being unable to reach anything, so telling them beforehand is part of doing this properly.
3. Authentication and workspace resolution — the workspace ceasing to be active is what does the work: resolution requires an active workspace, so an inactive one has no sessions, not merely fewer permissions.
4. Ingest or request — inbound work stops finding a destination. A carrier callback for a number belonging to that workspace no longer resolves to a workspace that can accept it.
5. Canonical record — the workspace's business rows still exist and are still scoped. They are invisible rather than gone, which is a genuinely different state.
6. Reasoning — none, and nothing scheduled runs for the workspace any more, because the engine works through workspaces that are active.
7. Knowledge, memory and rules — retained with everything else until erasure. Nothing is selectively pruned, because a half-erased workspace is harder to reason about than either whole state.
8. Autonomy and approval — moot. There is nothing to approve and nothing that could act.
9. Action through a provider — revocation is per connection and per provider. A mailbox grant withdrawn at Google is withdrawn there; nothing Connect stores can undo that from its own side.
10. Result — members see the sign-in screen and cannot get past it. That is the whole visible effect, and it happens at once rather than gradually.
11. Relationship, timeline and memory — untouched by ending access; removed only by erasure, which is a separate, deliberate step.
12. Audit, usage and Needs You — control-plane records remain: who signed in, what was verified, what was decided. Those never lived inside the workspace to begin with.

## What stays, and why that is correct

Several records are outside every workspace by design, and removing a workspace does not touch them: platform identity, sessions, billing and payment verification, and enquiries addressed to the operator through the public site. They are control-plane rows, not workspace rows.

This is not an oversight. A payment verification that vanished with the workspace it activated would leave the operator unable to answer a question about money that was genuinely received; a platform identity that vanished would let the same address create a fresh workspace and appear to have no history. Keeping them is the reason the boundary between the control plane and workspace data exists at all.

> **Careful** Data that is invisible is not data that is gone. A workspace whose access has ended still holds every message, call and file it held before. If the requirement is genuine erasure, ending access does not satisfy it and must not be reported as though it had.

## What cannot be undone

- Messages already sent. Outbound mail that reached a recipient is with the recipient, and nothing here recalls it.
- A revoked provider grant. Reconnecting means consenting again at the provider; there is no stored copy to restore, because credentials are sealed on save and never echoed back.
- A released phone number. Once a number goes back to the carrier it is no longer a record inside the workspace, and inbound calls to it stop resolving there.
- Erasure itself. Once the rows are gone there is no in-application path that recreates them, and nothing in the product pretends otherwise.

Everything else about ending access is reversible in the plain sense: a workspace made active again resolves sessions again, and its members find their history where they left it. That asymmetry is deliberate — the reversible step is the one exposed, and the irreversible one is the one that takes a deliberate operator action outside the screens.

## Questions

### Can a customer delete their own workspace from the app?

No. There is no self-serve delete, and this page does not describe one. A customer who wants their workspace removed asks the operator, and the operator performs the steps above.

### Does ending access stop mail being fetched?

Scheduled work no longer runs for an inactive workspace, so nothing new is pulled in. The connection itself still exists at the provider until it is revoked there, which is why revocation is listed as its own step rather than assumed.

### Is a removed workspace's data visible to anybody else?

No. Isolation does not depend on the workspace being active: the rows still carry their workspace stamp and are still filtered in the query layer and by the database. Another workspace sees nothing, before or after.

## Related

- [Creating a customer workspace, end to end](https://connectbyjbrh.com/docs/workflows/workspace-creation/)
- [What is kept and for how long](https://connectbyjbrh.com/docs/security/data-retention/)
- [Workspace isolation](https://connectbyjbrh.com/docs/security/workspace-isolation/)
- [Workspace administration](https://connectbyjbrh.com/docs/account/workspace-admin/)
- [Data that is invisible rather than missing](https://connectbyjbrh.com/research/workspace-stamp/)
- [How provider credentials are stored](https://connectbyjbrh.com/docs/security/credential-sealing/)

## What this page is based on

- `backend/app/app_auth.py` — session resolution requires an active workspace
- docs-source/sources/GENERAL.md §3 — scoped tables and the control-plane exception
- docs-source/sources/GENERAL.md §10 — sealed credentials
- Connect capability registry (docs-source/facts.py)