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

# Provisioning

> What each provisioning method changes after approval, how identity provider groups relate to application accounts, and how to set up provisioning with each identity provider.

An access level's provisioning method decides what Ravenna changes once a request is approved, and what it reverses when the access is revoked or expires. This page covers what each method does, how an identity provider group relates to an account in the application, and how to set up each identity provider.

## 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; on revoke or expiry, remove them. Supported by Okta, Microsoft Entra ID, Google Workspace, JumpCloud, Cloudflare, and OneLogin. App accounts depend on the IdP's provisioning or the app's JIT. |
| **Application** | Direct Okta app assignment is preferred over group membership. After approval, assign the user to the Okta app; on revoke or expiry, unassign them. Supported by Okta only, for apps synced from Okta. Okta's provisioning settings for the app decide whether an account is created. |
| **Manual** | No IdP connection or automated account creation exists. A human provisions access and marks the entitlement complete. On revoke or expiry, nobody is prompted to remove the access. |
| **Workflow** | Don't recommend it. It is selectable when access policies are enabled but not implemented: approval creates no entitlement, runs no workflow, and nothing is revoked. The requester is still told access was provisioned. Recommend **Manual** instead. |
| **External** | Not selectable. Assigned by the Okta Identity Governance sync. |

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

When a user asks why someone has a group but no account in an app, the cause is almost always outside Ravenna: the group isn't assigned to the app in the IdP, the IdP has no provisioning connector for the app, or the app doesn't do JIT.

***

## Constraints and gotchas

* Provisioning changes IdP group membership or Okta app assignment only. Ravenna never creates, updates, or deactivates accounts inside downstream applications, and has no SCIM client. An account exists only if the IdP's provisioning connector or the app's JIT creates it, or a person does.
* Access level IdP group mappings require an active integration. If the integration is disconnected, mappings persist but provisioning actions will fail.
* **Group** provisioning is supported by Okta, Microsoft Entra ID, Google Workspace, JumpCloud, Cloudflare, and OneLogin. **Application** provisioning is supported by Okta only. Setting either method on an access level mapped to a provider that does not support it fails at provisioning time, not at configuration time.
* **OneLogin group mappings can hold only one grant per user.** A OneLogin user has a single group but many roles. A group-mapped grant for a user who already has a group fails with `USER_BELONGS_TO_DIFFERENT_PRIMARY_GROUP` and writes nothing to OneLogin, so the existing group is never displaced. Role-mapped access levels are additive and do not have this limit. Recommend roles when a user needs concurrent grants.
* Only owners named as users can mark a Manual entitlement provisioned; members of an owner group can't, although the ticket assignee, workspace admins, and organization admins can.
* Removing a group membership or Okta assignment doesn't guarantee the app account is deactivated. Existing sessions, local credentials, and API tokens are up to the application.
* **Google Workspace never produces synced applications.** 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.


## Related topics

- [List manual provisioning actions for a ticket](https://docs.ravenna.ai/api/access-entitlement/list-manual-provisioning-actions-for-a-ticket.md)
- [Bulk update access levels (provisioning method or access policy)](https://docs.ravenna.ai/api/access-level/bulk-update-access-levels-provisioning-method-or-access-policy.md)
- [Entitlements](https://docs.ravenna.ai/documentation/automate/access-management/entitlements.md)
- [Applications](https://docs.ravenna.ai/documentation/automate/access-management/applications.md)
- [Setting up access management](https://docs.ravenna.ai/guides/how-to/setting-up-access-management.md)


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