Skip to main content
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.

​
Creating access levels

1

Open the access levels tab

Go to Settings > Applications, select an application, and open the Access Levels tab.
2

Add an access level

Click Add Access Level. Ravenna opens the new level’s form in a modal.
3

Configure the level

Provide:
  • Name: A clear name that communicates what the level grants, such as “Admin”, “Editor”, or “Viewer”.
  • Description: A plain-language explanation of what permissions this level includes.
  • License Count: The most people who can hold this level at once. Leave it blank for unlimited. See License count.
  • Owners: Users and user groups responsible for this access level. Every member of a selected group counts as an owner. Approval templates that use the Access Level Owner approver route to these owners. Leave it empty to fall back to the application’s owners.
  • Access Policy: The policy governing this level. It determines who is eligible to request it, how the request is approved, and when access expires. Pick a shared policy, or select Custom to define the policy on this level. See Custom access policies below.
  • Provisioning Method: What Ravenna changes once a request is approved. See Provisioning methods.
  • Post provisioning message: Optional rich text message sent to the requester after access to this level is granted. It replaces the application’s message for this level and supports the same tokens and mentions. Leave it blank to use the application’s message.
  • Enabled: Whether requesters are offered this level. It’s on by default. Turn it off to finish setting up the level before anyone can request it. See Enabling and disabling access levels.
4

Map to an identity provider group

For Group provisioning, select the corresponding IdP group from the dropdown. Ravenna adds the user to this group after approval and removes them on revoke or expiry. Pick the group your IdP already uses to grant this application and this level, so the membership has the effect you expect.
Changing an access level’s group mapping or provisioning method applies to new requests only. Ravenna doesn’t move people who already hold the level to the new group, and it removes them from the group recorded on their entitlement when that access ends.
Learn about access policies

​
Editing access levels

The Access Levels tab lists each level with its Owners in their own column. To change a level, click its row or use the Edit action. Ravenna opens the level’s settings in a sidebar on the right, so you can keep the table in view. Changes in the sidebar save automatically.The modal and the sidebar group the level’s settings into sections. The Policy section holds the access policy settings, and the Provisioning section holds the provisioning method, group mapping, and post provisioning message.If you’re an organization admin, a view button appears next to a selected shared Access Policy. Click it to open that policy without leaving the access level.

​
Access level detail page

Each access level also has its own full page. To open it, click the Expand to full view button in the top of the access level sidebar. Use the full page when you want more room to edit the level, especially one with a custom access policy.The page shows the level’s name and description in the header, which you can edit inline. Badges show the parent application, plus External or Archived when they apply. Below the header, the level’s settings appear in General, Policy, and Provisioning cards. Changes save automatically. Use the Access Levels breadcrumb to return to the table.The bottom of the page has one lifecycle action, depending on the level’s state:For external access levels, the name and description are read-only on this page.

​
Enabling and disabling access levels

Disable an access level to keep its configuration while hiding it from requesters. Use it when you want to set up a level, including its access policy, before you offer it.Change a level’s status from any of these places:
  • The Status column in the Access Levels table.
  • The status chip in the header of the access level detail page.
  • The Enabled switch in the level’s form.
  • The status menu next to each level in an application’s detail page and in an access policy’s access level list.
A disabled access level doesn’t appear in request forms in the web app or Slack, and the agent doesn’t offer it. Ravenna rejects new requests for it, including requests from the API and workflows. People who already have the access still see it.A form that already has a disabled level selected still shows its name, but requesters can’t pick it again. You can’t change the status of an archived level. Unarchive it first.

​
License count

Set License Count on an access level to cap how many people can hold that level at the same time. Leave it blank and the level is unlimited.
License count applies to one access level on its own. It doesn’t pool seats across an application’s access levels. Each level counts its own holders against its own limit, and someone who holds two levels counts once in each. If several levels draw on the same purchased seats, such as Member and Admin in GitHub, or separate levels you created so different teams get different approvals, Ravenna doesn’t enforce a shared total for the application.
How the count works:
  • Who counts: Each person who currently holds the level counts once. That includes people granted the level through a Ravenna request and members of the level’s mapped IdP group, so access granted outside Ravenna takes up a license too.
  • Usage: The level’s detail page shows how many licenses are in use under the field.
  • When the level is full: Ravenna declines new requests for the level. The requester is told no licenses are available, without the numbers, and a private note on the ticket mentions the level’s owners with the current usage so they can raise the limit or free a license.
  • Approved while full: If the level fills up between approval and an automatic grant, provisioning stops and the requester and owners get the same notice.
  • Existing holders: Someone who already holds the level isn’t blocked, so a renewal or a second request goes through at the limit.
  • The agent: When someone asks for a full level, the agent tells them up front that no licenses are available instead of filing the request.
