Administration

The admin area is gated by role: only STUDIO_ADMIN sees the rail icon at all — most tenants have a handful of admins and everyone else never sees it. The role model is detailed in Roles & Access; this page walks through what each screen does.

The admin area at a glance

Tenants

Each tenant is a hard boundary: PostgreSQL row-level security scopes every row at the database, so no studio bug can leak one tenant's calls into another's list. Tenant management is an administrator's page — STUDIO_ADMIN is the only role that reaches platform-level resources.

• Creation is atomic with the default project. A tenant is created together with its default project in the same transaction, so a tenant can never exist without a project to scope content to (ADR-0020). Existing content created before the project layer was backfilled into this default project.
• Disabling a tenant turns its users away at login, with the reason shown — not a silent timeout, and not a per-user cleanup job.
• One admin role holds everything. The old split between a platform admin (no tenant content) and a tenant admin disappeared with the V32 role simplification: STUDIO_ADMIN manages the platform lifecycle and the content inside every project, as the reference deployment's single Admin role does. Every admin action still lands in the audit trail.

Users

Admin → Users is the tenant's directory: accounts, their state, their language, and the forced-password-change flag.

• New accounts start with must_change_password set — the studio routes the first login to the change screen before anything else, and the API refuses every route except the password change until it is done.
• There is no delete. A user id is referenced by the audit trail, by project memberships and by scenario locks, so enabled: false is the operation — the account is cut off on its next request (the live row decides, not the token). Erasing a person is a privacy request, a separate audited flow, not a directory button.
• Password reset issues a new forced-change state; the admin never sees or sets the final password.
• You cannot edit your own enabled flag — an administrator can neither lock themselves out by accident nor quietly keep themselves enabled against another admin's decision.

The three incident levers

When an account is compromised or a person leaves, an operator has three levers — and because authorization reads the live database row on every request rather than trusting the token's claims, each takes effect immediately, not up to eight hours later at token expiry:

The same immediacy applies to taking roles away and forcing a password change.

User Roles

Admin → User Roles edits the one vocabulary described in Roles & Access: the three studio roles — Admin, Project, Monitoring — as checkboxes, any combination, including all three and none. Roles are replaced as a set: what the form shows on save is exactly what the user holds afterwards.

The API's one refusal is an unknown role name — a stored typo grants nothing but would otherwise read back as a grant — and the editor surfaces stragglers (legacy persona names V32 did not recognise) in amber for removal rather than hiding them.

And the standing guardrail: you cannot edit your own roles.

Managers

Admin → Manager Management keeps the operational owners a project or campaign reports to — the name a report means when it says whose campaign this is. Managers are directory entries, not accounts: they gate nothing and log into nothing.

Audit

Two pages, one principle: the trail is written by the authorizer itself — AccessControl is the single place that holds actor, tenant, project, action, target and outcome at once, so a new endpoint is audited because it is authorized, never forgotten by a handler.

Activity Log

Every privileged action lands in the immutable trail with actor, role set, action, subject, and timestamp. What is recorded is precise on purpose:

• Every denial and every allowed mutation — never a successful read. Reads at scale would drown the trail; denials and writes are what an investigation needs.
• The event record has no payload field of any kind. An id names what changed, and there is nowhere to put a secret — a design decision, not an omission.
• "What have I done" is not a privileged question: every signed-in user can read their own trail (it is what My Page shows). Reading other people's requires the audit permission, which only STUDIO_ADMIN holds.

Login History

Sign-ins and failures per account — the page an admin opens when someone says "that wasn't me". An administrator reads the login log unbound by tenant, so an attempt against an address that belongs to nobody is visible at all instead of vanishing between tenants.

Platform

The platform's own lifecycle surface (STUDIO_ADMIN, like the rest of the area): inbound routes — which DNIS lands on which tenant — and the platform-level view of the system. This is deliberately the smallest page in the area: it manages plumbing, not content.

AI Settings

Admin → AI Settings (STUDIO_ADMIN) decides which ASR / LLM / TTS provider answers this tenant's calls — endpoint, model, and API key, configured per capability, cloud or on-premise (ADR-0048).

• Gated on the tenant, not the author: a STUDIO_PROJECT user builds flows (and may read which provider runs them); an administrator decides what runs them and who is billed.
• No response ever carries an API key — the studio only ever learns hasApiKey. The one route in the entire system that returns a decrypted key is the internal worker fetch, because something has to make the model call.
• Per-node overrides in the studio win over these defaults, and a scenario never silently changes because an admin swapped the tenant default — the scenario's own choices are pinned at publish (ADR-0026).

Project Defaults

Tenant-wide defaults for the two texts the worker uses when a scenario does not bring its own:

• Intent Classification — the intent guide the worker classifies against.
• Call Summary Prompts — the prompt that produces the post-call summary.

Each project can override both from its own RESOURCES sidebar; the admin page is the fallback of last resort, which is why it lives under defaults and not under a project.

Usage

Provider spend per day and per tenant: ASR minutes, LLM tokens, TTS characters — the page that answers "what did the bot cost this month" without a spreadsheet. Every role holds usage read, so the page is visible from the project workspace to Admin, Project and Monitoring alike.