Skip to main content
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 methods

Each access level has a provisioning method that decides what Ravenna changes once a request is approved. Ravenna runs the request, the approval, and that one change, then tracks the result. What happens inside the application afterwards, such as whether an account exists or which role it has, depends on the method and on how your identity provider and the application are configured.Every method except Workflow creates an entitlement that records the grant, its expiry, and its revocation.

Group

Ravenna adds the user to the identity provider group mapped to the access level, and removes them when the access is revoked or expires. That membership change is the only change Ravenna makes. The group then does whatever your IdP is configured to do with it, such as assigning an SSO app or putting the user in scope for a provisioning connector. See group membership is not an application account.Supported by: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, Cloudflare, OneLoginUse this when your IdP already controls access to the application through group membership.For Cloudflare, the mapped group is a Cloudflare Access group and membership is expressed as an email include rule. See how Access group membership works.For OneLogin, the mapped entity can be a group or a role. A user can belong to only one OneLogin group at a time, so map to roles when a user needs to hold several grants at once. See OneLogin access management.
Ravenna assigns the user directly to the application in Okta through Okta’s application assignment API, and unassigns them on revoke or expiry. Ravenna sends only the assignment. Whether Okta then creates, updates, or deactivates an account in the application depends on that Okta app integration’s provisioning settings, such as Create Users and Deactivate Users.Supported by: Okta only, for applications synced from OktaUse this when you assign the Okta app to people directly rather than through groups.
Ravenna changes nothing outside Ravenna. After approval, the entitlement waits in Processing. Ravenna posts a private note on the ticket that mentions the application owners, and sends the ticket assignee a Slack message with a Provision access button. An authorized provisioner grants access in the application, then marks the entitlement provisioned.Authorized provisioners are the application’s owners (named users, not members of an owner group), the ticket assignee, workspace admins, and organization admins.When the access is revoked or expires, Ravenna ends the entitlement but doesn’t prompt anyone to remove the access. Remove it in the application yourself.No IdP required. Use this for applications that are not connected to an identity provider, or where automated provisioning is not possible.
The Workflow method doesn’t provision anything yet. When a request for a Workflow access level is approved, Ravenna records the approval but doesn’t run a workflow, create an entitlement, or revoke anything later. The access level has no setting that links it to a workflow. Use Manual for these applications until Workflow is supported.
To automate steps around a Manual grant, build a workflow on the Entitlement Status Changed trigger. See entitlements in workflows.

​
Group membership is not an application account

Group and Application provisioning stop at your identity provider. Three separate things decide whether someone can actually use an application:
  1. Access in Ravenna. Ravenna approves the request and changes the group membership or Okta assignment.
  2. Assignment in your IdP. The IdP decides which apps that group or assignment unlocks for single sign-on.
  3. An account in the application. Something has to create the user’s account in the app, give it the right role, and deactivate it later.
Single sign-on (SAML or OIDC) only handles step 2. It proves who the user is when they sign in. It doesn’t create, update, or deactivate accounts. Accounts come from one of these, configured in your IdP or the application rather than in Ravenna:
  • Automated provisioning (SCIM or a vendor API connector) in your IdP. It creates the account when the user is assigned, and can deactivate it when they’re unassigned.
  • Just-in-time (JIT) provisioning in the application. The app creates the account the first time the user signs in through SSO. JIT usually doesn’t deactivate the account when access is removed.
  • A person, who creates the account by hand.
Roles work the same way. A group can only set the user’s role in the application if the application supports group-to-role mapping, through SAML attributes or its provisioning connector, and you’ve configured it.
Example: a Google Group mapped to an app’s Member level. An access level maps to the slack-members Google Group, and the Slack SAML app is turned on for that group. When the request is approved, Ravenna adds the user to slack-members, and the user can now sign in to Slack through Google.
  • With SAML only, there’s no Slack account until something creates one. If your Slack setup creates accounts at first SSO sign-in (JIT), the first sign-in does it. Otherwise an admin has to create it, and removing the user from the group later leaves the account in place.
  • With automated provisioning set up for Slack in Google Workspace and scoped to slack-members, Google creates the Slack account after the user joins the group, and deactivates it according to your deprovisioning settings after they leave.
