> ## 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.

# Applications

> Build and manage your application catalog with access levels, provisioning methods, and identity provider integrations.

Applications represent the external tools and services your organization uses. By defining applications in Ravenna with their corresponding access levels and provisioning methods, you create a structured catalog that supports automated access requests.

## Mental model

The application is the core primitive of the access catalog. It answers the question: what can users request access to, and at what permission level?

Key relationships:

* An organization has many applications.
* An application has many access levels.
* Each access level has a provisioning method and can optionally map to an IdP group.
* Each access level has an assignment strategy that controls how approvers are assigned.
* Applications are organization-scoped but can be made visible in specific workspaces.

**Synced vs manual:** Applications with `integrationApplicationId != null` are synced from an identity provider (Okta, Google Workspace, Microsoft Entra ID). `isSynced` is the relevant check for enforcing edit restrictions: synced applications cannot be deleted, and their name and image are controlled by the IdP. All other fields (display name, owner, approver, workspaces, post provisioning message) can be set regardless of sync status.

**Access levels** are scoped to a single application. There is no shared or global access level concept across applications.

***

## Provisioning method selection

| Method          | When to use                                                                                                                               |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Group**       | IdP manages application access through group membership. After approval, add the user to the mapped IdP group.                            |
| **Application** | Direct application assignment is preferred over group membership in the IdP. After approval, add the user to the application directly.    |
| **Manual**      | No IdP connection or automated provisioning path exists. A human must provision access and mark the entitlement complete.                 |
| **Workflow**    | Custom provisioning logic is required, such as calling external APIs or chaining multiple steps beyond what standard IdP actions support. |

If no IdP integration is active, use **Manual** or **Workflow**. Group and Application methods require a connected integration; provisioning actions will fail if the integration is disconnected even if the mapping is configured.

***

## Assignment strategy selection

Assignment strategies are configured per access level, not per application. Different levels within the same application can use different strategies.

| Strategy        | Approvers assigned       | Approval required from     | Best for                                                   |
| --------------- | ------------------------ | -------------------------- | ---------------------------------------------------------- |
| **Auto**        | System bot               | None, approved immediately | Low-risk apps, dev/test environments, self-service tools   |
| **All**         | All configured approvers | Any one approver           | Multiple qualified approvers, fastest response time needed |
| **Round Robin** | One approver (rotated)   | The assigned approver      | Balancing workload across a team, avoiding bottlenecks     |

Common pattern: use Auto for basic access levels (such as Member) and All or Round Robin for elevated access levels (such as Admin).

***

## Constraints and gotchas

* Applications are organization-scoped. All workspaces share the same catalog, but workspace visibility is configurable per application.
* Synced applications (`integrationApplicationId != null`) cannot be deleted and do not allow name or image edits. Custom display names are cosmetic only and do not affect integration behavior.
* Archived applications reject new access requests and modifications to their access levels with an `APPLICATION_NOT_ACTIVE` error. Unarchive before resuming activity.
* Archiving and deletion do not revoke previously provisioned access. Revocation must be handled in the IdP.
* Access level IdP group mappings require an active integration. If the integration is disconnected, mappings persist but provisioning actions will fail.
* Owner and approver fields each accept either a user or a user group, but not both simultaneously. Selecting one clears the other.
* The post provisioning message is sent only after successful provisioning (full or partial). It is not sent on rejection or failed provisioning.
* Exports are capped at 10,000 applications per file.