> For the complete documentation index, see [llms.txt](https://docs.harmony.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.harmony.io/ai-agents/software-management/app-access.md).
# Application Access Request
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](#business-justification) below)
* **Manual provisioning** - Mark individual apps as manually provisioned for apps not connected to Okta (see [Manual Provisioning](#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:
1. **Okta or Microsoft Entra instances are always preferred** over Google Workspace when both are available.
2. **Google Workspace is used as a fallback** only when no other identity provider source exists for the app.
3. **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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.harmony.io/ai-agents/software-management/app-access.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.