Admin console overview

A map of the Strata admin console, who can reach it, and where to start when you take over your organization.

The admin console is the Organization page, opened from Organization in the sidebar. The sidebar shows that place only to users whose role grants the canAccessAdmin permission and at least one admin page; it opens the first page you may see (Profile, for an admin who manages the organization's settings). A user without canAccessAdmin who types /admin/users in the URL bar is redirected to the chat page. A user who has admin access but lacks a page's own permission is redirected the same way. The organization's settings sections are the exception: their addresses never redirect, and without canManageOrgSettings the page says Admin access required — except that /admin/audit opens the Audit log as a page of its own for a user who holds canViewAudit, and /admin/database-connections (or /admin/connections) opens Database connections the same way for one who holds canManageOrgConnections.

Who is an admin

Strata's permission system is role-based. Every organization is seeded with two built-in roles:

• admin — every administrative permission granted, with one deliberate exception: member-chat oversight (canViewMemberChats) is never auto-granted to the built-in admin role, since reading other people's conversations is a governance capability an org opts into by assigning a dedicated role. Cannot be edited.
• user — no administrative permissions; cannot be edited.

You can create additional custom roles that mix any subset of the granular permissions. The standard keys are:

Seven further permissions are owner-reserved. They carry organization-wide control, so an admin can only grant one if they already hold it themselves (enforced in the role editor and server-side):

A role without canAccessAdmin cannot reach /admin at all, even if other can_* keys are set. See Roles and permissions for the full model and how to author custom roles like "User manager" or "Compliance reader."

A user's effective permissions are not only their one direct role. An admin can bind roles to a group, and every member of that group inherits those permissions (group-level RBAC). The effective set is the union of the direct role and every group-bound role, still capped by org policy and any per-user deny. Binding a role — and, once a group is privileged, changing its membership — is governed by an escalation ceiling: you can only confer a permission you already hold yourself. See Binding roles to a group.

The admin pages

Every admin page draws the same navigation down its left side, with the page you are on selected: the organization's settings sections and the admin pages together, in seven groups (Organization, People, Intelligence, Connections, Usage and billing, Data and oversight and Help). Each still lives at its own URL, so you can deep-link, bookmark, and grant per-page review access. The navigation only lists the places your role has a permission for, so two admins can see different lists; an admin who holds only the Audit log or Database connections permission sees just that page. On a phone, Organization opens the whole list, and each place you open shows ‹ Organization to go back to it.

The organization's settings are twelve sections of the Organization page: Profile, Member defaults, Models, AI engine, Agents, Extensions, Connectors, Database connections, Data and privacy, Audit log, Provisioning, and Support, each in the group that says what you are changing, among the admin pages above. Several are permission-gated, so you may see fewer. Some admin areas live entirely inside those sections — org-wide SQL Server connections, bring-your-own Azure AI Foundry, organization deletion, the agent templates library, SCIM provisioning, and the audit log — and have their own articles. The bare /admin/org-settings opens Profile. The direct URLs /admin/connections and /admin/audit still work for deep-linking, as does every address a section ever had: /admin/locks opens Member defaults rather than 404ing, and /admin/setting/<column> opens whichever section owns that setting today. See Page layout.

There is no Locks section, and no register of what is pinned. A lock renders as a padlock on the row of the setting it pins, so you read a value and the decision to freeze it together, and there is no second screen to keep in step with the first. To see everything your organization has pinned at once, filter the audit log to the Organization category.

Two things are not here. Invitations are sent from the Users page's Add user flow (/admin/invites redirects there). The Atlassian connection that covers Jira and Confluence is configured on its extension's own page: Settings → Apps → (extension) → Manage → Organization settings. Which extensions your organization allows at all is set in Organization → Extensions; each extension's own page repeats that decision read-only.

Choosing AI models

Strata no longer ships a fixed list of models. It runs a centrally-curated Model Catalog — a library of chat, voice, transcription, and embedding models that Kronisys provisions and maintains on Microsoft Azure AI Foundry, spanning OpenAI, Anthropic, xAI, DeepSeek, Mistral AI, Cohere, and Microsoft. As an admin you decide which of those models your organization can use.

Open Organization → Models and choose Manage models to open the Model Catalog and enable or disable models. For each one you can review its capabilities, context window, per-1M-token pricing, and Strata's own benchmark results before turning it on. The set you enable becomes the org's allowed list; chat, agents, voice, the Teams bot, and the API all honor it.

Note

The in-app Model Catalog is the live source of truth for which models exist and what they cost. Use it rather than memorizing a list — the catalog changes as new models are added.

When Microsoft retires a model on Foundry, Strata marks it legacy 90 days ahead and notifies the admins who can manage AI models. On the date it moves your organization to the replacement, unless you turn that off. See Model retirement.

The models a single member can actually pick are the intersection of three layers: the org's enabled models, their role's allowed list, and any per-user override. To narrow one person below the org default, open Users → (manage user) → Access → AI models and uncheck models for that user; leaving it on "inherit" gives them every org-allowed model. See Roles and permissions and Users for the role and per-user layers.

How policies propagate

Most admin changes apply to every member of your organization the next time they make a request. The exceptions worth knowing:

• Role and permission changes rehydrate onto a session within about 30 seconds (the session refresh interval). Force-sign-out a user from the Sessions page if you need the change to land immediately.
• Model changes — disabling a model in the Model Catalog, or narrowing a role or per-user allowed list — take effect on the next chat, agent, voice, or API request once the session refreshes.
• Extension changes revoke access to newly-disallowed extensions on the next request — the user cannot keep using OneDrive or Outlook past their role's allowed list.
• Organization suspension is checked on the same ~30-second refresh. Once it lands, members get a 403 "Organization suspended" response on chat, scheduled agents stop running, and the voice button becomes unavailable. Admins can still reach /admin to lift the suspension.
• Bringing your own Foundry takes effect on the next AI request after Strata verifies the new endpoint and key.

Where to start as a new admin

If you have just taken over an organization, work through the console in this order:

1. Organization → Member defaults. Confirm the privacy defaults, the rate-limit plan, the required conversation mode, and the capability switches are what you want. As you go, close the padlock on the right of any row members may not override in their own settings — you do not have to come back for it later, and the row tells you what everyone will be pinned to.
2. Organization → Profile. Set the org name and logo, the invite domain restriction, the multi-factor requirement and the session timeout, and decide what members may change about their own account.
3. Organization → Models. Open the Model Catalog and enable the AI models you sanction.
4. Organization → Extensions. Choose which extensions your organization may use at all, and whether that list is a Ceiling (an extension off here is unavailable to every member) or a Menu (each role's own list decides).
5. Organization → Data and privacy. Set retention, and the egress rungs that decide what may leave through email, OneDrive, and the open web.
6. Roles. Add custom roles that match your org chart before inviting people. You can always change a user's role later, but you cannot retroactively assign a role that did not exist.
7. Database connections. If your team queries a shared SQL Server, add it once here so every analyst inherits a vetted connection.
8. Invitations. Send invites with the right role pre-assigned.
9. Organization → Audit log. Bookmark this. Every admin mutation appears in the activity table here.

For each page, follow the cross-link in the table above for the full reference.

Related

• Users
• Roles and permissions
• Groups
• Organization
• Audit log