> ## 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: add or sync applications, track setup status, and archive, delete, or export them.

Applications represent the external tools and services your organization uses. Each application holds the [access levels](https://docs.ravenna.ai/documentation/automate/access-management/access-levels.md) people can request, and each access level has a [provisioning method](https://docs.ravenna.ai/documentation/automate/access-management/provisioning.md) that decides what happens after approval.

## 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.
* Applications are organization-scoped but can be made visible in specific workspaces.

**Synced vs manual:** Applications with `integrationApplicationId != null` are synced from an access provider (Okta, Microsoft Entra ID, JumpCloud, OneLogin, or Cloudflare). `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, owners, approvers, workspaces, post provisioning message) can be set regardless of sync status.

**Google Workspace never produces synced applications.** Google-federated applications are always manual entries. Group provisioning still works: it resolves the access level's mapped group to a Google Group and adds the user there, without consulting the application record.

* Access levels and their assignment strategies: see the access levels page. Provisioning methods and what they change: see the provisioning page.

***

## 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.
* The post provisioning message is sent only after successful provisioning (full or partial). It is not sent on rejection or failed provisioning.
* An access level's post provisioning message takes priority over the application's. When the access level has no message, the application's message is sent. When neither is set, Ravenna sends its default confirmation.
* Post provisioning messages can reference the request's ticket fields, stored in `postProvisioningMessage` as `{{jp:$.postProvisioning.input.ticket.<field>}}`, the same path form workflows use, for example `{{jp:$.postProvisioning.input.ticket.requester.firstName}}`. A reference can also be a link target, as in `[View ticket]({{jp:$.postProvisioning.input.ticket.link}})`. Ravenna resolves them only in the message it posts on the ticket after provisioning. The **Post provisioning message** workflow variable returns the message with its references unresolved.
* Exports are capped at 10,000 applications per file.
* Application status is derived, not stored (`getApplicationConfigurationStatus` in `packages/types/src/validators/application.ts`). In order: `archivedAt` set, or IdP status `INACTIVE` or `DELETED`, is **Archived**. No access levels with `archivedAt: null` is **Needs Setup** (`needs_configuration`). Live access levels but no workspaces is **Configured**. Otherwise **Available**. Archived access levels never count, in the badge or in the Status filter.
* Saved Status filters that hold the retired `active` value still work. A scalar `active` resolves to Available or Configured, and inside `in` and `not_in` lists it expands to both.


## Related topics

- [Delete an application](https://docs.ravenna.ai/api/application/delete-an-application.md)
- [List applications](https://docs.ravenna.ai/api/application/list-applications.md)
- [Update an application](https://docs.ravenna.ai/api/application/update-an-application.md)
- [Bulk delete applications](https://docs.ravenna.ai/api/application/bulk-delete-applications.md)
- [Export applications to CSV](https://docs.ravenna.ai/api/application/export-applications-to-csv.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.