Lowering the limit below current usage doesn’t remove anyone’s access. It only blocks new holders until usage drops below the limit.

​
Custom access policies

Select Custom in the Access Policy dropdown to define the policy directly on the access level. Use it when a level needs its own approvers, expiry, or eligibility and no shared policy fits.When you select Custom, the Policy section shows the policy fields inline. They start with the same defaults as a new shared policy:
  • Approval: Not required, Users or Groups, or Approval template. Approval Policy appears only when you pick two or more approvers or at least one group.
  • Expiry: No expiry, Fixed duration, or Requester selects.
  • Business Justification: Whether requesters must explain why they need access.
  • Eligible Groups and Ineligible Groups: Who can request the level.
A custom policy belongs only to its access level. It doesn’t appear in the Policies tab or in the Access Policy picker, and you can’t reuse, archive, or delete it separately. The Access Levels table and the application’s detail page show Custom for these levels.Ravenna deletes a custom policy when you delete its access level, switch the level to a shared policy, or delete the application.

​
Example access level structure

Define levels that reflect how your organization actually uses each application. Here is an example for Slack:
Structure access levels based on real usage patterns in your organization, not theoretical permission models.

​
External access levels

Some access levels come from an integration sync instead of being created in Ravenna. These levels use the External provisioning method, and they show an External badge in the Access Levels tab and in the access level list on an access policy.The connected provider owns an external level’s definition. When you click an external level, Ravenna opens it with the provider-owned fields locked:
  • Name
  • Description
  • Provisioning Method
  • IdP group mapping
Each external level has its own External access policy that the provider sync manages. In the level’s form, the Policy section shows only two fields, both locked:
  • Access Policy, set to External
  • Eligible Groups, which shows who can request the level
The provider owns the other policy settings, so Ravenna hides them. Whether a request needs approval in Ravenna before Ravenna files it with the provider is copied from the level’s policy (your default access policy, for a new level) when it first moves to External. The bulk Set Policy action isn’t available when your selection includes an external level.If your organization doesn’t use access policies, the level has no editable fields and Ravenna shows it read-only.Okta Identity Governance sync creates external access levels from your OIG catalog and syncs their eligibility from OIG request conditions.
You can’t pick External as the provisioning method for an access level you create. Ravenna assigns it only to levels an integration syncs.

​
Archiving access levels

Archive access levels you no longer want users to request. Archived levels are hidden from request forms but retain their approval history and IdP mappings for audit purposes.
1

Open the access levels tab

Go to Settings > Applications, select the application, and open the Access Levels tab.
2

Archive the level

Select the access level row and use the Archive action. To archive several at once, select multiple rows and use the Archive bulk action.
To restore an archived access level, filter the table by Archived status, select the level, and use the Unarchive action.
Archiving an access level does not revoke access already granted through it. Existing tickets, approval history, and IdP mappings are preserved. To revoke previously granted access, handle the deprovisioning separately in your identity provider.

​
Assignment strategies

Assignment strategies control how approvers are assigned to access request tickets for a given access level.
Assignment strategies are the older approach to approver routing. When your access levels use access policies, approval routing comes from the policy’s approval template instead, and the access level form shows an Access Policy selector in place of the approver and assignment strategy fields.
Automatically approves the request without human intervention. The system bot is assigned as the approver and the request is approved immediately.Use this for low-risk applications or access levels where automatic approval is acceptable, such as dev environments or self-service tools.
Assigns all specified approvers to the ticket. Any one of them can approve the request.Use this when multiple people are qualified to approve and you want the fastest possible response from the available pool.
Distributes approval requests evenly across the approver pool. Only one approver is assigned per request, rotating through the list to balance workload.Use this when you want fair distribution of approval responsibilities across a team.
Configure different assignment strategies for different access levels within the same application. For example, Member access might use “Auto” for immediate approval while Admin access uses “Round Robin” to distribute the review work.
Learn about provisioning methods and access policies
Last modified on November 9, 2026