Application Access Request
Streamlines how employees request and receive access to business applications, with built-in approvals and automatic provisioning to reduce IT load and accelerate time-to-productivity.
- Triggered when a user requests access to an application
- Validates the requester's eligibility and current access before routing
- Adapts the approval flow based on the application, role, or business context
- Sends the approval request to the right approvers and tracks the response
- Supports tailored provisioning logic per application or instance
- Provisions access automatically once approved, with the appropriate permission level
- Notifies the requester through their preferred communication channel when access is ready
- Updates the ticket with the full outcome for audit and traceability
What Application Access Request does
Application Access Request lets employees ask for access to any app in the company catalog directly in chat, and handles everything from there - presenting the right access policy, collecting only the information that specific app requires, routing for approval when needed, and provisioning the access in the identity provider once approved. It replaces manually filed access tickets and back-and-forth with IT by resolving the whole request in one conversation, with automatic revocation for time-boxed grants.
Who Application Access Request Is For
Any employee who needs access to a SaaS application or internal tool, including new hires ramping up and existing employees requesting an upgrade to their current access level.
Before this agent, requesting app access meant filing a generic IT ticket, describing the app and access level in free text, and waiting for a human to figure out who owns the app, what approval it needs, and how to actually grant it - often across several ticket updates.
How Application Access Request Works
An employee tells Harmony's AI Helpdesk agent they need access to an app ("I need access to Figma," "can I get admin on Jira"). The agent classifies the intent (new access, upgrade, troubleshooting, or quota increase) and, for access requests, hands off into the app access flow with the app instance already identified.
- Confirm eligibility and existing access
checks whether the employee is already assigned to the app instance; if so, offers an upgrade or troubleshooting path instead of a duplicate request.
- Present access options
surfaces the app's configured access policies (e.g., "Engineering," "Sales Team," "General Access") as a plain numbered list, auto-selecting when there's only one valid option.
- Pull policy details via `get_app_policy_details`
retrieves whether business justification is required, what JIT (just-in-time) durations are allowed, and whether the policy auto-approves.
- Collect only what's required
asks for a justification only if the policy demands it, and asks for a JIT duration only if the app supports temporary access.
- Create the request via `create_app_access_request`
opens a
REQUEST-type Service Desk ticket carrying structured metadata (app, policy, group, JIT duration, justification) for the downstream workflow to consume. - Restricted-access gate
if the app is flagged as requiring manual review (via the
harmony:feature:application-access-requestflag), the agent skips self-service entirely and offers to open a general IT ticket instead. - Workflow takeover
the
app-accessTemporal workflow template picks up the ticket, resolves the identity provider for the app instance, and resolves the provisioning policy to decide the path below.
Auto-approved policies provision immediately; everything else routes to an approver first. Either way, the ticket updates in real time and resolves once access is granted (or closes if denied).
Sub-flow: Approval & Provisioning
The workflow determines the policy is not auto-approved.
- Send approval request
notifies configured approvers (default: the app owner, "any" strategy, 48-hour timeout with nudges) via the tenant's connected messaging channel.
- Provision on approval
calls
provision_access, which resolves the correct identity provider service (Okta, Microsoft Entra, Google Workspace, or JumpCloud) and assigns the employee either to a specific group or directly to the app, depending on what the provider and policy support (JumpCloud and role-gated Entra apps require group-based assignment). - Manual-provisioning fallback
if the policy is marked as needing manual completion, the ticket stays open and both app owners and IT approvers are notified to finish setup, with the ticket resolving only after they confirm.
Ticket resolves with a confirmation message, or closes with the denial reason if the approver rejects the request.
Sub-flow: JIT (Temporary) Access
The employee selected a time-boxed duration during the request.
- Workflow sleeps for the granted duration after provisioning.
- `revoke_access` fires automatically once the timer expires, removing the group/direct assignment via the same identity provider.
The employee is notified in the ticket that temporary access has expired and been revoked - no follow-up ticket needed.
Capabilities
- Detects app-access intent from natural language and distinguishes it from troubleshooting or quota requests, so it doesn't misfire on unrelated app questions.
- Finds the right application instance from a fuzzy or partial name, running full-phrase and simplified searches in parallel.
- Recognizes existing access and redirects to upgrade or troubleshooting instead of duplicating a request.
- Presents access policies (departmental groups, general access) as a simple, jargon-free choice - never exposing internal policy or group IDs to the employee.
- Collects business justification and JIT duration only when the specific app's policy requires them.
- Skips the confirmation step for tenants with auto-approve enabled, or asks for explicit confirmation otherwise.
- Provisions access directly in the resolved identity provider - Okta, Microsoft Entra, Google Workspace, or JumpCloud - using group or direct assignment as the app requires.
- Automatically revokes JIT (temporary) access once the granted duration elapses, with no manual cleanup step.
- Escalates to IT or app owners automatically when an app requires manual review, has no eligible policy, or has no compatible identity provider connected.
Main use cases
New hire requesting a common tool - An employee asks for access to a design tool; the agent finds the instance, shows the two configured policies ("Design Team" vs. "General Access"), and files the request. The policy auto-approves, so the workflow provisions the Okta group assignment immediately and resolves the ticket - no human touched it.
Sensitive access requiring approval - An employee asks for an elevated access tier that requires justification. The agent detects business_justification_required=true, asks why they need it, and files the ticket. The workflow sends an approval prompt to the app owner over the tenant's chat integration; once approved, access is provisioned and the ticket resolves - or the ticket closes with the stated reason if denied.
Contractor needing time-boxed access - An employee requests 24-hour access to a resource that supports JIT durations. After approval and provisioning, the workflow sleeps for the requested duration, then automatically revokes the access and posts a notice in the ticket - eliminating a manual "please remove this contractor's access" follow-up.
App requiring extra manual setup - A policy is marked as needing manual provisioning steps beyond the identity-provider group assignment. After the automated part completes, the ticket stays open while app owners and IT are notified to finish setup, resolving only once they confirm.
Integrations
| Integration | Role in the agent flow |
|---|---|
| Service Desk (ticketing) | Creates the initial Request ticket, carries all metadata the workflow needs, and receives every status update through resolution or closure |
| Application catalog (applications-api) | Source of app instances, eligibility, access policies, and assignment status used during search and policy selection |
| Identity providers - Okta, Microsoft Entra, Google Workspace, JumpCloud | Resolved per app instance; used to actually provision and later revoke access (tenant-optional - depends on which IdP integrations are connected) |
| Workflows engine (Temporal "app-access" template) | Orchestrates approval routing, provisioning, manual-completion waits, and JIT timers after the ticket is created; disabled by default per tenant |
| Messaging (Slack/Teams) | Delivers approval prompts to configured approvers (tenant-optional, depends on connected messaging integration) |
| Feature flag service | Gates the restricted-access check that routes sensitive apps to manual review instead of self-service |
FAQ
It's a capability inside Harmony's single AI Helpdesk agent (a toolkit called app_access), paired with a separate Temporal-orchestrated workflow template (app-access) that takes over once the ticket is filed to handle approval and actual provisioning.
Meet more Agents
