Applications

Build and manage your application catalog with access levels, provisioning methods, and identity provider integrations.

Applications represent the external tools and services your organization uses. By defining applications in Ravenna with their corresponding access levels and provisioning methods, you create a structured catalog that supports automated access requests.

Setting up applications

1. Navigate to applications

   Go to Settings > Applications in the left sidebar.

2. Add application

   Click Add Application to create a new application entry.

3. Fill basic information

   Provide the application details:

   • Name: Display name for the application.
   • Domain: The application’s web domain (optional).
   • Details: Rich text notes about the application (optional). These notes appear in hover cards when users view the application in ticket custom fields.
   • Owners: Users and user groups responsible for managing this application. Every member of a selected group acts as an owner for routing and fallback purposes.
   • Approvers: Users and user groups responsible for approving access requests. Every member of a selected group is treated as an approver. If no approver is set, the application owners are used as a fallback.
   • Post provisioning message: Optional rich text message sent to the requester after access is granted. Use it to share login instructions, onboarding resources, or follow-up steps. Click + in the editor to insert tokens such as the requester’s name. An access level can override it with its own message.
   • Workspaces: Select which workspaces can surface this application in request forms.
4. Configure access levels

   Add access levels to define the permission tiers available for this application. See Access levels below.

5. Save

   Click Save to create the application.

An application is requestable once it has at least one access level and is attached to a workspace. See Application status.

Post provisioning message tokens

Tokens personalize the post provisioning message for each request. Click + in the message editor and pick a field from the request’s ticket. Ravenna replaces it with that ticket’s value when it posts the message.

The menu lists the fields of the ticket, including:

Field	Replaced with
Ticket > Requester > First Name	The requester’s first name.
Ticket > Requester > Email	The requester’s email address.
Ticket > Access Level > Title	The name of the access level that was requested.
Ticket > Display ID	The ticket’s Display ID, such as IT-42.
Ticket > Link	The URL of the ticket in Ravenna.

A field with no value on the ticket is replaced with nothing.

---

Synced applications

Applications can be automatically imported from your identity provider rather than created by hand.

When you connect Okta, Microsoft Entra ID, JumpCloud, OneLogin, or Cloudflare, Ravenna discovers the applications in your IdP and adds them to your catalog. Each synced application shows the integration name as its Source.

Google Workspace does not import applications. Add your Google-federated applications manually, then use Group provisioning to grant access through a Google Group. Users and groups sync normally.

What syncing means in practice:

• The application name and image stay in sync with the IdP. You cannot edit them directly in Ravenna.
• You cannot delete a synced application while the integration is active.
• You can set a Display Name to override the IdP name shown to users. The original name is preserved for sync purposes and appears alongside the display name in the format Display Name (Original Name).
• A synced application arrives with no access levels and shows Needs Setup until you add them. The exception is external access levels, which an integration such as Okta Identity Governance syncs for you.

Use display names to make application names more recognizable to your users without affecting how the IdP integration works.

Learn about the Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, and Cloudflare Access integrations

---

Application status

Each application shows a status badge in the Status column of the applications table and in the header of its detail page. The status tells you how far along the application’s setup is and whether members can request it yet.

Status	Means	To move it forward
Needs Setup	The application has no access levels, so there is nothing to request.	Add at least one access level.
Configured	The application has access levels but isn’t attached to a workspace, so no requester can see it.	Select a workspace under Workspaces.
Available	The application has access levels and is attached to at least one workspace. Members of those workspaces can request it.	Nothing. It’s ready.
Archived	The application is archived, or your identity provider reports it as inactive or deleted.	Unarchive it, or reactivate it in your identity provider.

Hover a badge to see what it needs next. In the applications list beside an application’s detail page, the same status shows as a colored dot.

Only live access levels count. If you archive an application’s last access level, it goes back to Needs Setup.

Filter or group the applications table by Status to find the applications that still need work.

---

Provisioning methods

The provisioning method on an application (or access level) controls how access is granted after a request is approved.

Group

Provision access by adding the user to a group in your identity provider. After approval, Ravenna adds the user to the mapped IdP group, which then grants access to the application through the IdP’s own assignment rules.

Supported by: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, Cloudflare, OneLogin

Use this when your IdP manages application access through group membership.

For Cloudflare, the mapped group is a Cloudflare Access group and membership is expressed as an email include rule. See how Access group membership works.

For OneLogin, the mapped entity can be a group or a role. A user can belong to only one OneLogin group at a time, so map to roles when a user needs to hold several grants at once. See OneLogin access provisioning.

Application

