> ## 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. # Setting up access management > Step-by-step guide to configure applications, approval templates, access policies, access levels, and agent-assisted access requests. "Can I get access to X" is the single most common IT request and the one most often handled by a DM to whoever answers first. Set up access management and that becomes a flow where users request through a form or your AI agent, each request routes to the right approvers, and once it's approved, Ravenna makes the change in your identity provider or hands it to the person who provisions it. This guide walks through the complete setup from application catalog to agent-assisted requests. Learn about [access management concepts](https://docs.ravenna.ai/documentation/automate/access-management/overview) ## What good looks like ## How the pieces connect Access management is built from four layers that cascade into each other. You configure them from the bottom up: | Layer | What it defines | Attaches to | | - | - | - | | **Approval template** | Who approves, in how many rounds, and whether any or all approvers must sign off | An access policy | | **Access policy** | Who is eligible to request, which approval template applies, allowed durations, whether business justification is required | One or more access levels | | **Access level** | A permission tier within an application, and how access is provisioned once approved | An application | | **Application** | The tool or service being requested | Your catalog | The result is a single access request form that adapts to each requester. Users pick an application and an access level, the form shows only what they are eligible for, the access policy routes the request to the approvers defined in its approval template, and provisioning runs through the access level's provisioning method. > [!NOTE] > > You do not need to build a workflow for this. Approval routing and provisioning both happen automatically from the policy and access level configuration. Workflows are for the exceptions, covered in [optional workflow automation](#optional-workflow-automation) below. Provisioning in Ravenna changes access in your identity provider: a group membership, or an Okta app assignment. It doesn't create accounts inside applications. Before you map an access level to a group, check how your IdP turns that group into an account in the app, through automated provisioning (SCIM or an API connector), the app's just-in-time sign-up, or a person. See [group membership is not an application account](https://docs.ravenna.ai/documentation/automate/access-management/provisioning.md#group-membership-is-not-an-application-account). ## Before you begin Before starting, make sure you have: * A request channel already running, which the [IT help desk](https://docs.ravenna.ai/guides/playbooks/it/help-desk.md) playbook covers * An identity provider integration (Okta, Microsoft Entra ID, Google Workspace, JumpCloud, Cloudflare, or OneLogin) for automated group or assignment changes * For each application you automate, the IdP group or assignment that grants it, and how the app gets its accounts (IdP provisioning, JIT, or by hand) * An understanding of your organization's application catalog and which apps require access management * A clear picture of who should approve access, so you can turn that into approval templates * (Optional) An AI agent deployed to a Slack channel for conversational requests ## Step 1: Import or create applications Applications are the foundation of access management. You can sync them from your identity provider or create them manually. **1. Sync applications from your identity provider** Navigate to **Settings** > **Integrations**, connect Okta, Microsoft Entra ID, JumpCloud, OneLogin, or Cloudflare, and enable application syncing. Applications and their groups import automatically. Google Workspace is the exception: it syncs users and groups but not applications. Create those applications manually in the next step. **2. Create applications manually** Navigate to **Settings** > **Applications**, click **Add Application**, and fill in the name, domain, owner, approver, and workspaces. Save the application when complete. > [!TIP] > > Catalog the applications people ask for, not your whole estate. Pull a month of requests, count them, and start with the top ten. Record an owner on each one, because that is the field that stops every approval question becoming an IT question later. Learn about [applications](https://docs.ravenna.ai/documentation/automate/access-management/applications.md) ## Step 2: Create approval templates Approval templates define who approves an access request and in what order. Create them first, because access policies reference them. **1. Navigate to approval templates** Go to **Settings** > **Approvals**. **2. Click New Template** Click **New Template** to open the template form. **3. Configure template details** Fill in the following fields: * **Name**: A descriptive label such as "Manager approval" or "Security access review" * **Description**: When this template should be used * **Workspaces**: Which workspaces can use this template. Leave empty to make it available everywhere. **4. Add approval rounds** Add one round per approval stage. For each round, set: * **Policy**: **Any can approve** or **All must approve** * **Approvers**: Specific users, user groups, or dynamic roles such as the requester's manager **5. Save the template** Save the template. It is now available to attach to an access policy. Create one template per approval path you need. A typical setup looks like this: | Template | Rounds | Use for | | - | - | - | | Manager approval | Manager review (any can approve) | Standard, low-risk access | | Team lead and IT | Manager review, then IT sign-off | Access managed by a specific team | | Security access review | Manager review, security review (all must approve), IT sign-off | Admin and privileged access | > [!TIP] > > Use the **Requester's manager** dynamic approver rather than naming individuals. It resolves at request time, so the template keeps working as your org chart changes. Name individuals only in the rounds where the answer depends on a specific person's judgment, usually the security review. Learn about [approval templates](https://docs.ravenna.ai/documentation/tickets/approvals/templates.md) ## Step 3: Create access policies Access policies define who can request access and under what conditions. Each policy sets how requests are approved: not at all, by users or groups you pick, or through an approval template. **1. Navigate to the Policies tab** Go to **Settings** > **Applications** and open the **Policies** tab. **2. Click New Policy** Click **New Policy** to create a new policy. **3. Configure policy details** Fill in the following fields: * **Name**: A descriptive label such as "Standard access" or "Privileged access review" * **Description**: When this policy should be used * **Eligible groups**: Which user groups can request access under this policy. Leave empty to allow all users. * **Ineligible groups**: Which user groups are explicitly excluded * **Approval**: Select **Approval template** and pick the template you created in Step 2. Select **Users or Groups** for a single round of named approvers, or **Not required** only if requests under this policy should be approved automatically. * **Expiry**: How long access granted under this policy lasts. See the table below. * **Business Justification**: Toggle on if requesters must explain why they need access **4. Save the policy** Save the policy. You attach it to access levels in the next step. ### Tiering by risk Write your tiers down before you build the policies, because the tiers are what the rest of the configuration hangs off. Three cover most catalogs: | Tier | Examples | Approval | Duration | | - | - | - | - | | **Standard** | A design tool, a note-taking app, read access to a dashboard | Manager, any can approve | No expiry | | **Elevated** | A CRM seat, a billing tool, a repo with customer data | Manager, then the application owner | Requester selects, offer 30 and 90 days | | **Privileged** | Production consoles, admin roles, anything with a break-glass story | Manager, security review with all must approve, then IT | Fixed and short, 8 hours is a reasonable default | One policy per tier, reused across every application, is far easier to maintain than a policy per app. It works for ten apps and collapses at fifty. ### Choosing an access duration | Mode | What happens | Also configure | | - | - | - | | **No expiry** | Access is permanent, with no duration field on the form | Nothing | | **Fixed duration** | Access always lasts a set amount of time, with no duration field on the form | **Duration**: the enforced length, entered as a number and a unit, such as `8` **Hours** | | **Requester selects** | The requester chooses from a list of allowed durations on the request form | **Duration Options**: the durations to offer, each set as a number and a unit. Requesters pick from these on the form. On the policy page, select **Edit Options** in the **Default Duration** dropdown to add, reorder, or remove them. | Durations display in words, such as **12 Hours** or **1 Month**. A month is always 30 days. See [configure duration options](https://docs.ravenna.ai/documentation/automate/access-management/policies.md#configure-duration-options) for details. Make expiry the default rather than the exception. Permanent access is the reason access reviews are painful, and Ravenna revokes on expiry, so an unused seat leaves on its own and shows up as a reclaimed license rather than an audit finding. > [!NOTE] > > A policy with **Approval** set to **Not required**, or with no approval template, auto-approves every request that passes its eligibility check. Choose **Users or Groups** or attach a template on any policy that needs a human decision. Learn about [access policies](https://docs.ravenna.ai/documentation/automate/access-management/policies.md) ## Step 4: Define access levels Access levels represent the permission tiers within each application, such as Admin, Editor, or Viewer. Each level attaches an access policy and specifies how access is provisioned. **1. Open an application** Navigate to **Settings** > **Applications** and open the application you want to configure. **2. Go to the Access Levels tab** Select the **Access Levels** tab on the application detail page. **3. Click Add Access Level** Click **Add Access Level** to begin configuring a new tier. **4. Name and describe the level** Set the **Name** to a descriptive label such as "Admin", "Editor", or "Viewer", and use **Description** to explain what this level grants and when it should be requested. **5. Attach an access policy** Select the **Access Policy** that should govern this level. This is what determines eligibility and pulls in the approval template you configured in Step 2. If a single level needs its own rules, select **Custom** and set **Approval**, **Expiry**, **Business Justification**, and eligibility directly on the level. A custom policy can't be reused by other levels. See [custom access policies](https://docs.ravenna.ai/documentation/automate/access-management/access-levels.md#custom-access-policies). **6. Choose the provisioning method** Set **Provisioning Method** to control how access is granted after approval. See the table below for which to pick. **7. Map to your identity provider group** For Group provisioning, select the corresponding group in your identity provider. This is how Ravenna knows which group to add the user to after approval, and remove them from on revoke or expiry. **8. Repeat for each permission tier** Add an access level for every permission tier your application supports. Levels with different approval requirements should point at different access policies. ### Choosing a provisioning method | Method | What Ravenna changes | When to use it | | - | - | - | | **Group** | Adds the user to the mapped identity provider group, and removes them on revoke or expiry | Applications your IdP already grants through group membership. Supported on Okta, Microsoft Entra ID, Google Workspace, JumpCloud, Cloudflare, and OneLogin. | | **Application** | Assigns the user directly to the application in Okta, and unassigns them on revoke or expiry | Okta applications where direct assignment is preferred over groups. Okta is the only provider that supports it. | | **Manual** | Nothing outside Ravenna. An authorized provisioner grants access in the target system, then confirms it in Ravenna. | Tools with no identity provider connection, or with no automated account creation | | **Workflow** | Nothing yet | Don't use it. It's selectable but doesn't provision, create an entitlement, or revoke. Use Manual instead. | Group and Application automate the change in your identity provider. The account in the application still comes from the IdP's provisioning for that app or the app's JIT sign-up, so check that before you rely on either method for a new hire's first day. > [!WARNING] > > On OneLogin, Group provisioning maps to either a group or a role, and a user can belong to only one OneLogin group at a time. A second group-mapped grant fails rather than displacing the first, so if a user might hold two grants at once, map those access levels to OneLogin roles, which are additive. See [OneLogin access management](https://docs.ravenna.ai/integrations/onelogin/overview#access-management). Learn about [access levels](https://docs.ravenna.ai/documentation/automate/access-management/access-levels.md) and [provisioning](https://docs.ravenna.ai/documentation/automate/access-management/provisioning.md) ## Step 5: Configure the request form The form is how users submit access requests, and it is also what your AI agent presents. Create one form for access requests and let the field configuration adapt it per requester. **1. Create or open a form** Go to **Forms** and create a new form (or edit an existing one). **2. Add an Application Select field** Add an **Application Select** field. This lets users choose from the applications in your catalog. **3. Add an Access Level Select field** Add an **Access Level Select** field. This field dynamically shows the access levels available for the selected application, filtered by the requester's eligibility. **4. Add a Business Justification field** Add a **Business Justification** text area field. It renders only for access levels whose policy requires a justification, and it is required whenever it renders. **5. Add a Duration field** Add a **Duration** field. It renders only for access levels whose policy uses **Requester selects**, and it is required whenever it renders. Levels on a fixed duration or no expiry hide it automatically. **6. Save and publish the form** Save your form and publish it so it is available to users. > [!NOTE] > > The Access Level Select field is dependent on the Application Select field. It only shows access levels for the selected application, filtered by the requester's eligibility based on the attached access policy. > [!TIP] > > Add both the Business Justification and Duration fields even if only some policies need them. The access policy decides whether each one appears, so you do not need a separate form per policy. One form covers your whole catalog. Because eligibility filtering and policy-driven fields both resolve per requester, two people opening the same form see different applications, different access levels, and different fields. ## Step 6: Enable agent-assisted requests Once your form is published, you can enable your AI agent to handle access requests conversationally through Slack. The agent fills out and submits the form you built in Step 5, so it inherits the same eligibility filtering, approval routing, and provisioning. It has no separate path of its own. **1. Open your agent** Navigate to **Agents** in the sidebar and select the agent you want to configure. **2. Go to the Identity tab** Select the **Identity** tab on the agent configuration page. **3. Enable Software Access Requests** Scroll to the **Advanced Settings** card and toggle **Software Access Requests** on. This exposes eligibility-aware tools to the agent. **4. Create agent rules for access request scenarios** Add a rule so the agent presents the form and prefills what the requester already described. When someone asks for access to a tool, present the Software Access Request form. Prefill the application and access level from what they said. Do not tell them who the approvers are, the request routing handles that. When someone asks for access to a tool, present the Software Access Request form. Prefill the application and access level from what they said. Do not tell them who the approvers are, the request routing handles that. **5. Deploy the agent to your Slack channel** Deploy the agent to your Slack channel so users can submit access requests conversationally. > [!WARNING] > > The agent needs a published access request form to work with. It does not have a built-in form of its own, so complete Step 5 before enabling this. > [!NOTE] > > Requests submitted through the Ravenna API or an MCP client are different. They do not need a form you built, because Ravenna creates and reuses a **Software Access Request** form in the target workspace. It appears in **Forms** with a **System** badge and is marked **Managed by Ravenna**, so it cannot be edited. Leave it in place. Learn about [software access requests for agents](https://docs.ravenna.ai/documentation/automate/access-management/agent.md) ## Step 7: Test the flow Validate the complete setup before rolling it out to your organization. **1. Submit a test request** Submit a test access request via the form or through the agent. **2. Verify approval routing** Confirm that the access policy's approval template was applied to the ticket and that the expected approvers were notified. **3. Approve and verify provisioning** Approve the request and confirm that provisioning occurs. For Group and Application levels, check the identity provider to verify the user was added to the correct group or assigned to the app. Then sign in to the application as the test user to confirm the account exists and has the expected role. That last check is the one that tells you whether your IdP's provisioning or the app's JIT is doing its part. **4. Confirm the entitlement is created** Verify that the entitlement appears in the **Entitlements** tab on the relevant application. **5. Test manual provisioning** For access levels using Manual provisioning, test the flow by marking the entitlement as provisioned after granting access in the target system. > [!TIP] > > Test with a real requester from an eligible group, not just an admin account. Eligibility filtering is the part most likely to surprise you. ## After you launch Watch three things through the first two weeks: * **Provisioning failures.** Check the Entitlements tab on your busiest applications. A failure here is silent from the requester's side. * **Requests that skip the form.** If people still DM for access, the agent rule is not firing or the catalog is missing the app they want. * **Approvals sitting.** An approval nobody actions is worse than no approval. Add a reminder before you add more rounds. Learn about [entitlements](https://docs.ravenna.ai/documentation/automate/access-management/entitlements.md) ## Optional workflow automation Your access management setup is complete without any workflows. Add one only when you need behavior the policy and access level configuration cannot express: * **Steps around a Manual grant**: use the **Entitlement Status Changed** trigger on **Processing** to notify the team that provisions the access or open a task for them. The provisioner still marks the entitlement provisioned. The **Workflow** provisioning method doesn't run a workflow, so don't use it for this. * **Post-provisioning follow-up**: use the **Entitlement Status Changed** trigger to send a confirmation message, alert on provisioning failures, or notify a team when access is revoked. Learn about [workflow triggers and actions](https://docs.ravenna.ai/documentation/automate/workflows/triggers-actions.md) ## Where teams get this wrong > [accordion] A policy per application > > It works for ten apps and collapses at fifty. Tier the risk instead. > [accordion] Approvals on everything > > If a manager approves a note-taking app, they stop reading the ones that matter. > [accordion] Cataloging the estate instead of the requests > > Nobody requests the app that was already provisioned at hire. > [accordion] Skipping the test with a real requester > > Eligibility filtering behaves differently for an admin. Test as someone in an eligible group. ## Next steps > [card] [Access reviews](https://docs.ravenna.ai/guides/playbooks/security/access-reviews.md) > > Prove who has what, on a schedule. > [card] [Monitor entitlements](https://docs.ravenna.ai/documentation/automate/access-management/entitlements.md) > > Track active access grants and handle provisioning failures. > [card] [Refine policies](https://docs.ravenna.ai/documentation/automate/access-management/policies.md) > > Adjust eligibility and duration options based on usage patterns. > [card] [Add more applications](https://docs.ravenna.ai/documentation/automate/access-management/applications.md) > > Expand your catalog as teams request additional tools. Put this to work in the [employee lifecycle](https://docs.ravenna.ai/guides/playbooks/hr/employee-lifecycle.md), [employee onboarding](https://docs.ravenna.ai/guides/playbooks/hr/employee-onboarding.md), and [employee offboarding](https://docs.ravenna.ai/guides/playbooks/hr/employee-offboarding.md) playbooks ## Related topics - [Access management](https://docs.ravenna.ai/documentation/automate/access-management/overview.md) - [Access reviews](https://docs.ravenna.ai/guides/playbooks/security/access-reviews.md) - [Organization settings](https://docs.ravenna.ai/documentation/platform/organizations/settings.md) - [Software access requests for agents](https://docs.ravenna.ai/documentation/automate/access-management/agent.md) - [Applications](https://docs.ravenna.ai/documentation/automate/access-management/applications.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.