Access levels
Define different permission tiers per application
Request types
Create request forms for users to request application access
Workflow automation
Build custom approval and provisioning workflows
Automatic catalog sync
Sync with Okta or Google Workspace
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)
- Owner: Person or team responsible for managing this application
- 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.
Access levels
Access levels let you define different tiers of permissions within a single application. You can model the actual access structure your organization needs.Why use access levels?
Different roles require different levels of access. Access levels let you tailor permissions so each person only gets the capabilities they need, nothing more. This helps teams follow security best practices like least-privileged access, reducing risk while keeping workflows efficient.Model real-world access
Define levels like Viewer, Editor, Admin, or custom levels specific to each application.
Reduce over-provisioning
Grant only the access users actually need.
Streamline requests
Users select the specific level they need, reducing back-and-forth.
Maintain compliance
Track exactly what level of access each user has.
Creating access levels
1
Navigate to applications
Go to Settings > Applications and select an application.
2
Add access levels
Click Add Access Level to create a new level. Provide a name and description that clearly indicates what permissions this level grants.
3
Map to identity provider groups (optional)
If using Okta or Google Workspace, map the access level to the corresponding group for automated provisioning.
Example access level structure
Here’s how you might structure access levels for a tool like Slack:Access levels should reflect how your organization actually uses each application, not theoretical permission structures.
| Access Level | Description |
|---|---|
| Admin | Full admin capabilities |
| User Admin | User admin capabilities |
| Channel Manager | Create, edit, delete and manage channels |
| Member | Simple user, no admin capabilities |
Approval strategies
Each access level can be configured with an approval strategy that determines how approval requests are processed when users request that level of access.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 (Rav Bot) is recorded as the approver
- No waiting period or manual review required
All
All
Requires approval from every assigned approver. All specified individuals and group members must approve before the request is granted.When to use:
- High-risk or sensitive applications requiring consensus
- Compliance scenarios where multiple stakeholders must sign off
- Applications requiring both technical and business approval
- Cross-functional approvals (security team + manager + application owner)
- All approvers are assigned to the ticket
- Every single approver must provide approval
- Request only proceeds when all approvers have approved
- Can create bottlenecks if any approver is unavailable
Round Robin
Round Robin
Distributes approval requests evenly across the approver pool using a rotating assignment system. 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 all subsequent requests
Setting up access requests
Once you’ve created your applications and access levels, set up a way for users to request access. This involves creating a request type, adding the appropriate fields, and building a workflow to handle approvals and provisioning.Step 1: Create a request type
Create a dedicated request type for application access requests.1
Create new request type
Within Request Types click New > Request Type and give it a name like “Application Access Request”.
2
Configure basic settings
Set the description and any other basic settings for the request type.
Step 2: Add application fields
Add the Application Select and Access Level Select fields to your request type so users can specify what they’re requesting.1
Edit the request type form
Open your request type and navigate to the form builder.
2
Add Application Select field
Add an Application Select field. This allows users to choose which application they need access to.
3
Add Access Level Select field
Add an Access Level Select field. This field dynamically shows the access levels available for the selected application.
4
Add any additional fields
Include fields like “Business Justification” or “Duration” as needed for your approval process.
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 3: Create an approval workflow
Build a workflow that triggers when users submit this request type. Use nested conditions to route requests to the right approvers based on the application and access level.1
Create a new workflow
Go to Workflows and click New > Workflow.
2
Set the trigger
Configure the workflow to trigger on Ticket Created and add a condition to filter to your newly created Application Access Request type.
You can either use branching and one workflow to catch all application requests, or create separate workflows per application. Choose the approach that best fits your organization’s needs.
3
Configure approvers
Within each condition branch, use the Add Ticket Approvers action to assign the appropriate approver(s).
Use dynamic approvers like the requester’s manager or specific groups based on the application and access level.
4
Add provisioning actions
After approval, add actions to provision access. Such as adding the user to the appropriate Okta or Google Workspace group.
Example workflow structure
Here’s an example of how you might structure your approval workflow:Trigger: Ticket Created (Application Access Request)
│
├─ Application = “Salesforce”
│ ├─ Access Level = “Admin”
│ │ ├─ Add Approvers: IT Security Team + Department VP
│ │ ├─ Wait for Approval
│ │ └─ Add to Okta Group: salesforce-admins
│
│ └─ Access Level = “Standard User”
│ ├─ Add Approvers: Requester’s Manager
│ ├─ Wait for Approval
│ └─ Add to Okta Group: salesforce-users
│
├─ Application = “GitHub”
│ ├─ Add Approvers: Engineering Manager
│ ├─ Wait for Approval
│ └─ Add to GitHub Organization
│
└─ Default
├─ Add Approvers: IT Help Desk
└─ Wait for Approval
Workflow documentation
Learn more about building workflows, conditions, and available actions.