Provision access by assigning the user directly to the application in the IdP. Rather than adding the user to a group, Ravenna adds them to the application itself using the identity provider’s application assignment API.

Supported by: Okta only

Use this when direct application assignment is preferred over group-based access in your IdP.

Manual

No automated provisioning. After approval, an authorized provisioner must manually grant access in the target system and then mark the entitlement as provisioned in Ravenna.

Authorized provisioners for a manual access level include the application owner, the ticket assignee, and workspace admins.

No IdP required. Use this for applications that are not connected to an identity provider, or where automated provisioning is not possible.

Workflow

Provisioning is handled by a workflow action. After approval, a configured workflow runs and performs whatever provisioning steps you define, including calling external APIs, sending notifications, or chaining multiple actions.

No IdP required. Use this for custom provisioning logic that goes beyond standard IdP operations.

---

Access levels

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.
   • 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: How access is granted once approved. See Provisioning methods above.
   • 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. Leave it blank to use the application’s message.
4. Map to an identity provider group

   For Group provisioning, select the corresponding IdP group from the dropdown. Ravenna uses this mapping to add the user to the group after approval.

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:

Level state	Action
No access requests reference it	Delete. Removes the level permanently after confirmation.
Access requests reference it	Archive. Hides the level from new requests while keeping its history.
Archived	Unarchive. Makes the level available for new requests again.

For external access levels, the name and description are read-only on this page.

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:

Access level	Description
Admin	Full admin capabilities including workspace settings
User Admin	User administration without workspace configuration access
Channel Manager	Create, edit, delete, and manage channels
Member	Standard user without admin capabilities

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.

Auto

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.

All

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.

Round Robin

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.

---

Identity provider integration

Map access levels to groups in your identity provider for automated provisioning. After an access request is approved, Ravenna can automatically add the user to the mapped group or application.

Not all providers support the same provisioning methods:

Capability	Okta	Microsoft Entra ID	Google Workspace	JumpCloud	Cloudflare	OneLogin
Application sync/import	Yes	Yes (enterprise apps)	No	Yes	Yes (Zero Trust apps)	Yes
User and group sync	Yes	Yes	Yes	Yes	Yes	Yes (groups and roles)
Group provisioning (add user to group)	Yes	Yes	Yes	Yes	Yes	Yes (groups and roles)
Application provisioning (assign user to app)	Yes	No	No	No	No	No
Supported provisioning methods	Group, Application, Workflow, Manual	Group, Workflow, Manual	Group, Workflow, Manual	Group, Workflow, Manual	Group, Workflow, Manual	Group, Workflow, Manual

Okta

Connect your Okta integration and map access levels to Okta groups or applications. Okta is the only provider that supports both group-based and direct application assignment provisioning.

1. Connect the Okta integration

   Go to Settings > Integrations and configure your Okta connection.

2. Map access levels

   When creating an access level, select the corresponding Okta group from the dropdown.

3. Set the provisioning method

   Choose how the access level provisions once a request is approved:

   • Group: Ravenna adds the user to the mapped Okta group, which then grants application access through Okta’s assignment rules.
   • Application: Ravenna assigns the user directly to the Okta application without group membership.

   Provisioning runs automatically after approval. No workflow is required.

Learn more about the Okta integration

Google Workspace

Connect your Google Workspace integration and map access levels to Google Groups. Google Workspace supports group-based provisioning only. Direct application assignment is not available through this integration.

Applications do not import from Google Workspace, so create them manually first. Google Groups do sync, and those are what the access level maps to.

1. Connect the Google Workspace integration

   Go to Settings > Integrations and configure your Google Workspace connection. Users and groups begin syncing.

2. Add the application manually

   Go to Settings > Applications and click Add Application. Name it after the app your Google Group grants access to, such as Slack or Zoom.

3. Map access levels

   When creating an access level, select the corresponding Google Group from the dropdown. Every synced Google Group is available, since Ravenna cannot tell which groups Google associates with which app.

4. Set the provisioning method

   Choose Group. After approval, Ravenna adds the user to the mapped Google Group, which grants access to connected Workspace apps and shared resources. No workflow is required.

Learn more about the Google Workspace integration

Microsoft Entra ID

Connect your Microsoft Entra ID integration and map access levels to Entra groups. Entra supports group-based provisioning only. Direct application assignment is not available through this integration.

1. Connect the Entra ID integration

   Go to Settings > Integrations and configure your Microsoft Entra ID connection.

2. Map access levels

   When creating an access level, select the corresponding Entra group from the dropdown.

