Admin Workspace

The Admin workspace is the platform-wide identity and authorisation surface, served under /admin. In the product’s own words: “Manage users, group them into teams, bundle permissions as roles, and attach teams to workspaces.” It is where administrators control who can sign in, what they are allowed to do, and which workspaces they can reach — and where every such change is recorded in the audit log.

Note

The Admin workspace is a System area, not a regular workspace. It does not hold content, sources, or chats of its own; it governs access to the workspaces that do. The organisation’s data estate (sources, hosts, credentials, organisations) is managed separately in the Estate area.

Who can access it

Access to /admin is permission-gated, not role-gated. You can open the Admin workspace if either of the following is true:

• You are a super admin, or
• Any role you inherit (through your teams) grants at least one admin.* permission — for example admin.users:show or admin.audit_logs:show.

If neither applies, the Admin tile simply does not appear in your workspace picker. Within the Admin workspace, individual surfaces and buttons are gated by their own permissions (listed per section below), so two administrators may see different tabs and actions.

Super admin is a special account flag, not a role. It grants unrestricted access to every surface, bypassing all permission checks — but only a super admin can grant it, never to themselves, and every change to it is recorded in the audit log. A newly flagged super admin starts with no team memberships; the expected practice is to use the Admin surface to grant yourself (and others) ordinary permissions through teams and roles.

Opening the Admin workspace

1. Click the workspace picker — the pill in the top bar showing your current workspace name.
2. Under the System group, choose Admin (shield icon).
3. You land on the Overview page at /admin. The picker pill now reads Admin, and breadcrumbs are rooted at Workspaces › Admin.

The access model

Nobody is granted access directly. Every user’s reach is assembled from four kinds of record, linked in a chain:

User ──joins──▶ Team ──is assigned──▶ Role (a bundle of permissions)
                 │
                 └──is attached to──▶ Workspace

• A user who belongs to no team has no access at all.
• A team collects users and carries role assignments. Attaching a team to a workspace grants every member that team’s bundled permissions in that workspace. Teams exist once across the platform and can be attached to any number of workspaces.
• A role bundles permissions. Roles also exist once — editing a role immediately changes what every team using it can do.
• A permission is a scoped domain:action string (for example admin.users:invite) from a registry defined in the application code. The registry is read-only in the UI; adding a permission is a code change.

Because each link in the chain is a separate record, granting access is always some combination of: add the user to a team, assign a role to the team, and attach the team to a workspace. Removing any one link removes the corresponding reach. Every add and remove emits an audit event.

Finding your way around

Every Admin page shares a common header:

• Navigation strip — Overview, Manage, Audit Logs (only if you may view them), and About.
• Action buttons — Invite user, Add team, Add role (each shown only if you hold the matching permission).
• Metadata strip — Type (“System Workspace”) and live counts of Users, Teams, Roles, and Permissions.
• Health badge — a roll-up of the platform’s integrity checks. It shows healthy or needs attention; the latter means some records are misconfigured, such as users without a team or roles that grant nothing. Each section’s overview page highlights its own misconfiguration counts (for example No team, No role, Empty) and offers matching filters in the catalogue so you can find and fix the affected records.

The sections below follow the navigation strip and the Manage cards.

Overview

Path: /admin/overview (also the landing page at /admin)

A read-only dashboard of platform activity and growth over a selectable window (7d / 30d / 90d, default 30 days):

• Admin activity — access and security audit events per day, with a change-versus-previous-window indicator.
• Total users — cumulative user count over the window.
• Activity by type — a breakdown of event types in the window: sign-ins, sign-outs, blocked logins, role grants and removals, team joins and leaves, workspace grants and removals.
• Permissions by category — the permission registry grouped by domain.

Manage

Path: /admin/manage

A launcher listing every identity and authorisation surface, each card showing a live count and opening the working surface: Users, Teams, Roles, and Permissions. A fifth card, Organisations → Estate, links out to the Estate area, where ROPA Article 30 controller records live.

Users

Path: /admin/users · Permissions: admin.users:show to view, admin.users:invite to invite, admin.users:update to edit

Every signed-in user across every workspace. Identity is sourced from your sign-in provider (OmniAuth); team membership controls what each user can reach.

