Appearance
Roles & Permissions
Three role systems coexist in the Console, each governing a different layer of the platform:
- Internal roles — what an Exto operator can do across the platform.
- Portal roles — what a customer's users can do inside their own customer portal.
- Tenant roles — what a user can do inside a specific tenant after they have been provisioned into it.
The three systems are intentionally separate. An internal operator never holds a portal role; a customer admin never holds an internal role; tenant roles are assigned on top of either, per tenant.
In the matrices below:
- Y — full access (read + write).
- R — read-only.
- — — no access.
A user can hold more than one internal role. When that happens, permission checks union all of their roles — Console grants access if any of the roles allows it.
Internal roles
Internal roles control what an Exto operator can do across the platform. A user can hold one or more roles.
| Role | Code | Description |
|---|---|---|
| Platform Admin | platform_admin | Full access. Manages instances, plans, internal users, system pages, and platform configuration. |
| Infra Ops | infra_ops | Operates the fleet — instances, releases, migrations, environment variables, system workers, discrepancies. |
| Finance Admin | finance_admin | Finance-only — billing settings, invoices, payments, plans, meters, usage aggregates, custom plans, credits. |
| Compliance Admin | compliance_admin | Audit-focused, read-only. Sees system workers, discrepancies, audit log, email logs. No finance access. Receives discrepancy alerts. |
| Reader | reader | View-only across the platform (instances, customers, tenants, users, releases, migrations, system pages). Excludes finance. |
| Account Manager | account_manager | Manages a defined set of customers — onboarding, plan changes, billing, invitations. Restricted to their customer scope. |
| QA Admin | qa_admin | Operates against a defined set of customers and instances — typically for QA cycles or validation against non-prod environments. Restricted to both customer scope and instance scope. |
When you create an internal user with the Account Manager or QA Admin role, a scope picker appears so you can grant the customers (and, for QA Admin, the instances) they may operate on. Empty scope = no access; you must grant at least one entry. Scopes can be modified at any time on the user's detail page.
Internal permission matrix
| Capability | Platform Admin | Infra Ops | Finance Admin | Compliance Admin | Reader | Account Manager | QA Admin |
|---|---|---|---|---|---|---|---|
| Dashboard, Tenant Insights | Y | Y | Y | R | R | Y (scoped customers) | Y (scoped customers) |
| Customers (list, detail) | Y | Y | — | — | R | Y (scoped) | Y (scoped) |
| Tenants (list, detail) | Y | Y | — | — | R | Y (scoped) | Y (scoped) |
| Instances | Y | Y | — | — | R | — | Y (scoped instances) |
| Releases, Changelog, Environment | Y | Y | — | — | R | — | — |
| Migrations (list) | Y | Y | — | — | R | — | Y (scoped) |
| Migrations (start / rerun / rollback) | Y | Y | — | — | — | — | Y (scoped) |
| Internal Users (list) | Y | R | R | R | R | — | — |
| Internal User Invite / Edit | Y | — | — | — | — | — | — |
| System Workers, Discrepancies (list) | Y | Y | — | R | R | — | — |
| Discrepancies (purge / discard) | Y | Y | — | — | — | — | — |
| Audit Log, Email Logs | Y | Y | Y | R | R | — | — |
| User Attributes (definitions) | Y | — | — | — | — | — | — |
| Billing, Invoices, Payments | Y | — | Y | — | — | Y (scoped) | — |
| Plans, Meters, Usage Aggregates | Y | — | Y | — | — | — | — |
| Custom Plans, Credit Management | Y | — | Y | — | — | — | — |
| Billed-amount visibility (in $ figures) | Y | — | Y | R | R | R | — |
Each role gets a tailored sidebar — for example, Finance Admin sees a finance-only sidebar, and Compliance Admin sees an audit-focused sidebar. Reader sees the full operations sidebar minus Finance and admin-only items.
Portal roles
Portal roles control what a customer's users can do inside their own customer's portal. Every user who can sign in to the portal holds exactly one portal role; a user with the member role has no portal access at all (only their own profile).
| Role | Code | Description |
|---|---|---|
| Owner | owner | Full control. Exactly one per customer. Manages admins, transfers ownership, and is the only role that can delete the account. |
| Admin | admin | Manages users, tenants, settings, auth config, webhooks, and service accounts. Cannot promote anyone to Admin or Owner. |
| Billing | billing | Sees the dashboard, tenants, and instances; manages billing and invoices. |
| Viewer | viewer | Read-only access to dashboard, tenants, and instances. |
| Member | member | No portal access. Can only manage their own profile and MFA. Auto-assigned when a user is added to a tenant without an existing portal role. |
Portal permission matrix
| Capability | Owner | Admin | Billing | Viewer | Member |
|---|---|---|---|---|---|
| Portal Dashboard | Y | Y | Y | Y | — |
| View Tenants & Instances | Y | Y | Y | Y | — |
| View Users | Y | Y | — | — | — |
| Manage Users (invite, suspend, reactivate) | Y | Y | — | — | — |
| Manage Tenant Users (assign / remove) | Y | Y | — | — | — |
| View Billing & Invoices | Y | Y | Y | — | — |
| Manage Billing | Y | Y | Y | — | — |
| Customer Settings | Y | Y | — | — | — |
| Auth Config (SSO, IdPs) | Y | Y | — | — | — |
| Service Accounts | Y | Y | — | — | — |
| Webhooks | Y | Y | — | — | — |
| Account Settings (own profile, MFA) | Y | Y | Y | Y | Y |
| Changelog | Y | Y | Y | Y | — |
Role assignment
Who can grant which portal role:
| Actor | Can assign | Cannot assign |
|---|---|---|
| Owner | admin, billing, viewer, member | owner (use transfer) |
| Admin | billing, viewer, member | owner, admin |
- Only the Owner can promote or demote Admins.
- Admins cannot modify other Admins or the Owner.
- Ownership transfer is a dedicated action — there is always exactly one Owner per customer, and the previous Owner is automatically demoted to Admin when ownership transfers.
Owner-only actions
These actions are reserved exclusively for the Owner:
| Action | Detail |
|---|---|
| Transfer ownership | Designate another portal user as the new Owner. The current Owner is demoted to Admin. Atomic. |
| Promote to Admin | Only the Owner can set a user's portal role to Admin. |
| Demote an Admin | Only the Owner can change an Admin's role to Billing, Viewer, or Member. |
| Delete customer account | Soft-delete the customer organisation. Requires a confirmation flow. |
The system blocks removing the Owner without first transferring ownership, and blocks self-demotion if you are the only Owner.
Member behaviour
The Member role is a deliberate "tenant-only" state — the user exists to be a tenant user, not to manage anything at the customer level:
- All portal routes return HTTP 403.
- A restricted layout (no sidebar) is shown.
- After sign-in, the user is redirected straight to Account.
- Auto-assigned when a user is added to a tenant without already having a portal role.
Tenant roles
A user's portal role decides what they can do in the customer portal. Their tenant role decides what they can do inside a specific tenant. These are assigned independently — a Customer Admin might only be a Tenant User on one of the tenants, and vice versa.
| Role | Code | Description |
|---|---|---|
| Tenant Admin | tenant_admin | Admin within the tenant. Enforced by the Exto instance, not by the Console. |
| Tenant User | tenant_user | Regular user within the tenant. |
Tenant roles are passed to the instance during user provisioning. The instance — not the Console — enforces what each tenant role can do once the user is signed in to that tenant.
Portal actions
Underneath portal roles, individual pages and buttons are gated by portal actions such as view_dashboard, view_users, manage_users, view_billing, manage_billing, manage_settings. When the UI hides a button or page, the missing action is the reason.
The portal role → portal action mapping is what the permission matrix above describes.
Account Manager scope
Account Managers see only the customers in their scope. If an AM has scope {Acme, Globex}, they cannot list, open, or operate on any other customer — those rows simply do not appear. This is scope hiding, not just access denial: the AM never sees data outside their scope.
QA Admin scope
QA Admins are doubly scoped:
- The customer scope decides which customers they may operate on.
- The instance scope decides which instances they may act against.
QA Admins are typically used to run validation flows against specific non-prod customers and instances without granting broad access.
Notifications
A separate layer of subscriptions controls what notifications users receive (in-app and email). Notifications are grouped by category — Operations, Discrepancies, Billing, Infrastructure, General. Some subscriptions are marked Required for the user's role and cannot be turned off.
Users manage their own subscriptions on the Account page. Operators viewing another user's detail page see subscriptions read-only.
Focus mode
Operators with broad access can enter focus mode on a single customer. While focused, the Dashboard and other aggregate views hide cross-customer information and present only the focused customer's data. Focus mode is a viewing convenience — it does not change what the operator is permitted to do.
Source of truth
The backend is the source of truth for every check in these matrices. The Console UI uses the same mapping to hide buttons and filter the sidebar, but a request that bypasses the UI still gets a 403 from the server — there is no UI-only permission anywhere in Console.