System roles

Wiring in flight. System roles exist and are assignable today. The detailed capability matrix below reflects the intended v2 shape; some capabilities currently aggregate at coarser granularity (a user may have slightly broader access than the table suggests during the transition).

Every tenant ships with four roles. You can't delete them; you CAN extend them with custom roles (Create a custom role). They cover most needs without configuration.

The four

Owner

Full control over the tenant. Has every capability. Can do everything an Administrator can do, plus:

• Delete the tenant itself (subject to platform confirmation).
• Transfer ownership to another user.
• Change billing-affecting settings.

Assign sparingly. One or two Owners per tenant. Mostly the people who initially set the tenant up; if they leave, transfer ownership to whoever replaces them.

Administrator

Day-to-day administration. Everything except the destructive / billing-level operations. Capabilities:

• Applications — full CRUD; rotate secrets; enable / disable / delete.
• Users — full CRUD; reset password; force MFA reset; bulk import / export; GDPR delete.
• Authentication — configure policy; manage federation connections; tune flows + actions.
• MFA — configure enforcement; manage custom factors.
• Branding — full edit.
• Audit — read; export; configure streaming.
• Threat intelligence — manage feeds; test IPs.
• Reports — view; configure custom reports.
• Members — invite; change roles; remove.

This is the role most tenant admins land on. Default to Administrator for full-time admin staff.

Operator

Day-to-day operations without policy authority. Capabilities:

• Users — view; reset password; force MFA reset; suspend / re-enable. NOT: delete, bulk operations, change identities.
• Applications — view; rotate secrets. NOT: create, delete, edit configuration.
• Audit — read; export.
• MFA — perform recovery operations.
• Threat intelligence — test IPs.
• Reports — view (not configure).

The role for support staff, on-call engineers, customer-success operators. Can react to incidents without authority to change policy.

Viewer

Read-only. Capabilities:

• Users — view records (no edits).
• Applications — view configurations (no secret rotations).
• Audit — read.
• Reports — view.
• Authentication / MFA / Branding — view configurations (no edits).

For auditors, compliance officers, security reviewers, stakeholders who want context without click-power.

Capability matrix

A summary across the four:

Capability	Owner	Admin	Operator	Viewer
View users	yes	yes	yes	yes
Create / edit / delete users	yes	yes	partial (suspend only)	no
Reset password	yes	yes	yes	no
Force MFA reset	yes	yes	yes	no
Bulk import / export users	yes	yes	no	no
GDPR-delete user	yes	yes	no	no
View applications	yes	yes	yes	yes
Create / edit / delete applications	yes	yes	no	no
Rotate secrets	yes	yes	yes	no
Configure authentication policy	yes	yes	no	no
Manage federation connections	yes	yes	no	no
Configure MFA enforcement	yes	yes	no	no
View audit	yes	yes	yes	yes
Export audit	yes	yes	yes	no
Configure audit streaming	yes	yes	no	no
Invite new members	yes	yes	no	no
Change member roles	yes	yes	no	no
Delete the tenant	yes	no	no	no
Transfer ownership	yes	no	no	no

Choosing per-person

Quick decision guide:

• "They run this tenant" → Owner (one or two people).
• "They administer day to day" → Administrator.
• "They respond to issues but don't set policy" → Operator.
• "They watch but don't act" → Viewer.

When in doubt, start lower (Operator instead of Administrator). Promoting is one click.

What custom roles add

System roles cover most needs. Reach for custom roles when:

• A specific job needs a non-standard mix of capabilities. ("Branding editor — can only touch the Branding section.")
• You have a regulatory requirement to scope an external auditor to specific audit-log queries.
• You want a role bound to a feature your tenant uses heavily.

For most tenants, the four system roles are enough.

See also

• Roles overview
• Create a custom role
• Assign roles to users