Authentication & access

The CRM is a single-tenant internal tool behind sign-in. Everyone who signs in can see and work every record; three things are gated to the workspace owner or an admin — renaming the workspace, changing a teammate's role, and configuring SSO.

ALLOWED_SIGN_IN is the whole authorization model

A comma-separated list, each entry a whole email domain or a single address:

ALLOWED_SIGN_IN="acme.com"                       # everyone at a workspace
ALLOWED_SIGN_IN="acme.com,contractor@gmail.com"  # …plus one outsider
ALLOWED_SIGN_IN="you@gmail.com"                  # a one-person install

An empty list fails closed — nobody signs in until it's set. It's read by two things that must never disagree: the sign-in guard, and the sync's decision about which side of a conversation is external.

Google sign-in

The built-in method, and what a clone starts with. The same OAuth client is the sign-in button and the Gmail / Calendar sync. GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET are set together or not at all. A rep who signed in with Google must grant the two read-only scopes to use the CRM; anyone missing one is sent to a Grant access screen to re-consent.

SSO is a row, not a deploy

An install with its own identity provider adds one on Settings → SSO — issuer URL, client id, client secret. The whole configuration is a database row written by the auth layer, not an environment variable, because a self-hoster's admin cannot redeploy.

• OpenID Connect only. SAML needs a certificate and signing key this app has nowhere to keep.
• The provider's button appears on the sign-in page alongside Google — it doesn't replace or disable it.
• Signing in through an IdP proves who you are; it does not by itself connect Gmail. An SSO rep links Google from Settings → Connections if they want the mailbox sync, and isn't locked out for skipping it.
• ALLOWED_SIGN_IN still decides who may have an account, on an SSO sign-up exactly as on a Google one.

Bootstrapping the first provider

An install with no Google client and no provider yet has nobody who can reach the SSO settings page. Six optional SSO_BOOTSTRAP_* variables register one provider automatically the first time the API boots — the same effect as filling out the form once. Set all five required ones together or leave them blank; partial config logs a warning and does nothing. Once the row exists, the variables are never read again for it, so a later edit in Settings is never reverted by a stale .env.

The local admin door

/admin-login is a second, separate door — email and password stored in this app's own database, with no dependency on Google, SSO, or ALLOWED_SIGN_IN. It exists for getting into a workspace before any of those are configured.

• Registration is open to anyone who reaches the page.
• Logging in grants full workspace owner access — the same as the first person who ever signed in with Google. There is no narrower admin role.
• Once in, an admin is a real workspace owner, not a separate UI — every existing page just works.
• Logging out clears both the admin session and the workspace session.

Worth deciding whether to leave it reachable on a real deployment.

The singleton workspace

There is exactly one workspace, and it is not a tenancy boundary — no CRM record carries an organization id. What exists is one row that answers three questions the CRM has to answer about itself:

Question	Field
What is this company called?	Name — also the URL slug (/acme/companies)
Who works here?	Members, with an owner / admin / member role each
What do we sell?	Website — researched by the agent into the "Who we are" block every session opens with

Onboarding

The first person to sign in becomes the owner. One short form — Name and Website — stands between a fresh install and a usable CRM. The website isn't decoration: saving it queues the agent to research your own company, and the result is what keeps it from pitching your own product back to you. Both fields can be changed later on Settings → General; changing the website re-triggers that research.

Members

• Signing in is the invite. Add someone's email or domain to ALLOWED_SIGN_IN and they're enrolled automatically the next time they sign in. There is no invite flow.
• Change a member between owner, admin and member on Settings → Members.
• The workspace can never be left with zero owners — demoting the last one is refused.