Application Access Request
Automated application access requests with approval and provisioning.
The Application Access Request agent automates application access requests with approval workflow and identity provider provisioning.
What it does
Triggered when a user requests access to an application
Classifies the request upfront - detecting whether the user needs new access, wants to modify existing access, is experiencing a technical issue, or has an unclear request - and routes accordingly
Checks the service catalog before proceeding to app access policy selection, ensuring requests are always routed through the right steps
Guides employees through selecting an access policy and, where configured, collecting a business justification
Sends approval request to one or more approvers and waits for response
On approval: provisions application access via identity provider, or notifies a responsible person for manual provisioning
Updates the ticket with the outcome and moves it to the correct status at each stage
Triggers
Event - Runs when agent detects Application Access Request made by user.
Approval
Requires approval by default. A single flexible approval block replaces multiple workflow-specific approval configurations. You can define approvers, resolution strategies (any/all/fallback), multi-tier sequential approvals, timeouts, and interactive fields such as group selection - all in one place. Approvers receive rich Slack or Teams notifications and admins can override or edit approvers mid-flight.
Configure approvers (for example, application owners), approval logic (require one or all), and timeout settings.
Configuration
Approval - Set approvers, approval logic, timeout duration
Identity provider - Supported: Okta, Microsoft Entra, Google Workspace
Execution settings - Approval request timeout (e.g., 2 days)
Notifications - Toggle notifications for approval status
Business justification - Optionally require employees to provide a business justification when submitting an access request (see Business Justification below)
Manual provisioning - Mark individual apps as manually provisioned for apps not connected to Okta (see Manual Provisioning below)
Post-approval message - Compose a rich text message shown to users after their request is approved, with support for bold text, bullet lists, numbered lists, and hyperlinks
Access Request Control per Application
Each application in your organization has an Access Request status - either Available or Unavailable - that determines whether the App Access Request agent and AI assistant will offer provisioning or access options for that app.
All applications default to Unavailable, so no access requests are processed until an admin explicitly enables them.
A new Access Request column and filter in the Applications table lets you quickly see and sort which apps are enabled for access requests.
Only apps with Discovered or Approved status are considered when the agent evaluates access requests. Apps marked as Ignored are filtered out entirely and will not be surfaced to users or approvers.
Provisioning Configurations
Configure how users are granted access to applications by default. Choose between direct app assignment or group-based access for each application in your organization.
For each application, you can configure:
Provisioning Method - Dynamic assignment (automatic) or static assignment
Access Duration - Unlimited or time-limited (JIT) access. Available durations include: 1 hour, 30 days, 60 days, 90 days, and other preset windows
Auto Approval - Enable to bypass approval workflow for specific applications
Application Owners - Designate owners who can approve access requests
Manual Provisioning - Mark an app as manually provisioned when it is not connected to Okta (see below)
The provisioning table displays all connected applications from your identity provider, including their instance names, current configuration, and assigned owners. Use the search bar to quickly find specific applications.
App Group Selection
When configuring group-based access, the group selection area is larger and more prominent, and badges wrap correctly so all labels remain visible. This makes it easier to browse and choose application groups, especially when working with multiple groups.
Policy-Based and Group Access
Employees can now request access to specific groups and resources within an application. The AI agent guides employees through selecting the right access policy for their needs. Approvers receive full context in their notifications - including the requested group, the employee's business justification, and the identity provider involved - without needing to look up details separately.
When multiple instances of an app exist across different identity providers, the agent applies a priority hierarchy:
Okta or Microsoft Entra instances are always preferred over Google Workspace when both are available.
Google Workspace is used as a fallback only when no other identity provider source exists for the app.
When multiple non-IDP instances exist, the agent selects the single instance with the highest relevance.
Business Justification
You can require employees to provide a business justification when submitting app access requests, directly from the agent configuration. This setting is off by default. Two modes are available:
Request justification for all applications - Overrides any existing provisioning policy and always prompts for a justification, regardless of per-app settings.
Request justification only for applications without an existing provisioning policy - Applies only where no provisioning policy is already defined, leaving existing per-app policies unchanged.
When a justification is provided, it is included in the approval notification so approvers have the full context they need.
Just-in-Time (JIT) Access
You can configure Just-in-Time provisioning as part of your app access workflows. When a user requests access to an application, the agent enforces temporary, time-limited access based on the provision policy defined for that application - ensuring access is automatically revoked after the specified duration.
Available JIT access durations include:
1 hour - for short-lived, tightly scoped access needs
30 days
60 days - for longer-term access without repeated re-approval
90 days
JIT duration is surfaced clearly in approval notifications delivered through Slack, Microsoft Teams, and email, so users and approvers always know when access will expire. Provisioning and revocation are handled end-to-end within the workflow.
Manual Provisioning
You can mark individual apps as manually provisioned in the agent configuration page, enabling access request workflows for apps that are not connected to Okta.
Manual provisioning indicator - A per-app checkbox in the agent configuration page identifies apps that require manual provisioning rather than automated Okta-based provisioning.
Responsible person assignment - When manual provisioning is enabled for an app, you designate a responsible person who automatically receives a message to provision access once a request is approved.
Approval Notifications
Approvers receive interactive approval requests via Slack or Microsoft Teams, including OTP verification support for Teams. Notifications include:
The name of the group for which access was requested
The employee's business justification (when provided)
JIT access duration (when applicable)
The identity provider context
Approval notifications preserve their original structure and include clear details about the group and provider involved, so approvers can review and act with the right context at a glance.
Ticket Status During Approvals
When the agent is waiting on an approval before proceeding, the ticket is automatically moved to a Pending Approval status. This gives your team a real-time picture of where each request stands and makes it easier to identify tickets that are blocked on a human decision.
Last updated
Was this helpful?