3. Set the provisioning method

   Choose Group. After approval, Ravenna adds the user to the mapped Entra group. No workflow is required.

Learn more about the Microsoft Entra ID integration

JumpCloud

Connect your JumpCloud integration and map access levels to JumpCloud user groups. JumpCloud supports group-based provisioning only. Applications import from JumpCloud, so you do not need to add them by hand.

1. Connect the JumpCloud integration

   Go to Settings > Integrations and configure your JumpCloud connection. Users, groups, and applications begin syncing.

2. Map access levels

   When creating an access level, select the corresponding JumpCloud user group from the dropdown.

3. Set the provisioning method

   Choose Group. After approval, Ravenna adds the user to the mapped JumpCloud group, which grants application access through JumpCloud’s own assignment rules. No workflow is required.

Learn more about the JumpCloud integration

Cloudflare

Connect your Cloudflare integration and map access levels to Cloudflare Access groups. Cloudflare supports group-based provisioning only. Zero Trust applications import automatically.

1. Connect the Cloudflare integration

   Go to Settings > Integrations and configure your Cloudflare connection. Applications, users, and Access groups begin syncing.

2. Map access levels

   When creating an access level, select the corresponding Cloudflare Access group from the dropdown.

3. Set the provisioning method

   Choose Group. After approval, Ravenna adds an email include rule for the user on the mapped Access group, and Cloudflare’s policies grant access on the user’s next login. No workflow is required.

Ravenna manages Cloudflare Access group membership through email include rules only. A group that grants access through an email domain, an everyone rule, or an identity provider rule reports no members in Ravenna, and provisioning into it still appends an email rule for the requester.

Learn more about the Cloudflare Access integration

OneLogin

Connect your OneLogin integration and map access levels to OneLogin groups or roles. Direct application assignment is not available through this integration, so of the automated methods only Group applies. Applications import from OneLogin, so you do not need to add them by hand.

1. Connect the OneLogin integration

   Go to Settings > Integrations and configure your OneLogin connection. Users, groups, roles, and applications begin syncing.

2. Map access levels

   When creating an access level, select the corresponding OneLogin entity from the dropdown. Groups appear under their own name and roles appear with a Role: prefix, so pick deliberately: the two provision differently.

3. Set the provisioning method

   Choose Group. It covers both OneLogin groups and roles. After approval, Ravenna adds the user to the mapped group or assigns them the mapped role. No workflow is required.

A OneLogin user can belong to only one group at a time. If a user already has a different group, a second group-mapped grant fails with USER_BELONGS_TO_DIFFERENT_PRIMARY_GROUP and changes nothing in OneLogin, rather than displacing the group they already have. If the group is the one they already hold, the entitlement is marked Skipped Provisioning instead. Map access levels to OneLogin roles when a user needs to hold several grants at once, because roles are additive.

Learn more about the OneLogin integration

---

Archiving applications

Archive applications you no longer want users to request access to. Archived applications are hidden from request forms by default, but their access levels and approval history remain intact for audit purposes.

1. Open the application

   Go to Settings > Applications and select the application you want to archive.

2. Archive

   Use the Archive action in the application’s details. A confirmation appears before the application is archived.

To archive multiple applications at once, select them from the applications table and use the Archive bulk action.

To restore an archived application, filter the table by Archived status, select the application, and use the Unarchive action.

While an application is archived, Ravenna blocks changes to its access levels and rejects new access requests tied to it. Unarchive the application before resuming access request activity.

Archiving does not revoke any access already provisioned through the application. To revoke previously granted access, handle the deprovisioning separately in your identity provider.

---

Deleting applications

Delete an application to permanently remove it from your catalog.

Deletion is permanent and cannot be undone. If you need to preserve approval history, ticket references, or audit trails, archive the application instead.

1. Open the application

   Go to Settings > Applications and select the application you want to delete.

2. Delete

   Use the Delete action in the application’s details. A confirmation dialog appears before the application is permanently removed.

Deleting an application does not revoke any access already provisioned through it. Handle any deprovisioning separately in your identity provider.

---

Exporting to CSV

Export your application catalog to CSV for audits, reporting, or offline review. The export reflects any search, sort, or filter you have applied in the applications table.

1. Open applications

   Go to Settings > Applications.

2. Apply filters (optional)

   Apply any filters you want included in the export. Only applications currently visible in the table are exported.

3. Export

   Click Export in the toolbar. The file downloads as applications-export-<date>.csv.

The Status column in the file uses the same labels as the status badge.

Exports are capped at 10,000 applications per file. Use filters to narrow the list if your catalog exceeds that limit.