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:
Trigger: Ticket Created (Application Access Request)
│
├─ If Application = "Salesforce"
│   ├─ If Access Level = "Admin"
│   │   ├─ Add Approvers: IT Security + VP
│   │   ├─ Wait for Approval
│   │   └─ Add to Okta Group: salesforce-admins
│   │
│   └─ If Access Level = "Standard"
│       ├─ Add Approvers: Manager
│       ├─ Wait for Approval
│       └─ Add to Okta Group: salesforce-users
│
├─ If Application = "GitHub"
│   ├─ Add Approvers: Engineering Manager
│   ├─ Wait for Approval
│   └─ Add to GitHub Organization
│
└─ Default
    ├─ Add Approvers: IT Help Desk
    └─ Wait for Approval

​
Add approval actions

For each application or access level branch, configure approval actions:
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.
3

Add conditional for approval result

Add a conditional to check if the request was approved or declined. Handle each case appropriately.
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.

​
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: 
Trigger: Ticket Created (Application Access Request form)
│
├─ Application = "Salesforce"
│   ├─ Access Level = "Admin"
│   │   ├─ Add Approvers: IT Security Team + Department VP (All)
│   │   ├─ Wait for Approval
│   │   ├─ If Approved:
│   │   │   ├─ Add to Okta Group: salesforce-admins
│   │   │   └─ Send Message: "Access granted"
│   │   └─ If Declined:
│   │       └─ Send Message: "Request declined"
│   │
│   └─ Access Level = "Standard User"
│       ├─ Add Approvers: Requester's Manager
│       ├─ Wait for Approval
│       ├─ If Approved:
│       │   ├─ Add to Okta Group: salesforce-users
│       │   └─ Send Message: "Access granted"
│       └─ If Declined:
│           └─ Send Message: "Request declined"
│
├─ Application = "GitHub"
│   ├─ Add Approvers: Engineering Manager (Round Robin)
│   ├─ Wait for Approval
│   ├─ If Approved:
│   │   ├─ Add to Google Group: github-developers
│   │   └─ Send Message: "Access granted"
│   └─ If Declined:
│       └─ Send Message: "Request declined"
│
└─ Default (all other applications)
    ├─ Add Approvers: IT Help Desk (Round Robin)
    ├─ Wait for Approval
    ├─ If Approved:
    │   └─ Send Message: "Contact IT to provision access"
    └─ If Declined:
        └─ Send Message: "Request declined"