Users & Roles

How AdaptCX authenticates and authorizes people inside your tenant. Covers user management, the built-in role model, SSO configuration, and MFA.

Sections

• Users — invite, edit, deactivate; user lifecycle
• Roles — the built-in roles and what each can do
• Permissions — the underlying permission catalog and custom roles
• SSO — connect Azure AD, Okta, Google Workspace, or any OIDC IdP
• MFA — TOTP enrollment, recovery codes, device management

Concepts

User — a person with access to your tenant. Every user has:

• Email (unique, doubles as the login identifier)
• One or more roles (see below)
• Optional partner or tenant scope for platform-level roles
• MFA enrollment state
• SSO identity linkage (if SSO is enabled)

Role — a named bundle of permissions. AdaptCX ships with a set of built-in roles covering the common patterns; custom roles can be created for organizations with unusual permission needs.

Permission — a fine-grained capability like bots.create, users.invite, integrations.edit. Permissions belong to roles; users get permissions transitively.

User type — a coarse platform-level category on the User record (super_admin, platform_ops, partner_admin, tenant_admin, agent, etc.). Some checks read user_type directly for platform-scoped decisions; per-tenant permissions are handled through the role/permission model.

Design principles

• Role-based, not per-user permissions — grant a role, not a permission. Custom roles when the default set doesn't fit.
• MFA everywhere — no way to opt out of MFA on a per-user basis. If SSO is on, MFA is delegated to your IdP.
• Least privilege — the default roles are scoped to what the role name implies. A "supervisor" can see agents; a "supervisor" cannot delete tenants.
• Audit trail — every user, role, or permission change is logged to audit_logs with actor, target, timestamp, and source IP.