Cloud Onboarding

This is the hosted onboarding path: how a real person signs in to a hosted Consystence organisation, reaches its subdomain, and becomes a member. It is deliberately distinct from spinning up a server on your own machine — for that, see Installation.

The path has three moving parts:

1. Sign in through Entra External ID.
2. Reach your org at its subdomain — {slug}.consystence.com for enterprise-family tenants, {slug}.consystence.dev for integrator-family tenants, sandboxes, and trials.
3. Join via an explicit membership — an email invite from an owner, or added/approved directly by an owner or admin. (Auto-requested joins on a bound email domain are a roadmap convenience.)

Beta — behind launch gates

Consystence is in public beta. The account control plane and billing run in production behind launch gates: new tenants pass through an operator approval gate before any DNS or cell side-effects occur, and self-serve purchasing can be centrally disabled during the launch window. The flow on this page is the shipped production code path.

Step 1 — Sign in with Entra

Consystence uses Entra External ID (Microsoft’s CIAM) as its identity provider, reached through the Consystence sign-in domain (id.consystence.com). Interactive browser sign-in yields a CIAM Bearer token that the platform validates on every request.

There is no local email/password store, no self-hosted registration, and no MFA prompt owned by Consystence — those are Entra’s responsibility. The browser session selector accepts only the CIAM Bearer scheme for human users; programmatic and site-PIN schemes exist for other callers. See Authentication for the full MultiAuth model.

Signup is also where legal consent happens: the signup screen carries consent-by-continuing copy — by continuing, you accept the Consystence Terms of Service and Privacy Policy.

Identity is your Entra oid, not your email

Your stable identity — the membership key — is your Entra object id (oid). It is immutable and identical across the account control plane and every cell, so one person resolves to one identity everywhere.

Your email is a verified attribute, not your identity. That distinction matters:

• The same account (the same oid) can be a member of one organisation and an admin of another, simultaneously.
• Changing or adding a verified email never changes who you are.
• Email is used as the domain-binding signal (below) — never as the thing access is keyed on.

Note

Organisations themselves are keyed by an account-minted UUID (org_* format), not by a slug and not by anyone’s oid. The slug you see in the URL is a routing label (rename is not currently supported); the UUID is the identity. See Organisation & site model.

Step 2 — Reach your org subdomain

Each tenant lives at its own subdomain. One URL, one login, one tenant boundary, following the Slack / Notion / GitHub subdomain pattern. The canonical domain follows the tenant’s licence family: enterprise-family tenants (SME, Enterprise, Enterprise Unlimited) live at {slug}.consystence.com — for example acme.consystence.com — while integrator-family tenants (Integrator, Integrator Pro, Certified Partner) and all sandboxes and trials live at {slug}.consystence.dev. A slug is unique per canonical domain, so acme can exist once on .com and once on .dev. Every tenant additionally gets {slug}.consystence.io — a per-tenant alias for its AI chat surface.

Sites are paths under that subdomain (/sites/{code}), never their own top-level domains. The org subdomain serves both the fleet view and the site-level views as routes. Behind the subdomain, the organisation runs inside a cell — the account control plane records which cell hosts which org and provisions the DNS. See Cell topology.

Step 3 — Join via approval

Membership is explicit and approved, and it lives at two levels. On the account plane, an org’s roster carries exactly two roles — owner and member — and joining is by invitation: an owner issues an email invite (from the console, or csy account member invite), and you join by following the accept link. Inside the org’s cell, membership is a separate surface, managed by an owner or admin through the org’s admin views. Either way, you gain access only through an explicit owner/admin action. (Automatic join requests for signers whose verified email domain is bound to the org are a roadmap convenience — see domain binding below.)

The first owner is a special case: it is created at provisioning time (account-born and delivered to the cell in the provisioning seed), so a freshly provisioned org is never left without someone who can approve others. Every subsequent role beyond owner/admin is resolved by the cell itself. Within the cell, org membership carries exactly three roles — owner, admin, member; see Roles.

flowchart TD
  ACP[Account control plane<br/>account.consystence.com] -->|provisions org + seeds first owner| ORG[Org runtime in a cell<br/>slug.consystence.com]
  IDP[Entra External ID] -->|CIAM Bearer keyed on oid| ORG
  YOU[You] -->|sign in| IDP
  YOU -. bound-domain auto-request (roadmap) .-> ORG
  APPROVER[Owner / Admin] -->|add member or approve request| ORG
  ORG -->|access granted| YOU

