> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access levels

> Define the permission tiers people can request for each application, with access policies, provisioning methods, and approver routing.

Access levels define the permission tiers available within an application. Each level represents a specific set of capabilities a user can be granted, and each has its own provisioning method, approvers, and optional IdP group mapping.

## Mental model

**Access levels** are scoped to a single application. There is no shared or global access level concept across applications.

Each access level belongs to one application and carries its own provisioning method, access policy (shared, custom, or external), owners, optional IdP group mapping, and post provisioning message. See the provisioning page for what each method changes.

***

## Assignment strategy selection

Assignment strategies are configured per access level, not per application. Different levels within the same application can use different strategies.

| Strategy | Approvers assigned | Approval required from | Best for |
| - | - | - | - |
| **Auto** | System bot | None, approved immediately | Low-risk apps, dev/test environments, self-service tools |
| **All** | All configured approvers | Any one approver | Multiple qualified approvers, fastest response time needed |
| **Round Robin** | One approver (rotated) | The assigned approver | Balancing workload across a team, avoiding bottlenecks |

Common pattern: use Auto for basic access levels (such as Member) and All or Round Robin for elevated access levels (such as Admin).

***

## Constraints and gotchas

* Owners and approvers each accept any mix of users and user groups.
* Changing an access level's group mapping or provisioning method has no effect on existing entitlements. Revocation uses the group or application recorded on each entitlement.
* Access levels with `provisioningMethod: external` are written by an integration sync and can't be created with that method. Their name, description, provisioning method, and group mapping are provider-owned. An update to an external level sends only `accessPolicyId`. When access policies aren't enabled for the organization, the access level modal for an external level is read-only.
* Archiving an access level hides it from new requests but doesn't revoke existing grants.


## Related topics

- [Available tools](https://docs.ravenna.ai/documentation/automate/mcp/tools.md)
- [Get an access level](https://docs.ravenna.ai/api/access-level/get-an-access-level.md)
- [List access levels](https://docs.ravenna.ai/api/access-level/list-access-levels.md)
- [Delete an access level](https://docs.ravenna.ai/api/access-level/delete-an-access-level.md)
- [Access policies](https://docs.ravenna.ai/documentation/automate/access-management/policies.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.