In both cases Ravenna’s part is the same: one group membership, added on approval and removed on revoke or expiry.
Removing a group membership can stop the user from signing in through SSO. It doesn’t guarantee the application account is deactivated or deleted. Sessions that are already open, local passwords, API tokens, and other sign-in methods can keep working until the application ends them. Confirm how each application handles this before you rely on Ravenna’s revoke or expiry to remove access.

​
What you configure where

​
Choosing a method

  • The application is behind your IdP and a group controls access: use Group. Check that the IdP provisions accounts for that app, or that the app uses JIT, or plan for someone to create accounts.
  • You assign the Okta app to people directly: use Application.
  • The application isn’t behind your IdP, or nothing automates account creation: use Manual. Ravenna still handles the request, approval, notification, and audit trail.
  • The request comes from your Okta Identity Governance catalog: Ravenna sets up External levels for you when you sync OIG.

​
Identity provider integration

Map access levels to groups in your identity provider so approved requests change group membership without anyone touching the IdP. After an access request is approved, Ravenna adds the user to the mapped group, or assigns them to the mapped Okta application.Ravenna doesn’t create accounts in the applications behind your IdP. Whether a group membership leads to a working account depends on that IdP’s app assignment and provisioning setup. See group membership is not an application account.Not all providers support the same provisioning methods:Workflow appears in the list because you can select it, but it doesn’t provision yet. See the Workflow method.

​
Okta

Connect your Okta integration and map access levels to Okta groups or applications. Okta is the only provider that supports both group-based and direct application assignment provisioning.
1

Connect the Okta integration

Go to Settings > Integrations and configure your Okta connection.
2

Map access levels

When creating an access level, select the corresponding Okta group from the dropdown.
3

Set the provisioning method

Choose how the access level provisions once a request is approved:
  • Group: Ravenna adds the user to the mapped Okta group. Okta assigns the user every app that group is assigned to.
  • Application: Ravenna assigns the user directly to the Okta application without group membership.
Ravenna makes the change automatically after approval. No workflow is required.
Either way, an account in the downstream application comes from Okta, not Ravenna. If the Okta app integration has provisioning with Create Users and Deactivate Users turned on, Okta creates the account on assignment and deactivates it on unassignment. Without provisioning, the assignment only lets the user sign in through Okta.
Learn more about the Okta integration

​
Google Workspace

Connect your Google Workspace integration and map access levels to Google Groups. Google Workspace supports group-based provisioning only. Direct application assignment is not available through this integration.Applications do not import from Google Workspace, so create them manually first. Google Groups do sync, and those are what the access level maps to.A Google Group controls access to Google Workspace resources shared with it, and to the SAML apps you turn on for it. It doesn’t create accounts in those apps:
  • SAML is sign-in, not provisioning. Turning a SAML app on for a group lets members sign in to the app through Google. It doesn’t create, update, or deactivate their account in the app.
  • Accounts need JIT or automated provisioning. The app creates the account at first sign-in if it supports JIT. For supported apps, Google Workspace can also create and deactivate accounts with automated user provisioning, which you set up separately after SSO and can scope to groups.
  • Roles need app support. A group sets the user’s role in the app only if the app supports group or attribute mapping and you’ve configured it.
  • Removing someone from the group isn’t deactivation. It can stop them signing in through Google, but the app account stays unless automated provisioning deactivates it. Open sessions, local passwords, and other sign-in methods can keep working, depending on the app.
1

Connect the Google Workspace integration

Go to Settings > Integrations and configure your Google Workspace connection. Users and groups begin syncing.
2

Add the application manually

Go to Settings > Applications and click Add Application. Name it after the app your Google Group grants access to, such as Slack or Zoom.
3

Map access levels

When creating an access level, select the corresponding Google Group from the dropdown. Every synced Google Group is available, since Ravenna cannot tell which groups Google associates with which app.
4

Set the provisioning method

