Workspace lifecycle
Review owner-only deletion and its impact on consumers and active work
Deleting a workspace removes its governed contents and makes its workspace-scoped MCP endpoint unavailable. This is different from renaming it, revoking a key or removing an employee from the SSO join list.
You need a Semogram account as workspace Owner. A general administrator or service key should not be treated as owner authorization. Active work must finish or be handled before deletion can proceed.
Before deleting
Inspect projects, running/queued work, installed connections, endpoints, keys and dependent services. Retain/export needed records through supported paths and resolve uncertain external writes. Workspace deletion does not mean every external system's records are reversed or removed; those systems have separate ownership and lifecycle.
In Workspace settings, use Delete workspace and review the confirmation for the exact workspace. If deletion is blocked by active work, inspect pipeline/prediction and other active operations rather than repeatedly retrying deletion.
MCP exposes workspace_delete only for an owner-authenticated workspace context, requires org:manage and explicit confirm true. Success makes that endpoint cease to exist. Do not use it as a cleanup step in an example or ask an assistant to delete an ambiguous workspace name.
Less extensive changes
| Goal | Control |
|---|---|
| Stop a service from authenticating | Revoke its API key |
| Remove access to a binding | Remove the relevant custom grant |
| Stop future SSO joins | Remove the allowed email or disable new SSO sign-ins |
| Stop future scheduled work | Pause the relevant schedule/watchlist |
| Stop an active invocation | Use its applicable cancellation workflow |
These actions have separate effects. Pausing a schedule does not cancel existing work; join-list removal does not revoke existing membership; revoking a key does not undo past writes.