Skip to main content
Access policies define the rules governing who can request access and under what conditions. Each policy controls eligibility, routes requests to the right approvers, and sets constraints like how long access lasts and whether a business justification is required.Policies are the middle layer of the cascade: approvals attach to a policy, and a policy attaches to one or more access levels. Decide how the policy will collect approvals (no approval, chosen users or groups, or an approval template), then attach the policy when you configure an access level. If one access level needs its own rules, define a custom policy directly on that level instead.

​
What policies provide

Eligibility control

Define which user groups can (or cannot) request access under this policy.

Approval routing

Skip approval, pick users or groups for a single inline round, or attach an approval template for multi-round workflows.

Access duration

Let requesters pick a duration, enforce a fixed one, or grant permanent access.

Business justification

Require requesters to explain why they need access.

​
Creating a policy

1

Navigate to Settings > Applications > Policies tab

2

Click New Policy

3

Configure policy details

  • Name: Descriptive name (e.g., “Standard access”, “Privileged access review”)
  • Description: When this policy should be used
  • Icon and color: Visual identifier for the policy
  • Owner: User responsible for managing this policy
4

Set eligibility

  • Eligible Groups: User groups allowed to request access under this policy. Leave empty to allow all users.
  • Ineligible Groups: User groups excluded from requesting access, even if they also belong to an eligible group.
5

Configure approvals

Under Approval, choose how requests are approved. See approver modes for the three options and when to use each.
6

Set the expiry

Choose an Expiry mode, which controls how long access granted under this policy lasts and whether requesters see a duration field at all. See access duration modes below.
7

Set the business justification requirement

Toggle Business Justification on to require requesters to explain their need.
8

Save the policy

​
Approver modes

The Approval setting on a policy decides how the request is routed for review. Pick the mode that matches how you want to configure approvers.
Users or Groups and Approval template also auto-approve when no approvers resolve. In template mode, that means leaving the template empty. In Users or Groups mode, it means no approvers remain after groups expand and roles resolve.

​
Approval template

Pick this mode when you want a reusable, multi-round workflow (for example, manager approval, then security review). The template defines each round’s policy and approvers, and one template can back many access policies. Create templates at Settings > Approvals.
Learn about approval templates

​
Users or Groups

Pick this mode when a single round of approval is enough and you do not need to maintain a separate template. You select users, user groups, or dynamic roles (such as the requester’s manager or the application owner) directly on the policy, then pick the round policy that decides when the round completes.The Approval Policy options are the same as those on template rounds, minus Threshold:
  • All must approve: every approver must approve.
  • Any can approve: the first approver to approve completes the round.
  • Majority must approve: more than half of the approvers must approve.
On a custom policy, Approval Policy appears only when there is more than one approver to reconcile: two or more approvers, or at least one group.
Threshold is intentionally not available in this mode. Threshold needs an approver count that the inline form does not collect. If you need threshold routing, use an approval template instead.
When a request comes in, groups expand to their current members and dynamic roles resolve against the requester and the target access level, exactly as they do inside a template round. The resolved set of users becomes the approvers on the single round.

​
Access duration modes

The Expiry setting on a policy decides who controls the length of the grant. It also decides whether the request form shows a duration field, so you set expiry once on the policy rather than per form.

​
Configure duration options

You set durations with a number and a unit (Minutes, Hours, Days, Weeks, or Months) rather than typing duration codes.
  • Requester selects: On the policy’s details page, the Default Duration dropdown lists the offered durations in words, such as 12 Hours or 1 Month. Pick the one to preselect on the request form. To change the list, select Edit Options at the bottom of the dropdown. The Duration options modal opens, where you can add, reorder, and remove options, then select Save. Keep at least one option. If you remove the current default, Ravenna makes the first remaining option the new default.
  • Fixed duration: Enter a number and pick a unit, for example 8 and Hours.
The create policy dialog uses the same number and unit control. A new policy starts with no duration options, and each option you add starts at 1 Day. When you switch an existing policy with no options to Requester selects, it starts with 12 Hours, 1 Week, and 1 Month.
A month is always 30 days. A 1 Month grant lasts exactly 30 days, regardless of the calendar month.
The duration measures from when the entitlement is provisioned, not from when the request is submitted or approved. A one-day grant that takes four hours to approve still lasts a full day once access is granted.

​
How the form adapts

The Duration and Business Justification fields on your access request form are policy-driven. They appear only for access levels whose policy calls for them, and when they appear they are required.
  • A requester picking an access level whose policy uses Fixed duration or No expiry never sees the Duration field.
  • A requester picking an access level whose policy leaves Business Justification off never sees that field.
  • When a field does render, the requester has to fill it in, so you do not need to mark it required on the form yourself.
This is what lets one form serve your whole catalog. Two people opening the same form, or the same person selecting two different access levels, see different fields.
When a policy uses Requester selects and has a default duration set, the form preselects it as long as it is one of the offered options.

​
Linking policies to access levels

Policies are assigned to individual access levels, not to entire applications. A single policy can be shared across multiple access levels.When a user requests an access level, the linked policy determines eligibility and approval requirements. If no policy is linked to an access level, the request is auto-approved.

​
Custom policies

When an access level needs rules that no shared policy covers, select Custom in the level’s Access Policy dropdown instead of a shared policy. The policy fields then appear directly on the access level, under a Policy section: Approval, Expiry, Business Justification, and eligibility. They start with the same defaults as a new shared policy.Use a custom policy for one-off levels, such as a single admin role with its own approvers. Use a shared policy when several levels should follow the same rules, so you change them in one place.A custom policy belongs only to its access level:
  • It does not appear in the Policies tab or in the Access Policy picker on other levels, so you can’t reuse it.
  • You can’t archive or delete it on its own. Edit it on the access level instead.
  • The Access Levels table and the application’s detail page show Custom in the policy column for that level.
  • Ravenna deletes the custom policy when you delete its access level, switch the level to a shared policy, or delete the application.
An external access level synced from an integration has its own External policy that the sync manages. You can’t link a different policy to it, and its policy settings are read-only in Ravenna.

​
How policies drive approvals

When a request is submitted, Ravenna creates the approval rounds on the ticket automatically based on the policy’s approver mode.
  • Template mode: Ravenna applies the referenced approval template, materializing its rounds as concrete approval steps. Dynamic approvers (the requester’s manager, application owner, and so on) are resolved at apply time.
  • Users or Groups mode: Ravenna creates one inline round using the policy’s approvers and approval policy. Groups expand and dynamic roles resolve the same way as in template rounds.
You do not need a workflow for this routing. If the policy uses Not required, or no approvers are configured, the request is auto-approved.

​
Managing policies

Editing a policy only affects future requests. Existing in-flight requests retain the policy rules that were in place when they were submitted.Archiving hides the policy from new assignments while preserving history and existing entitlements that reference it.Deleting permanently removes the policy. Access levels that referenced it fall back to auto-approval.These actions apply to shared policies. Custom policies are edited on their access level and removed with it. See custom policies.
Learn about approval templates and approval rounds
Last modified on October 9, 2026