Choose Group. After approval, Ravenna adds the user to the mapped Google Group, and removes them on revoke or expiry. What that membership grants is decided by the group’s settings in Google: resources shared with it, SAML apps turned on for it, and any automated provisioning scoped to it. No workflow is required.
Learn more about the Google Workspace integration

​
Microsoft Entra ID

Connect your Microsoft Entra ID integration and map access levels to Entra groups. Entra supports group-based provisioning only. Direct application assignment is not available through this integration.
1

Connect the Entra ID integration

Go to Settings > Integrations and configure your Microsoft Entra ID connection.
2

Map access levels

When creating an access level, select the corresponding Entra group from the dropdown.
3

Set the provisioning method

Choose Group. After approval, Ravenna adds the user to the mapped Entra group. No workflow is required.
The group grants an enterprise application only if it’s assigned to that app in Entra. Assigning groups to apps needs a Microsoft Entra ID P1 or P2 license, and only direct members count, not members of nested groups. Accounts in the app come from Entra’s provisioning service, if you’ve configured it for that app. It runs in cycles, so the account can appear some time after Ravenna adds the user. When provisioning is scoped to assigned users and groups, it disables the account after the user leaves the group.
Learn more about the Microsoft Entra ID integration

​
JumpCloud

Connect your JumpCloud integration and map access levels to JumpCloud user groups. JumpCloud supports group-based provisioning only. Applications import from JumpCloud, so you do not need to add them by hand.
1

Connect the JumpCloud integration

Go to Settings > Integrations and configure your JumpCloud connection. Users, groups, and applications begin syncing.
2

Map access levels

When creating an access level, select the corresponding JumpCloud user group from the dropdown.
3

Set the provisioning method

Choose Group. After approval, Ravenna adds the user to the mapped JumpCloud group. The user can sign in to the SSO applications bound to that group. Accounts in those applications come from the application’s SCIM connector or JIT provisioning, where you’ve set them up. No workflow is required.
Learn more about the JumpCloud integration

​
Cloudflare

Connect your Cloudflare integration and map access levels to Cloudflare Access groups. Cloudflare supports group-based provisioning only. Zero Trust applications import automatically.
1

Connect the Cloudflare integration

Go to Settings > Integrations and configure your Cloudflare connection. Applications, users, and Access groups begin syncing.
2

Map access levels

When creating an access level, select the corresponding Cloudflare Access group from the dropdown.
3

Set the provisioning method

Choose Group. After approval, Ravenna adds an email include rule for the user on the mapped Access group, and Cloudflare’s policies grant access on the user’s next login. Cloudflare Access controls who can reach the application. It doesn’t create an account inside it. No workflow is required.
Ravenna manages Cloudflare Access group membership through email include rules only. A group that grants access through an email domain, an everyone rule, or an identity provider rule reports no members in Ravenna, and provisioning into it still appends an email rule for the requester.
Learn more about the Cloudflare Access integration

​
OneLogin

Connect your OneLogin integration and map access levels to OneLogin groups or roles. Direct application assignment is not available through this integration, so of the automated methods only Group applies. Applications import from OneLogin, so you do not need to add them by hand.
1

Connect the OneLogin integration

Go to Settings > Integrations and configure your OneLogin connection. Users, groups, roles, and applications begin syncing.
2

Map access levels

When creating an access level, select the corresponding OneLogin entity from the dropdown. Groups appear under their own name and roles appear with a Role: prefix, so pick deliberately: the two provision differently.
3

Set the provisioning method

Choose Group. It covers both OneLogin groups and roles. After approval, Ravenna adds the user to the mapped group or assigns them the mapped role. The role or group decides which OneLogin apps the user can sign in to. Accounts in those apps come from each app’s provisioning setting in OneLogin, where it’s available and turned on. No workflow is required.
A OneLogin user can belong to only one group at a time. If a user already has a different group, a second group-mapped grant fails with USER_BELONGS_TO_DIFFERENT_PRIMARY_GROUP and changes nothing in OneLogin, rather than displacing the group they already have. If the group is the one they already hold, the entitlement is marked Skipped Provisioning instead. Map access levels to OneLogin roles when a user needs to hold several grants at once, because roles are additive.
Learn more about the OneLogin integration
Last modified on November 9, 2026