• Overview — a Membership distribution chart ranking teams by member count. Users with no team collect at the bottom as the misconfiguration tail; a user with no team has no access.
• Catalogue — a searchable, sortable table of users (name, email, teams, joined date), with filters for super-admin status and a Without team toggle. Search is by name only — email addresses are encrypted at rest and cannot be searched or sorted.
• User detail — profile, team memberships (add via Link team, or remove), inherited roles, the last five access sessions, and a timeline of the user’s audit events.
• Invite user — enter an email address and choose Send invite. This mints an identity so the person can sign in; they have no access until you add them to at least one team.
• Edit profile — full name and preferred name. Super admins additionally see the super admin switch when editing another user’s profile (see Who can access it).

Teams

Path: /admin/teams · Permissions: admin.teams:show / :create / :update / :discard

Groups of users with shared role assignments. A team’s reach is the set of workspaces it is attached to.

• Overview — a Workspace reach heatmap of teams against workspaces, showing coverage at a glance.
• Catalogue — teams with member, role, and workspace counts; filters include Without role and Without workspace (a team missing either grants nothing).
• Team detail — the team’s roles (Link role to assign, remove to revoke), members (Link member), attached workspaces (Link workspace), the permissions members inherit, and a timeline.
• Add / edit team — name, description, and the team owner.

Teams are soft-deleted: discarding a team hides it and severs its reach, but it can be restored. Re-linking a previously removed member, role, or workspace restores the original record rather than duplicating it.

Roles

Path: /admin/roles · Permissions: admin.roles:show / :create / :update / :discard

Permission bundles. Assign a role to a team to grant every member the bundled permissions in the workspaces that team reaches.

• Overview — a Permission coverage heatmap of roles against permission domains.
• Catalogue — roles with team, user, and permission counts, the domains they cover, and an Empty (no permissions) filter.
• Role detail — the granted permissions grouped by domain, the teams holding the role (Link team to assign), the users reached through those teams, and a timeline.
• Add / edit role — name, description, and a checkbox grid of every permission in the registry, grouped by domain.

Caution

Roles exist once across the platform. Editing a role’s permissions immediately changes what every team assigned that role can do, in every workspace those teams reach. Check the role’s Teams and Users reached lists before making changes.

Permissions

Path: /admin/permissions · Permission: admin.permissions:show

The application’s permission registry — the canonical action vocabulary that roles bundle from. This surface is read-only: permissions are defined in the application code, and access is only ever issued by bundling them into roles.

• Overview — an Action coverage heatmap of permission domains against the canonical actions (show, create, update, discard). A filled cell means that domain:action permission exists.
• Registry — every permission string, searchable and filterable by action.

Workspaces

Path: /admin/workspaces · Permissions: admin.workspaces:show / :create / :update / :discard

The platform-wide catalogue of workspaces — the isolated tenant environments users work in.

• Overview — a Setup coverage heatmap showing, for each workspace, whether it has a team attached, a default AI model, and a chat plan. Gaps indicate incomplete setup.
• Catalogue — workspaces with team counts, plus Without team, Without AI model, and Without chat plan filters.
• Workspace detail — description, the teams granted access (Link team to grant, remove to revoke), and a timeline.
• Add / edit workspace — name and description only. Creating a workspace starts its first-run setup; default plans, models, and content links are then configured inside the workspace itself, not from the Admin area.

Audit Logs

Path: /admin/audit_logs · Permission: admin.audit_logs:show (the tab is hidden without it)

The platform-wide, read-only audit trail — every recorded action across the platform, including sign-ins, blocked logins, and every access change made in the Admin workspace.

• Audit trail — a table of events with time, event type, category (security, access, content, database, ai, billing), action, actor (or System), subject, workspace, and IP address. The filter shelf searches event type, IP, request ID, and metadata, and filters on any column.
• Event detail — the full record for one event: actor, subject (linked where it still resolves), workspace, IP address, request and session identifiers, user agent, and the event’s raw metadata.

About

Path: /admin/about

Platform diagnostics: build and release details (version, revision, Ruby and Rails versions), environment, database, connected services, OIDC configuration, Enprivacy AI configuration, runtime policy, and active feature flags. Include these details when contacting support. Credentials are never shown — connection strings are sanitised before display.

Next steps

For step-by-step instructions — inviting a user, granting workspace access, creating teams and roles — see Common Administration Tasks.