> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access provisioning

> Manage application access requests with policies, approval templates, and automated provisioning through identity providers.

## Mental model

Access provisioning is built from four resources that chain together:

| Resource          | Role                                                           | Key relationship                                                                                |
| ----------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Application**   | The tool or service (e.g., GitHub, Salesforce).                | Has many access levels. Can be synced from an IdP or created manually.                          |
| **Access level**  | A permission tier within an application (e.g., Admin, Viewer). | Belongs to one application. Has a provisioning method and optionally links to an access policy. |
| **Access policy** | Governance rules for requesting an access level.               | Links to an approval template. Controls eligibility, duration, and justification.               |
| **Entitlement**   | A concrete access grant for a user.                            | Created when an approved request is provisioned. Tracks status, expiration, and lineage.        |

The request flow: user submits request for an access level -> policy evaluated (eligibility) -> approval template materialized on ticket -> provisioning executed -> entitlement created.

***

## Agent activation

The agent's access provisioning capabilities require the **Software Access Requests** toggle to be on (Identity tab > Advanced Settings).

When active, the agent can look up eligible applications filtered by the user's group membership, access levels with their policy requirements (approval, duration options, business justification), and the user's current active entitlements.

***

## Constraints

* Automated provisioning requires an active integration with Okta, Google Workspace, or Microsoft Entra ID.
* Access policies are organization-scoped. A single policy can be shared across access levels in different applications.
* Entitlements are immutable records. Extensions create new linked entitlements rather than modifying the original.
* Revocation of synced-app entitlements triggers deprovisioning in the IdP immediately.
* If the agent cannot resolve eligibility (user not in any eligible group and no default policy exists), the application does not appear in results.