# Workspace administration

A workspace has members, each with a role, and the administrator is the person who may change how it works: autonomy, mailboxes, knowledge, integrations and the runtime switch. The model is wider than what you can reach today. There is no member-management screen, and a session resolves only when exactly one active administrator membership matches — so the practical shape is one administrator per workspace.

- **Status:** Foundation
- **Audience:** both
- **In the app:** #/account, #/autonomy, #/integrations, #/billing
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/account/workspace-admin/

## What exists, and what you can reach

Memberships are real records: a person, a workspace, a role and a status. Two roles are in use — the platform owner in the operator's workspace, and the administrator in a customer workspace — and session resolution reads them on every sign-in. That much is running in production and everything else on this page depends on it.

What is deliberately narrower is the surface over it. The account screen shows who is signed in, how, from where, and the sessions they hold. It does not offer team access, and neither does anything else today. Adding a colleague is not a self-service action, and a page that implied otherwise would be describing a control that does not exist.

> **Careful** One consequence is worth stating plainly, because it surprises people: a person with two active administrator memberships cannot sign in at all. Resolution requires exactly one match, so adding somebody to a second workspace does not give them a choice — it stops their sign-in until it is undone.

## What an administrator may change

| Area | May change | Recorded where |
|---|---|---|
| What Connect may do | Autonomy modes at any of the four scopes | The decision log, with the person who changed it |
| Channels | Mailboxes and their roles and signatures, phone lines, messaging integrations | Activity, and the mailbox or line's own health record |
| Knowledge and memory | Sources, facts, and what Connect knows at every tier | The record each of those keeps in its own screen |
| Runtime | The switch that stops Connect picking up new work | The decision log |
| Plan | Choices available inside the workspace's entitlement | Plan & Usage |
| Nothing outside the workspace | No cross-workspace read, no platform pricing, no payment verification | Refusals are recorded like any other decision |

The boundary is the workspace, not the role. An administrator is powerful inside one workspace and has no reach at all outside it — not because a screen hides the option, but because the request would be filtered by the workspace kernel and refused by row-level security even if it were made.

## How a workspace gets its administrator

1. Somebody signs in with Google for the first time.
   - Result: A workspace is created for them, with themselves as its administrator and an active membership recording it.
2. They configure it: mailboxes, knowledge, autonomy, channels.
   - Result: Every one of those changes is theirs, inside their workspace, and invisible to every other workspace.
3. A colleague needs access.
   - Result: This is the step the current surface does not cover. Ask JBRH rather than looking for a control — and see [adding a colleague, end to end](/docs/workflows/adding-a-colleague/) for the shape of it.

## What a refusal looks like

**A permission you do not have** — The action is refused and the refusal is recorded with the rule behind it, in the same shape as an action. An attempted change is as visible as a completed one.
**A path a customer session may not call** — Refused by the customer facade before any handler runs. This reads as a 403 on a screen rather than as a permission message — see [a screen returned 403](/docs/troubleshooting/403-on-a-screen/).
**Data in another workspace** — Not refused so much as absent: the kernel filters it out and the database enforces the same boundary independently. There is nothing to be denied access to.
**The Assistant asked to do it for you** — Its rights are narrower than yours, not wider. Asking it to do something you may not do does not route around the limit.

## Questions

### Can I add a second administrator myself?

Not today. Memberships and roles exist as records and session resolution reads them, but there is no self-service screen for granting one, and a second active administrator membership for the same person would stop their sign-in rather than widening their access.

### What happens to the workspace if its administrator leaves?

The workspace and everything in it are unaffected — records belong to the workspace, not to a person. Restoring access is an administrative action rather than something the departing person can hand over from a screen.

### Are refused attempts visible?

Yes. A refusal is recorded in the same shape as an action, because a refusal is a decision. That makes 'somebody tried to change this and could not' a question the decision log answers directly.

## Related

- [Account and access](https://connectbyjbrh.com/docs/account/)
- [Which workspace you are in](https://connectbyjbrh.com/docs/account/workspace-resolution/)
- [Your profile](https://connectbyjbrh.com/docs/account/profile/)
- [Who may change what](https://connectbyjbrh.com/docs/autonomy/permissions/)
- [Adding a colleague, end to end](https://connectbyjbrh.com/docs/workflows/adding-a-colleague/)
- [Granting a permission, end to end](https://connectbyjbrh.com/docs/workflows/workspace-admin-permission/)
- [Authorisation](https://connectbyjbrh.com/docs/security/authorization/)

## What this page is based on

- Connect source pack §1 and §2 — workspace scope and the isolation layers (`docs-source/sources/GENERAL.md`)
- `backend/app/app_auth.py` — roles, active memberships and the exactly-one-match requirement
- `backend/app/main.py` — the account payload, which deliberately carries no team access
- `backend/app/tenant_foundation.py` — the administrator membership created with a workspace