# Application Access Request

**Categories:** Software Management

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

**Persona:** 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.

**Pain point:** 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

**Trigger:** 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.

1. **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.

2. **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.

3. **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.

4. **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.

5. **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.

6. **Restricted-access gate** - if the app is flagged as requiring manual review (via the harmony:feature:application-access-request flag), the agent skips self-service entirely and offers to open a general IT ticket instead.

7. **Workflow takeover** - the app-access Temporal workflow template picks up the ticket, resolves the identity provider for the app instance, and resolves the provisioning policy to decide the path below.

**Outcome:** 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

**Trigger:** The workflow determines the policy is not auto-approved.

1. **Send approval request** - notifies configured approvers (default: the app owner, "any" strategy, 48-hour timeout with nudges) via the tenant's connected messaging channel.

2. **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).

3. **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.

**Outcome:** Ticket resolves with a confirmation message, or closes with the denial reason if the approver rejects the request.

## Sub-flow: JIT (Temporary) Access

**Trigger:** The employee selected a time-boxed duration during the request.

1. **Workflow sleeps for the granted duration after provisioning.**

2. **`revoke_access` fires automatically once the timer expires, removing the group/direct assignment via the same identity provider.**

**Outcome:** 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

### What exactly is Application Access Request - is it a bot, a workflow, or something else?

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.

### How does it decide what to do?

The conversational part is LLM-driven - it interprets what the employee is asking for and which policy applies. The fulfillment part is deterministic: each app's configured provisioning policy (auto-approve flag, justification requirement, allowed JIT durations) and the tenant's configured approvers/strategy drive exactly what happens next.

### What's automatic vs. what gets escalated to a human?

Auto-approved policies provision with zero human involvement. Everything else waits on a configured approver (default: the app owner, any-of strategy, 48-hour timeout). Apps flagged for manual review, apps with no eligible policy for the employee, or app instances with no resolvable identity provider are all routed to IT/app-owner escalation rather than self-service.

### Can it grant temporary, time-limited access?

Yes - if the app's policy defines allowed JIT durations, the employee picks one during the request, and the workflow automatically revokes the access through the identity provider once that duration expires, with no follow-up ticket required.

### What needs to be set up before this works?

The app needs to exist in the application catalog with at least one access policy (or general access) configured; the `app-access` workflow template must be explicitly enabled for the tenant (it's disabled by default); and the app instance needs a connected identity provider for automatic provisioning - otherwise a request falls back to a manual IT ticket.

## Related platform features

- **Application catalog / search (app_management toolkit)** - Internal discovery step that identifies the app instance before this agent's policy flow begins; not confirmed as its own catalog page
- **Service Catalog** - Fallback path referenced when an app has no configured access policies; exact catalog-page status not confirmed in code