Cloud Onboarding

This is the hosted onboarding path: how a real person signs in to the hosted Consystence service, reaches a tenant at its subdomain, and becomes a member. No organisation to join yet? Start with a free individual sandbox. Site servers, which run on your own infrastructure, are a separate path: they are arranged with our team during the beta (contact us); see On-premises deployment.

The path has three moving parts:

Sign in through Entra External ID.
Reach your tenant at its subdomain — {slug}.consystence.com for Enterprise tenants, {slug}.consystence.dev for Integrator tenants and sandboxes.
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.)

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 runs an OpenID Connect flow against Entra: the server keeps a session for the browser and hands it the Entra access token for its SignalR connection, and the cell validates that token itself, without calling back to the account control plane.

There is no local email/password store, no self-hosted registration, and no MFA prompt owned by Consystence — those are Entra’s responsibility. People sign in to the hosted service this way; programs use tenant API keys instead. See Authentication for the credential each kind of client sends.

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 tenant 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.

Step 2 — Reach your tenant’s subdomain

Each tenant lives at its own subdomain: one URL, one login, one tenant boundary. The canonical domain follows the tenant’s tier: Enterprise tenants live at {slug}.consystence.com — for example acme.consystence.com — while Integrator tenants and all sandboxes live at {slug}.consystence.dev. A slug is unique per canonical domain, so acme can exist once on .com and once on .dev. A standalone advisory AI web interface at consystence.io is planned as one address, with no per-tenant addresses: the tenant comes from the sign-in, with a default that a signed-in person can switch. It is not yet publicly available.

Sites are paths under that subdomain, never their own top-level domains. /sites/{code} is the target addressing scheme; today the tenant’s subdomain serves the fleet view and the site-level views as in-app routes, and the API addresses a site by code at /api/sites/{code}. Behind the subdomain, the tenant runs inside a cell, a hosting unit of the cloud service; the account control plane records which cell hosts which tenant and sets up its 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 tenant, membership is a separate surface, managed by a tenant owner or admin through the tenant’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 set when the tenant is provisioned, so a new tenant is never left without someone who can approve others. Within the tenant, membership carries exactly three roles — owner, admin, member; see Roles.

flowchart TD
  ACP[Account control plane<br/>account.consystence.com] -->|provisions tenant + sets first owner| ORG[Tenant 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 tenant’s admin membership surface. Automatic join for signers on a bound domain is a roadmap convenience, not yet available.

Get a free sandbox

Don’t have an org to join? An account can hold one free individual sandbox: a full tenant of its own at {slug}.consystence.dev. During the public beta, sandboxes are arranged on request: request access.

A sandbox is set up through the account console at account.consystence.com, where you sign in (or sign up) through Entra External ID. The console’s flow is New tenant, then Create a sandbox, with a chosen 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; a slug already taken on .dev cannot be used. Once the sandbox is ready, it is listed under My tenants, and your account is its first owner.

Quotas and rate limits apply: 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 tenants get created today

Every tenant — sandbox 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 — arranged on request during the beta and set up through the account console (above), landing at {slug}.consystence.dev.
Paid tenant — during the public beta, Integrator and Enterprise access is arranged with our team (contact us; see plans). Once agreed, the tier is granted to your organisation and an owner provisions the paid tenant under it from the account console.

In every case the account control plane mints the tenant’s immutable id, sets up its subdomain and places it in a hosting cell with its first owner, who can then bring in the rest of your team (Step 3).

Where to go next

Authentication — the credential each client sends and how the CIAM Bearer is validated.
Organisation & site model — accounts, orgs, tenants, sites, and how identity is keyed.
Cell topology — what a cell is and how tenants are placed into one.
Roles — the owner / admin / member model and what each can do.
On-premises deployment — site servers on your own infrastructure, arranged with our team during the beta.