Skip to main content
Set up automated access request workflows so users can request application access through forms, approvers receive tickets routed based on your policies, and access is provisioned automatically after approval. This guide walks through creating a complete access request system including forms, workflows, and integration with identity providers for automated provisioning.
Learn about IGA/IAM concepts including birthright access, JIT access, and the employee lifecycle

​
Access request patterns

Organizations typically manage two types of access during the employee lifecycle: Birthright access is handled by your identity provider (Okta, Google Workspace) using group rules based on employee attributes like department or role. This access is applied automatically as attributes change. Just-in-time (JIT) access is handled by Ravenna for ad hoc requests, project-based needs, and exceptions that require approval. This guide focuses on setting up JIT access request workflows.

​
Before you begin

You need:
  • Applications configured with access levels in Settings > Applications
  • Identity provider integration (Okta or Google Workspace) for automated provisioning
  • Understanding of your approval policies and who should approve different access levels
Learn about applications and access level configuration

​
Step 1: Create an access request form

Create a dedicated form for application access requests that users will submit.
1

Create new form

Go to Forms and click New > Form. Name it “Application Access Request” or similar.
2

Configure basic settings

Set the form description to help users understand when to use this form.
3

Add Application Select field

Add an Application Select field. This allows users to choose which application they need access to from your application catalog.
4

Add Access Level Select field

Add an Access Level Select field. This field dynamically shows the access levels available for whichever application the user selects.
5

Add supporting fields

Add fields like:
  • Business Justification (text area) - Required field for users to explain why they need access
  • Duration (select or text) - Optional field if access should be time-limited
  • Manager Approval (yes/no) - If you want to track whether the requester’s manager approves
6

Save the form

Save your form configuration.
The Access Level Select field is dependent on the Application Select field. It will only show access levels for the application the user selects.

​
Step 2: Create an approval workflow

Build a workflow that triggers when users submit the access request form and routes the request to appropriate approvers based on the application and access level.

​
Create the workflow

1

Create new workflow

Go to Workflows and click New > Workflow. Name it “Application Access Approval” or similar.
2

Configure trigger

Set the trigger to Ticket Created and add a filter for your Application Access Request form type.

​
Choose your routing approach

You can route access requests using one of two approaches:
Use one workflow with conditional branches for different applications. This approach centralizes your access request logic.When to use:
  • You want centralized control over access request routing
  • Applications have similar approval patterns
  • You prefer maintaining one workflow
Structure:

​
Add approval actions

For each application or access level branch, configure approval actions. These actions create on the ticket.
Learn more about approval rounds and approval templates for reusable approval configurations
1

Add approvers

Use the Add Ticket Approvers action to assign approvers. You can:
  • Assign specific users (e.g., IT Security Team)
  • Assign groups (e.g., Engineering Managers)
  • Use dynamic approvers (e.g., requester’s manager)
  • Set assignment strategy (All, Round Robin, or Auto)
2

Wait for approval

Add a Wait for Approval action. The workflow pauses here until an approver approves or declines the request, or the wait duration expires (default 3 days). The step automatically branches into On Approved, On Declined, and On Timeout paths.
3

Handle each outcome

Fill in each branch with the right follow-up: provision access on On Approved, notify the requester on On Declined, and escalate or auto-close on On Timeout.
Learn about assignment strategies for different approval patterns

​
Step 3: Add provisioning actions

After approval, automatically provision access by adding users to the appropriate groups in your identity provider.

​
Okta provisioning

1

Add conditional for approved requests

Ensure provisioning only happens for approved requests by checking the approval status.
2

Add users to Okta group

Use the Add Users to Okta Group action. Select:
  • User: The requester (from ticket data)
  • Group: The Okta group mapped to the access level
3

Send confirmation

Use Send Ticket Message to notify the requester that access has been provisioned.

​
Google Workspace provisioning

1

Add conditional for approved requests

Ensure provisioning only happens for approved requests.
2

Add users to Google Group

Use the Add Users to Google Group action. Select:
  • User: The requester (from ticket data)
  • Group: The Google Group mapped to the access level
3

Send confirmation

Use Send Ticket Message to notify the requester that access has been provisioned.

​
Per-application provisioning settings

When a workflow trigger or form includes an Application Select field, the workflow step input panel exposes extra settings for each application that can be requested. Use these to tailor how the workflow handles access for that specific application without writing extra branches.
1

Open the workflow step

In the Workflow editor, open the step that consumes the Application Select field (typically the provisioning step that runs after approval).
2

Configure the application input

For each application listed in the step’s input panel, set the Provisioning method and, optionally, a Post provisioning message.
3

Reference the message in your confirmation

In a Send Ticket Message action after provisioning, insert the application’s post-provisioning message as a dynamic value so the requester sees the guidance you configured.
Leave Post provisioning message blank for applications that don’t need extra instructions. The workflow still sends the standard confirmation message you configured.

​
Step 4: Test your workflow

Test the complete access request flow before deploying to users.
1

Submit test request

Submit a test access request through your form as if you were a regular user.
2

Verify routing

Check that the ticket was created and routed to the correct approvers based on your workflow logic.
3

Test approval

Have an approver approve the request and verify the workflow continues correctly.
4

Verify provisioning

Check that the user was added to the correct group in your identity provider after approval.
5

Test edge cases

Test scenarios like:
  • Declined requests
  • Different applications and access levels
  • Different approval paths in your workflow

​
Step 5: Deploy to users

Make the access request form available to users in your organization.
1

Publish workflow

Publish your approval workflow so it activates and begins processing requests.
2

Add form to channel

Add the access request form to your support channel or help desk so users can easily find and submit requests.
3

Communicate to users

Let users know about the new access request process. Include:
  • How to submit access requests
  • What information they need to provide
  • Expected approval timeframes
  • Who to contact with questions

​
Example workflow structure

Here’s a complete example showing how you might structure an access request workflow for multiple applications:
Last modified on May 25, 2026