Super-admin overview

Who is a super admin

Super admin is a platform-level role, not a workspace role. It's held by AI Domination support, engineering, and customer-success staff who need cross-workspace visibility to do their jobs.

You don't see super-admin actions in your day-to-day. You'll see them when:

• Support is investigating a ticket you opened.
• A customer-success agent runs an account review.
• Engineering is fixing a data issue.

What super admins CAN do

• View any workspace's data, read-only by default.
• Impersonate a specific user with explicit audit logging (see Impersonation).
• Trigger an audit re-run on your workspace.
• Pause a workspace (e.g. for billing holds or platform issues).
• Issue trial extensions or credit notes.
• Resolve internal escalations from the customer-success dashboard.

What super admins CAN'T do

• Read raw API key plaintext (we store hashes; the plaintext doesn't exist).
• Decrypt your encrypted integration credentials without an additional engineering ceremony (key holders are separate from support).
• Modify your billing without your consent (a credit note is not the same as charging you).
• Delete your workspace.
• Promote themselves or anyone else to super admin (a separate engineering process gates that).

Audit trail

Every super-admin action — every read, every impersonation start, every config change — produces an audit-log entry visible in your workspace's audit log under the actor type "Super admin." The entry includes:

• The exact action.
• The super admin's name and ticket number (when associated with a ticket).
• A justification field if the action was sensitive.

You can filter your audit log by actor.type=super_admin to see every staff touch.

Asking for super-admin help

When you open a support ticket asking for an action that requires super-admin powers, the agent will:

1. Identify themselves by name and ticket ID.
2. Tell you what they're about to do.
3. Get your written consent.
4. Perform the action.
5. Link to the audit-log entry.

If a step is skipped, push back. Our internal policy requires all five.

Read-only by default

Super admin defaults to read-only. Write actions require the agent to elevate via a separate internal flow that audit-logs the elevation. Read-only investigation is most of what they do.

Service-account access

Some automated systems (e.g. our cron runners) need data access. These are explicit service accounts with narrowly-scoped permissions, not super admins. Service-account actions log under actor.type=service.

Customer-controlled disablement

You can opt your workspace out of super-admin access at Settings → Privacy → Restrict staff access. With this on:

• Super admins cannot view your workspace without explicit per-request opt-in from a workspace owner.
• Support tickets requiring data access will require an extra round-trip to grant access.

This slows support responses but raises the privacy bar — trade-off documented in the setting's help text.

See also

• Impersonation — the most-asked-about super-admin power.
• Audit logs — how to read what super admins (and your own team) have been doing.
• Customer success dashboard — the staff-side view that powers proactive outreach.