Email-domain binding is a convenience, not a boundary

An organisation may associate one or more email domains. Domain binding is admin-configured — an owner or admin binds a domain through the org’s admin surface — and it never grants access on its own. Its role is to route the right people to the right org: when a signer’s verified email matches a bound domain — say @acme.example for the Acme org — that org is where their join request belongs. The verification that is enforced sits on the user side: a domain match only counts when the signer’s Entra token carries a verified email (email_verified: true).

Two things to be clear about:

• It is a signup convenience, never a security boundary. Access is always granted explicitly through approved org membership. A matching domain does not, by itself, grant access.
• Every join passes through explicit owner/admin action today — an account-plane email invite issued by an owner, or a direct add / approval by an owner or admin through the cell’s admin membership surface. Automatic join for signers on a bound domain is a roadmap convenience, not yet enforced.

Caution

Do not treat a matching email domain as authorisation. The verified-domain gate is plumbing for where to send you, not what you may do. Authorisation comes from the membership record an owner or admin approves.

Get a free sandbox

Don’t have an org to join? The self-serve front door is the account console at account.consystence.com: any signed-in account can provision one free individual sandbox — a full tenant of its own at {slug}.consystence.dev.

Open in beta

The sandbox front door is open as part of the public beta. The flow below is the shipped code path; new tenants may wait on operator approval before the workspace opens.

1. Land on account.consystence.com and get started — you sign in (or sign up) through Entra External ID.
2. From the console’s tenant list, choose New sandbox tenant and pick a slug. The slug must be a DNS label: lowercase letters, digits, and hyphens, 3–40 characters (1–2-character slugs are reserved), no leading or trailing hyphen, and not on the reserved-slug denylist. If the slug is already taken on .dev, you’re asked to pick another.
3. The console provisions the tenant and hands you off through an interstitial into your new workspace at {slug}.consystence.dev, with your account seeded as the first owner. Where the operator approval gate is on — as it is during the beta — your new tenant sits in pending approval until a platform operator approves it, and the workspace opens then.

Two limits gate the front door: each account gets a single free sandbox, and repeat provisioning attempts are rate-limited per account. A sandbox-only JSON twin of the console flow exists at POST /api/provision on the account service.

How organisations get created today

Every tenant — sandbox, trial, or paid — is provisioned through the account control plane, which is the single chokepoint for tenant identity, slug uniqueness, DNS, and the first owner:

• Free individual sandbox — any signed-in account self-provisions one from the account console (above), landing at {slug}.consystence.dev.
• Free trial tenant — each org can create one free trial (simulation) tenant, ever. A trial converts in place: upgrading it to a paid tier keeps the tenant rather than re-provisioning it.
• Paid tenant, self-serve — the primary paid path is Stripe checkout from the console. The checkoutable tiers are SME, Enterprise, Integrator, and Integrator Pro; the entitlement is minted by the Stripe webhook on successful payment, and the owner’s tenant is provisioned under it.
• Paid tenant, sales-led — the request-a-tier → platform-operator grant flow remains for sales-led and complimentary arrangements, including the granted-only rungs (Enterprise Unlimited, Certified Partner).

Tenant creation itself can pass through an approval gate: where auto-approval is switched off, a newly requested tenant sits in pending approval until a platform operator approves it.

In every case the provision itself is the same machine-to-machine step: the account control plane mints the org’s immutable UUID, upserts the {slug} DNS record, and calls the hosting cell’s provisioning contract server-to-server, seeding the first owner — who can then bring in the rest of your team via Step 3.

Tip

Need programmatic access rather than a browser session? Tenant API keys (csk_ prefix) are minted separately and used with the X-Api-Key scheme. See API keys.

Where to go next

• Authentication — the full MultiAuth scheme model and how the CIAM Bearer is validated.
• Organisation & site model — accounts, orgs, sites, and how identity is keyed.
• Cell topology — what a cell is and how orgs are placed into one.
• Roles — the owner / admin / member model and what each can do.
• Installation — the local development path, distinct from this production flow.