# Which workspace you are in

A workspace is chosen when your session is created, from your active membership. The operator's account resolves to the operator workspace; everybody else resolves to the single workspace they administer. Exactly one active membership must match — none refuses the sign-in, and two refuse it as well, rather than guessing which you meant.

- **Status:** Available
- **Audience:** both
- **In the app:** #/account, #/home
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/account/workspace-resolution/

## How it is decided

1. You sign in and Connect resolves your identity.
   - Result: At this point Connect knows who you are and nothing about where you work.
2. It looks for the membership that matches your role.
   - Result: For the operator's account, an active platform-owner membership in the operator workspace. For everybody else, an active workspace-administrator membership.
3. It requires exactly one match.
   - Result: Zero matches and the session is refused. Two or more and it is also refused — deliberately, because picking one silently is how somebody ends up working in the wrong company's data.
4. It checks the workspace is active and has an entitlement.
   - Result: A workspace that is suspended, or has no commercial record at all, does not produce a session.
5. The workspace is stamped on the session.
   - Result: Every later request enters that workspace before it reaches any handler, and everything it reads or writes is filtered to it.

> **Note** The operator is not exempt from any of this. The operator's requests run inside the operator workspace exactly as a customer's run inside theirs. There is no unscoped mode for anybody — even a deployment with authentication switched off still confines every API request to one workspace, because falling through unscoped means no filter at all.

## What a second membership means

It means you cannot sign in until it is resolved. Connect does not present a workspace picker and does not choose the newest, the largest or the first. Two active administrator memberships is treated as a configuration problem, and the honest response to an ambiguous question is to refuse it rather than to answer it arbitrarily.

That is a real constraint worth planning around: one person cannot administer two customer workspaces from one Google account today. Two accounts, one per workspace, is the arrangement that works — and it has the side benefit that every decision recorded against a person names which business it was made in.

> **Careful** If a sign-in that used to work stops, and nothing about your Google account has changed, a membership added elsewhere is a strong candidate. It is the one failure here that is caused by somebody else's administrative action rather than by anything you did.

## What being in a workspace changes

| Data | Scoped to the workspace? | Consequence |
|---|---|---|
| Conversations, contacts, calls, follow-ups | Yes | Unreachable from any other workspace, not merely hidden from its screens |
| Knowledge, memory, autonomy settings, files | Yes | A rule or a fact set in one workspace has no effect anywhere else |
| Your identity and your sessions | No — platform records | Which is what lets one person hold sessions for different workspaces without the two touching |
| Billing and entitlement records | No — platform records | The plan is about the workspace but is not stored inside its scoped data |
| Enquiries sent to JBRH through the public website | No — outside every workspace | By design: they are addressed to the operator, not to any customer |

A record that carries no workspace stamp is invisible rather than shared. That is the property worth internalising: the failure mode of this design is data nobody can see, never data the wrong person can see. [A row with no workspace stamp is invisible, not missing](/research/invisible-not-missing/) works through what that looks like in practice.

## Telling which workspace you are in

- The account screen names it, along with whether the session is an operator session or a customer one.
- The identifier is stable and derived rather than sequential, so it does not change as the business grows and it reveals nothing about how many workspaces exist.
- If a screen is unexpectedly empty rather than erroring, the workspace is usually the thing to check first — an empty workspace and a wrong workspace look identical.
- If a screen returns a refusal instead, that is a different mechanism: the customer facade refusing a path, not the workspace being wrong. [A screen returned 403](/docs/troubleshooting/403-on-a-screen/) covers it.

## Questions

### Can I switch workspaces without signing out?

No. The workspace is fixed when the session is created, so changing it means a new session. On one browser that also ends the session it replaces, which is covered in [signing in as somebody else](/docs/account/session-replacement/).

### Why refuse a second membership instead of asking me which one?

Because the cost of the two outcomes is not symmetric. A refused sign-in is an inconvenience somebody fixes in a minute; a silent wrong choice puts one business's work into another's records, and nothing downstream would notice.

### Does the operator see across workspaces?

Not through the normal screens. The operator's session resolves to the operator workspace and is filtered to it like any other, by the same kernel and the same row-level security. Running the platform involves platform-level records, which are a separate thing from another workspace's data.

## Related

- [Account and access](https://connectbyjbrh.com/docs/account/)
- [The operator's workspace and a customer's](https://connectbyjbrh.com/docs/account/owner-vs-tenant/)
- [Workspace administration](https://connectbyjbrh.com/docs/account/workspace-admin/)
- [Workspace isolation](https://connectbyjbrh.com/docs/security/workspace-isolation/)
- [Resolving which workspace a request belongs to](https://connectbyjbrh.com/docs/workflows/workspace-resolution-flow/)
- [You are in the wrong workspace](https://connectbyjbrh.com/docs/troubleshooting/wrong-workspace/)
- [A row with no workspace stamp is invisible, not missing](https://connectbyjbrh.com/research/invisible-not-missing/)

## What this page is based on

- Connect source pack §2 and §3 — the request path, `SCOPED_TABLES` and the control-plane exception (`docs-source/sources/GENERAL.md`)
- Connect capability registry (`docs-source/facts.py`) — `workspace_resolution`, `rls_isolation`
- `backend/app/app_auth.py` — the membership lookup that requires exactly one match
- `backend/app/main.py` — every API request runs inside a workspace, including the operator's