Roles & permissions reference

Atomation Roles & Permissions

The declared role and permission contract used for Okta group mapping. Role names and SCIM mappings are active, but production end-to-end authorization validation is still in progress. Do not use this page as proof that every listed action has completed enforcement testing.

Last updated: July 9, 2026

How Atomation Roles Work

Every Atomation user has exactly one role, and the declared contract associates that role with a set of permissions. You assign a role by linking an Okta group to an Atomation role-group with SCIM Group Push or Group Linking, 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 the intended permission contract. Production enforcement validation for every listed action is still in progress.

The Six Roles

Role	Permissions	Summary
Admin	21 of 21	Full access. Always holds every permission. Built-in system role.
Org Admin	19 of 21	Customer and org management, scans, triage, and report publishing.
Security Admin	17 of 21	Viewer access plus security, logs, users, roles, and permissions management.
Developer	8 of 21	Read access plus scan runs and internal operator diagnostics. No suspend, no security config.
Viewer	7 of 21	Read-only across customers, orgs, scans, findings, reports, the audit log, and internal users.
User	0 of 21	Zero 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.

Validation status: role names and SCIM mappings are active; this matrix is not a substitute for completed end-to-end production RBAC test evidence.

Export formats are separate from permission names: the active customer portal exports assessment reports as PDF or Markdown and offers CSV on supported inventory views. It does not expose DOCX, raw JSON, or raw snapshot downloads.

Permission	Admin	Org Admin	Security Admin	Developer	Viewer	User
Customers
`customers.impersonate`Reserved impersonation permission; not claimed here as an active audited workflow	✓	—	—	—	—	—
`customers.manage`Create, edit, suspend, deactivate customers	✓	✓	—	—	—	—
`customers.view`View customers and their orgs	✓	✓	✓	✓	✓	—
Findings
`findings.triage`Triage findings: dispositions, notes	✓	✓	✓	—	—	—
`findings.view`View findings	✓	✓	✓	✓	✓	—
Logs
`logs.export`Export audit logs to CSV	✓	✓	✓	—	—	—
`logs.view`View the unified audit log	✓	✓	✓	✓	✓	—
Orgs
`orgs.manage`Edit, verify, suspend, deactivate Okta org connections	✓	✓	✓	—	—	—
`orgs.view`View Okta org connections	✓	✓	✓	✓	✓	—
Reports
`reports.publish`Publish reports to tenants	✓	✓	✓	—	—	—
`reports.view`View reports	✓	✓	✓	✓	✓	—
Roles
`permissions.manage`Register new permissions	✓	—	✓	—	—	—
`roles.manage`Create and edit roles	✓	✓	✓	—	—	—
Scans
`scans.run`Trigger ingestion scans	✓	✓	✓	✓	—	—
`scans.view`View scan/snapshot history and data	✓	✓	✓	✓	✓	—
Security
`security.manage`Change SSO, SCIM, and policy configuration	✓	✓	✓	—	—	—
`security.view`View security configuration	✓	✓	✓	—	—	—
System
`data.export`CSV export on supported inventory views	✓	✓	—	—	—	—
`system.debug`Internal operator diagnostics; not a customer raw-JSON export	✓	✓	—	✓	—	—
Users
`users.manage`Invite, edit, suspend, unlock internal users	✓	✓	✓	—	—	—
`users.view`View 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 or Group Linking.

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 SCIM provisioning 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.