# Inviting your team A workspace is the boundary everything lives inside, so adding a colleague means giving a Google account access to that workspace — there is no password to issue, because Google sign-in is the only way in. Everyone who is in shares the same records, and every decision is recorded against the person who made it rather than against the workspace. - **Status:** Available - **Audience:** both - **In the app:** #/account, #/needs-you, #/autonomy-audit - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/getting-started/inviting-your-team/ ## What an invitation actually grants Access is to a workspace, and a workspace is the isolation root: nearly every record carries the workspace it belongs to and is filtered automatically at three independent layers. Inside that boundary, people work on one shared set of conversations, relationships, follow-ups and knowledge. There is no per-person copy of the data and no private sub-inbox. Because sign-in is Google-only, an invitation is really a decision about a Google account. That has two useful consequences: there is no password to circulate or rotate, and removing somebody's access is a decision made in one place rather than a hunt for credentials they may have kept. ## How the work divides in practice - **One person owns the queue each day.** Two people working Needs You from the top at once mostly produces collisions; agreeing who has it is a working practice, not a setting. - **Hand an item over rather than leaving it.** An approval nobody feels qualified to make sits at the top ageing, and the customer behind it is waiting on a decision nobody is making. - **Give `task` follow-ups a name.** Those are the ones nothing automatic will ever do; unowned, they are hopes rather than commitments. - **Let one person own the rules.** Knowledge and standing instructions written by four people in four styles contradict one another, and the contradiction shows up in drafts weeks later. The accountability side needs no agreement, because it is recorded automatically. Approvals and rejections are attributed to the person who made them, and the decision log answers 'who released this' months later without anyone having to remember. Refusals are recorded too — a decision not to act is still a decision. ## Why a colleague sees a refusal you do not Connect is one codebase serving two kinds of session: the platform operator's, and a customer workspace's. Both get the same feature set over the same implementation, but a customer session reaches it through a facade that rewrites the path, and anything the facade does not recognise is refused rather than passed through. A second allowlist in the middleware refuses any request a customer session is not permitted to make. The practical rule for a team: if something works for one person and is refused for another, the difference is almost always which kind of session they are in, not a fault in the feature. Two things are correctly available only to the platform operator, because they are about running the platform rather than using Connect — verifying customer payments, and JBRH's own pricing. > **Note** The facade failing closed is the intended behaviour, not a rough edge. [A tenant facade that fails closed](/research/closed-by-default-facade/) explains why refusing an unrecognised path is safer than guessing at it. ## Devices, sessions and leaving **Signing in as somebody else** — Ends the session it replaced on that browser, and only that browser. Your other devices are untouched, which is deliberate — one person switching accounts must not sign a colleague out elsewhere. **A shared or borrowed device** — Sign out on purpose. Nothing else will do it for you, and the session on that browser outlives the day. **Somebody leaving** — Remove the account's access to the workspace. The records they created stay: they belong to the workspace, and the decision log keeps its attribution so history remains readable. **The Assistant acting for a person** — It works within rights narrower than a human's — no pricing, and it cannot clear a do-not-contact entry — so 'the Assistant did it' never covers an action a person could not have taken. ## Questions ### Can I give somebody read-only access to one channel? What a given account may do inside a workspace is an account and access question rather than a getting-started one — [Account and access](/docs/account/) is the page for it. What is certain here is the boundary: whatever a person can do, they can do it only inside the workspace they were added to. ### Do colleagues need their own mailbox connected? No. Mailboxes belong to the workspace, not to individuals, and each has its own role, signature and autonomy. Several people work the same mailboxes, which is the point — the shared record is what lets one person pick up where another left off. ### Will adding people cost more? A workspace's use is bounded by its plan's allowances rather than by headcount in any way this page can state precisely. What changes with more people is usually volume, and volume is what allowances measure — the usage screen is where that shows up. ## Related - [Account and access](https://connectbyjbrh.com/docs/account/) - [Security and isolation](https://connectbyjbrh.com/docs/security/) - [One implementation, two audiences](https://connectbyjbrh.com/research/two-audiences-one-implementation/) - [A tenant facade that fails closed](https://connectbyjbrh.com/research/closed-by-default-facade/) - [Your first pass through Needs You](https://connectbyjbrh.com/docs/getting-started/read-needs-you/) - [Hand a conversation to a colleague](https://connectbyjbrh.com/docs/how-to/hand-over-to-a-colleague/) ## What this page is based on - docs-source/sources/GENERAL.md §1, §2 — two audiences, the facade and the allowlist - docs-source/sources/GENERAL.md §10 — Google-only sign-in and session replacement - Connect capability registry (docs-source/facts.py) — google_sign_in, rls_isolation