Roles & permissions reference

Atomation Roles & Permissions

The permissions each Atomation role grants. Use it when you map Okta groups to Atomation roles with SCIM Group Push, so every group lands on the least-privilege role its team actually needs.

Last updated: June 24, 2026

How Atomation Roles Work

Every Atomation user has exactly one role, and the role is a fixed set of permissions that controls what the user can see and do across the workspace. You assign a role by linking an Okta group to an Atomation role-group with SCIM Group Push, so group membership in Okta determines the role in Atomation.

Atomation ships six roles. Two are built-in system roles – Admin and User – and the rest are standard roles you link Okta groups to. The matrix below shows exactly which permissions each one grants.

The Six Roles

RolePermissionsSummary
Admin21 of 21Full access. Always holds every permission. Built-in system role.
Org Admin19 of 21Customer and org management, scans, triage, and report publishing.
Security Admin17 of 21Viewer access plus security, logs, users, roles, and permissions management.
Developer8 of 21Read access plus scan runs and debug surfaces. No suspend, no security config.
Viewer7 of 21Read-only across customers, orgs, scans, findings, reports, the audit log, and internal users.
User0 of 21Zero permissions. Safe default for just-in-time users with no group match. Cannot be deleted.

Permission Matrix

Rows are permissions, columns are roles.✓ means the role grants the permission;— means it does not.

PermissionAdminOrg AdminSecurity AdminDeveloperViewerUser
Customers
customers.impersonateImpersonate-view a tenant portal (read-only, audit-logged)✓—————
customers.manageCreate, edit, suspend, deactivate customers✓✓————
customers.viewView customers and their orgs✓✓✓✓✓—
Findings
findings.triageTriage findings: dispositions, notes✓✓✓———
findings.viewView findings✓✓✓✓✓—
Logs
logs.exportExport audit logs to CSV✓✓✓———
logs.viewView the unified audit log✓✓✓✓✓—
Orgs
orgs.manageEdit, verify, suspend, deactivate Okta org connections✓✓✓———
orgs.viewView Okta org connections✓✓✓✓✓—
Reports
reports.publishPublish reports to tenants✓✓✓———
reports.viewView reports✓✓✓✓✓—
Roles
permissions.manageRegister new permissions✓—✓———
roles.manageCreate and edit roles✓✓✓———
Scans
scans.runTrigger ingestion scans✓✓✓✓——
scans.viewView scan/snapshot history and data✓✓✓✓✓—
Security
security.manageChange SSO, SCIM, and policy configuration✓✓✓———
security.viewView security configuration✓✓✓———
System
data.exportCSV export of customer data views✓✓————
system.debugRaw JSON toggles and debug surfaces✓✓—✓——
Users
users.manageInvite, edit, suspend, unlock internal users✓✓✓———
users.viewView internal users✓✓✓—✓—

Admin always holds every permission and User holds none, both by design. They are built-in system roles: User cannot be deleted and is the safe default for just-in-time users with no group match.

Mapping Okta Groups to Roles

Follow least privilege: link each Okta group to the lowest role-group that still lets that team do its work. Create one Okta group per role you intend to use, then link each one to its matching Atomation role-group with SCIM Group Push.

  • Grant Admin and Security Admin only to the small group that runs the workspace.
  • Use Org Admin, Developer, and Viewer for everyday access tiers.
  • Leave everyone else on User (zero permissions) until a group match grants more.
  • Review group membership in Okta on a regular cadence so role assignments stay current.

For the step-by-step Group Linking and SCIM configuration, see the Okta SSO & SCIM Setup Guide.

Support

  • Email: [email protected]
  • Include your Atomation tenant subdomain and the role or group you are mapping when reporting an issue.

Atomation LLC - Okta SSO & SCIM integration.