What applications provide
Application catalog
Centralized inventory of tools and systems your organization uses
Access level definitions
Different permission tiers for each application
Approval configuration
Control who approves requests for each access level
Identity provider integration
Map access levels to groups in Okta or Google Workspace
Setting up applications
Create application entries to represent the tools and services your organization uses.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 details appear in hover cards when users view the application in ticket custom fields.
- Owner: User or user group responsible for managing this application. Selecting a group lets the entire group act as the owner for routing and fallback purposes.
- Approver: User or user group responsible for approving access requests for this application. Used by access levels and approval templates that route to the “Application Approver” role. When a group is selected, every member of the group is treated as an approver. If no approver is set, the application owner is used as a fallback.
- Post Provisioning Message: Optional rich text message sent to the requester after access has been granted. See Post provisioning message for details.
- Workspaces: Select which workspaces can surface this application via request forms
4
Configure access levels
Add access levels to define the different permission tiers available for this application.
5
Save application
Click Save to create the application.
Customizing synced application names
Applications synced from identity providers (Okta, Google Workspace, Microsoft Entra ID) use the integration’s application name by default. You can set a custom display name to make applications easier to identify for your users.1
Open the synced application
Go to Settings > Applications and select the synced application you want to rename.
2
Edit the application
Click the Edit button to open the application settings.
3
Set a display name
Enter your preferred name in the Display Name field. This overrides the integration name shown to users.
4
Save changes
Click Save to apply the new display name.
- The application appears as Display Name (Original Name) throughout the platform
- The original integration name is preserved for reference and syncing
- Clearing the display name reverts to showing only the original name
The original application name remains unchanged and continues to sync with your identity provider. Only the display name shown to users is affected.
Post provisioning message
Set a custom message that’s sent to the requester on the ticket once their access has been provisioned. Use it to share login instructions, links to documentation, onboarding resources, or any other context specific to that application.When set, the post provisioning message replaces the default confirmation text on the ticket for both fully provisioned and partially provisioned access requests. When left blank, Ravenna uses the default messages.When to use it
Share login instructions
Point users to a single sign-on URL, account setup link, or first-time login steps
Link to onboarding resources
Direct users to internal guides, training videos, or runbooks for the application
Set expectations
Note any post-provisioning steps the requester needs to take, such as installing a client or accepting an invite email
Highlight support contacts
Tell requesters who to reach out to with questions about the application
Configure the message
1
Open the application
Go to Settings > Applications and select the application you want to edit.
2
Edit the post provisioning message
In the Post Provisioning Message field, enter the rich text message you want requesters to see after access is granted. You can include formatted text, links, and lists.
3
Save the application
Click Save to apply your changes. The message is used for all future access requests against this application.
Default messages
If no post provisioning message is configured, Ravenna posts one of the following on the ticket:The post provisioning message is sent only after access is successfully provisioned (or partially provisioned). It isn’t sent when a request is rejected or when provisioning fails.
Exporting applications
Export your application catalog to a CSV file for reporting, audits, or backup. The export mirrors the list you currently see in Settings > Applications, so any search, sort, or filter you apply is reflected in the file.When to export
Audit and compliance
Share a snapshot of your application catalog with auditors or security reviewers
Reporting
Build reports outside Ravenna using spreadsheet or BI tooling
Catalog review
Review ownership, approvers, and access levels across applications in bulk
Backups
Keep an offline record of your catalog before large changes
Export the catalog
1
Open applications
Go to Settings > Applications.
2
Filter the list (optional)
Apply any search, sort, or filters you want included. Only the applications currently visible in the table are exported.
3
Export
Click Export in the toolbar. The CSV downloads to your browser as
applications-export-<date>.csv.What’s included
Each row in the CSV represents one application. The export resolves user, group, workspace, and access-level references to human-readable names.Exports are capped at 10,000 applications per file. Use filters to narrow the list if your catalog is larger than that.
Archiving applications
Archive applications you no longer want users to request access to without losing their configuration or breaking historical tickets. Archived applications are hidden from request forms and the application catalog by default, but their access levels and approval history remain intact for audit purposes.When to archive
Decommissioned tools
The application is being retired and you do not want new access requests
Replaced applications
A new tool has replaced this one but you need to keep historical records
Seasonal access
The application is only used during specific periods and should be hidden between cycles
Cleanup
The application was created in error or is no longer relevant to your catalog
Archive an application
1
Open the application
Go to Settings > Applications and select the application you want to archive.
2
Archive the application
Use the Archive action in the application’s details to archive it. A confirmation appears before the application is archived.
Unarchive an application
1
Show archived applications
From Settings > Applications, add a status filter for Archived to display archived applications. Archived applications are hidden by default.
2
Open the archived application
Select the archived application you want to restore.
3
Unarchive the application
Use the Unarchive action to restore the application to active status.
Status and visibility
A color-coded Archived badge appears on the application row so you can identify archived applications at a glance.
Archiving an application does not revoke any access that has already been provisioned through it. Archived applications stop appearing in new request forms, but existing tickets, access levels, and identity provider mappings are preserved. To revoke previously granted access, handle the deprovisioning separately in your identity provider.
Deleting applications
Delete an application when you want to permanently remove it from your catalog. Unlike archiving, deletion is irreversible and removes the application from Ravenna entirely.When to delete versus archive
Delete
The application was created in error, contains test data, or has no historical tickets or approvals you need to retain
Archive
The application is being retired but you want to preserve its access levels, approval history, and ticket references for audit purposes
Delete an application
1
Open the application
Go to Settings > Applications and select the application you want to delete.
2
Delete the application
Use the Delete action in the application’s details. A confirmation dialog appears before the application is permanently removed.
3
Confirm deletion
Confirm the deletion to remove the application, its access levels, and its identity provider mappings from Ravenna.
Deleting an application does not revoke any access that has already been provisioned through it. To revoke previously granted access, handle the deprovisioning separately in your identity provider.
Access levels
Access levels define the different permission tiers available within an application. Each access level represents a specific set of capabilities users can be granted.Why use access levels?
Access levels help organizations implement least-privilege access by allowing users to request only the permissions they need for their role. This reduces security risk while maintaining operational efficiency.Model real permissions
Define levels that match how your organization actually uses each application
Reduce over-provisioning
Grant only the access users need for their specific role
Streamline requests
Users select specific levels, reducing approval back-and-forth
Support compliance
Maintain clear records of what access each user has
Managing access levels
Access levels have a dedicated Access Levels tab on the application details page. Click any row in the table to edit that access level inline.Creating access levels
1
Open application settings
Go to Settings > Applications, select an application, and open the Access Levels tab.
2
Add access level
Click Add Access Level to create a new permission tier.
3
Configure the level
Provide:
- Name: Clear name indicating what this level grants (e.g., “Admin”, “Editor”, “Viewer”)
- Description: Detailed explanation of what permissions this level includes
- Assignment strategy: How approvers are assigned when users request this level
- Approvers: Who can approve requests for this access level
4
Map to identity provider groups (optional)
If using an identity provider integration, map the access level to the corresponding user group for automated provisioning.
Learn about user groups including synced groups from identity providers
Example access level structure
Access levels should reflect how your organization actually uses each application. Here’s an example for Slack:Structure access levels based on actual usage patterns in your organization, not theoretical permission models.
Archiving access levels
Archive access levels you no longer want users to request without losing their configuration or breaking historical tickets. Archived access levels are hidden from request forms by default, but their approval history and identity provider mappings remain intact for audit purposes.When to archive an access level:- A permission tier has been deprecated but historical requests should be preserved
- You are restructuring an application’s permissions and need to retire old levels
- A level was created in error and should be hidden from new requests
- A level only applies during specific periods and should be hidden between cycles
1
Open the Access Levels tab
Go to Settings > Applications, select the application, and open the Access Levels tab.
2
Archive the access 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.
Archiving an access level does not revoke access already granted through it. Existing tickets, approval history, and identity provider 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. Configure different strategies for different access levels based on risk and organizational requirements.Auto
Auto
Automatically approves requests without human intervention. The system bot is assigned as the approver and the request is immediately approved.When to use:
- Low-risk applications that don’t require oversight
- Self-service applications with built-in approval mechanisms
- Testing or development environments
- Applications where immediate access is acceptable
- Request is approved immediately upon submission
- System bot is recorded as the approver
- No waiting period or manual review required
All
All
Assigns all specified approvers to the ticket. Any one of them can approve the request.When to use:
- Multiple people are qualified to approve
- You want the fastest response from a pool of approvers
- Cross-functional teams where any member can approve
- All approvers in the list are assigned to the ticket
- Any single approver can approve the request
- First approval completes the approval step
Round Robin
Round Robin
Distributes approval requests evenly across the approver pool. Only one approver is assigned per request.When to use:
- Balancing approval workload across team members
- Applications with multiple qualified approvers
- Avoiding bottlenecks from single points of approval
- Ensuring fair distribution of approval responsibilities
- Automatically tracks and rotates through approvers
- Assigns the next approver in the sequence
- Only one approver is assigned per request
- Ensures fair distribution across subsequent requests
Identity provider integration
Map access levels to groups in your identity provider for automated provisioning after approval. When a workflow provisions access, it can automatically add users to the appropriate groups in Okta or Google Workspace.Okta
Connect your Okta integration and map access levels to Okta groups. After approval, workflows can automatically assign users to applications or add them to groups.How it works:- In the Okta integration settings, connect your Okta organization
- When creating an access level, select the corresponding Okta group from the dropdown
- In your workflow, use Okta actions to provision access after approval:
- Add Users to Application: Directly assign users to Okta applications
- Add Users to Group: Add users to Okta groups that grant application access
1
Connect Okta integration
Navigate to Settings > Integrations and configure your Okta connection.
2
Map access levels
When creating access levels in applications, select the corresponding Okta group from the dropdown menu.
3
Configure workflow provisioning
In your access request workflows, add Okta actions after approval to automatically provision access.
Learn about Okta integration and automated provisioning
Google Workspace
Connect your Google Workspace integration and map access levels to Google Groups. After approval, workflows can automatically add users to the mapped groups.How it works:- In the Google Workspace integration settings, connect your workspace
- When creating an access level, select the corresponding Google Group from the dropdown
- In your workflow, use Google Workspace actions to provision access after approval:
- Add Users to Group: Add users to Google Groups that grant application access
- Create Email Alias: Create email aliases for role-based access
1
Connect Google Workspace integration
Navigate to Settings > Integrations and configure your Google Workspace connection.
2
Map access levels
When creating access levels in applications, select the corresponding Google Group from the dropdown menu.
3
Configure workflow provisioning
In your access request workflows, add Google Workspace actions after approval to automatically provision access.
Learn about Google Workspace integration and automated provisioning
See the Setting up access requests guide for step-by-step instructions on building complete access request workflows