Account and access
Access to Connect has four parts: Google sign-in, which is the only way in; a session, which belongs to one browser; a workspace, which is the isolation root every record belongs to; and a role, which decides what you may change inside it. Your plan sits beside these and governs allowance and volume — never permission.
The four things that decide what you see#
- Identity
- One Google account, bound to one Connect user the first time it signs in. There is no password login to fall back to, and no second way to prove who you are.
- Session
- A signed-in browser. Sessions are per browser and per device, so ending one leaves the others alone.
- Workspace
- The isolation root. Every record belongs to exactly one, and the boundary is enforced three separate times between your browser and the database.
- Role
- What you may change inside that workspace. The operator's workspace has a
platform_owner; a customer workspace has aworkspace_admin.
Those four are resolved in that order on every request, which is why a problem in one of them looks so different from a problem in the next. A failure at identity keeps you out; a failure at workspace resolution lets you in and shows you the wrong data — or, more often, none.
The pages in this section#
| If you want to know | Read |
|---|---|
| How to get in, and what Google is asked for | Signing in with Google |
| How long you stay signed in | Sessions |
| What happens when somebody else signs in on your browser | Signing in as somebody else |
| Why a Google account can be refused as a mismatch | How your Google account binds to a person |
| Which workspace a request belongs to | Which workspace you are in |
| How the operator's workspace differs from a customer's | The operator's workspace and a customer's |
| Who may change members and settings | Workspace administration |
| What is yours rather than the workspace's | Your profile |
| Active sessions and what to do after a lost device | Security settings |
| What a plan governs | Your plan |
Isolation, three times over#
A workspace is not a filter applied at the end. A request passes three independent boundaries: the customer_safe allowlist in the middleware, which refuses any path a customer session may not call; the SQLAlchemy workspace kernel, which filters every scoped table; and row-level security in PostgreSQL, forced on those tables. Each would be sufficient on a good day. Having three is what makes a bug in one of them survivable.
The practical consequence for a reader of these pages: data belonging to another workspace is not hidden from you, it is unreachable, and a record with no workspace stamp is invisible rather than shared. Workspace isolation covers the mechanism; the account pages cover what it means for a person.
What is not here#
- There is no password sign-in, no recovery code and no second factor inside Connect. Two-step verification is Google's, on the Google account you sign in with.
- There is no lock screen, no language and region setting, and no team-access panel. Controls that do nothing are worse than absent ones, so they are absent.
- There is no way to move a record between workspaces from the account screens. Isolation is the point of a workspace; a transfer control would be a hole in it.
- Nothing here changes what Connect may do on your behalf. That lives in What Connect may do, which is a separate control with a separate log.
Everything in this section#
13 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| Entitlements and runtime choice | Entitlement is what your plan grants; runtime is what your workspace has switched on, and Connect acts only when both agree. |
| How your Google account binds to a person | Connect binds one Google identity to one user on first sign-in. Where that binding is stored, why there are two stores, and what a mismatch means. |
| Security settings | The security controls a person genuinely has: the list of live sessions, one action that ends all the others, and what to do the day a device goes missing. |
| Sessions | A signed-in browser, how long it stays signed in, what ends one, and why your other devices are unaffected by anything that happens to this one. |
| Signing in as somebody else | Signing in as a different person on the same browser ends the session that browser was holding — that one only, never that person's other devices. |
| Signing in with Google | Google is the only way into Connect. What the sign-in asks for, what is kept afterwards, and the four reasons it can refuse you. |
| The operator's workspace and a customer's | One codebase serves the platform operator and every customer. The feature set is identical; the difference is commercial, plus two screens about running the platform. |
| Usage and allowances | What Connect counts against a plan, how a daily allowance is reserved before the work happens, and what you see as a limit gets close. |
| When a plan lapses | What stops when a workspace plan is no longer live, what waits instead of failing, what is refused outright, and what is never deleted. |
| Which workspace you are in | Every request runs inside exactly one workspace. How that one is chosen from your memberships, and why a second membership stops a sign-in rather than offering a choice. |
| Workspace administration | Memberships, roles and what an administrator may change — and the deliberate limit: no member management on the account screen. |
| Your plan | A plan decides how much a workspace may do, never what it is allowed to do. What that distinction covers, and the one place it is easy to get backwards. |
| Your profile | What Connect keeps about you personally is deliberately small. Where the line falls between your details and the workspace's, and why the signature is not yours. |
Questions#
Can I sign in without a Google account?
No. Google sign-in is the only route, deliberately: one authentication path is one path to secure, and a password store that exists 'just in case' is a liability with no compensating benefit. If your organisation does not use Google accounts, Connect cannot sign you in today.
Does signing in on my phone sign me out of my laptop?
No. A session belongs to one browser. Signing in somewhere new adds a session; it does not disturb the ones you already have. The one exception is signing in as a *different person* on the same browser, which ends that browser's previous session and nothing else.
Do the Owner and a customer see different features here?
No. The feature set is identical and runs on the same implementation; the difference is commercial. A customer's use is bounded by their plan's allowances, and the Owner has no plan and no allowance gates.