Identity, Roles, and Access
Use this article to reason about permissions correctly and to plan an SSO rollout that can be rolled back.
Availability: Enterprise6 min readLast reviewed September 3, 2026
How Access Works
- RBAC controls permitted actions.
- Organizational scope controls which organization's data is accessible.
- SSO/SAML connects an enterprise identity provider.
- SCIM can support lifecycle provisioning where configured.
- Audit records provide evidence of sensitive administrative actions.
- Seeing a page does not prove permission to perform an action.
- UI controls do not replace backend authorization.
Recommended SSO Rollout
- Confirm the Enterprise entitlement.
- Identify an accountable administrator.
- Validate the organization's domain.
- Configure identity-provider metadata.
- Define group and role mappings.
- Test with a limited pilot group.
- Confirm rollback and break-glass access.
- Review audit evidence.
- Expand access only after validation.
Important: Nothing Is Automatic
SSO and SCIM are not enabled automatically. Both require an applicable plan, identity-provider configuration, and administrative validation before any group depends on them.
Troubleshooting
- A pilot user cannot sign in through the identity provider.
- Verify the user is in a mapped group, the domain is validated, and the identity-provider metadata matches what is configured.
- Group mapping grants more access than intended.
- Map to the least-privileged role that satisfies the job, and review audit evidence after the pilot before expanding.
- You are locked out during a rollout.
- Use the break-glass access confirmed in step 7. Confirm it before, not during, an incident.