Skip to main content
Okta Identity Governance (OIG) sync brings the requestable access in your OIG catalog into Ravenna as access levels. Users request that access in Ravenna, and Ravenna files the request in OIG. OIG then runs its own approval and provisioning. Use it when OIG is the system of record for access approvals and you want users to request access from Ravenna.

​
Prerequisites

  • An Okta tenant with Okta Identity Governance and Access Requests enabled
  • The Okta integration connected with either setup method
  • Okta applications and groups already synced into Ravenna. Ravenna maps catalog entries to them, so entries for unsynced apps or groups are skipped until they sync.

​
Required scopes and role

OIG sync needs three scopes beyond the standard set, plus the Access Requests Administrator admin role on the app.
  • Client Secret: the Ravenna app from the Okta OIN marketplace sets up the scopes and the role for you, so there’s nothing to configure.
  • Private Key: grant the scopes on your Okta API service app alongside the standard scopes, then assign the role. In Okta, open the app under Applications > Applications, grant the scopes on the Okta API Scopes tab, and assign the role from the Admin roles tab with Edit assignments. The role also includes app assignment management.
The first three are required. Ravenna requests them together for every OIG call, so a missing one blocks the sync and requests alike. okta.accessRequests.condition.read is optional: without it, access levels still sync but who is eligible to request them isn’t.
OIG uses the v2 Access Requests API, which rejects the older okta.governance.accessRequests.* scope names. Grant the okta.accessRequests.* scopes listed above.
The governance scopes are optional for everything else. Ravenna checks for them only when OIG sync is turned on, and integrations that don’t use OIG keep working without them.

​
Turn on OIG sync

1

Grant the scopes and role

With Private Key, grant the three required okta.accessRequests.* scopes and assign the Access Requests Administrator role to your Okta API service app. Also grant okta.accessRequests.condition.read to turn on eligibility sync. With Client Secret, the installed app sets up the scopes and role, so skip this step. Its scopes can’t be changed, so if eligibility doesn’t sync, switch to Private Key to grant okta.accessRequests.condition.read.
2

Enable the setting

Go to Settings > Integrations, open the ⋯ menu on the Okta integration, and choose Configure. Turn on Sync OIG requestable access as access levels.
3

Run a sync

Choose Resync from the same ⋯ menu, or wait for the next scheduled sync (every 6 hours by default). If Ravenna can’t read the OIG catalog, the integration status turns yellow and its tooltip shows a Missing Okta Identity Governance access warning.

​
How the sync works

On each Okta sync, after groups sync, Ravenna reads the OIG catalog and turns every requestable entry into an access level. If the group sync fails, Ravenna skips the catalog for that run.
  • Application entries: an entry under an Okta application becomes an access level on the matching Ravenna application.
  • Group entries: an entry tied to an Okta group becomes an access level on each Ravenna application that group grants. Ravenna also maps the access level to that group. Entries for groups that grant no application are skipped.
Synced access levels use the External provisioning method and an External access policy. Okta owns both, so they’re read-only in Ravenna. The access level shows what came from Okta: who is eligible to request it and, for group-scoped entries, the group it provisions into. Whether a request needs approval in Ravenna before it’s filed in OIG is copied from your default access policy when the level is first synced. See eligibility sync. When an entry leaves the OIG catalog, Ravenna archives its access level. If the entry returns, Ravenna unarchives it. A level isn’t archived while its Okta application or group is still waiting to sync into Ravenna.
Turning the setting off stops the catalog sync, but access levels it already created stay active. Requests for them are still filed in OIG.

​
Eligibility sync

On each sync, Ravenna copies your OIG request conditions onto every external access level’s External access policy. Who can request a level in Ravenna then matches who can request it in OIG, so users don’t file requests OIG will refuse. The sync owns these policy settings: The first time Ravenna moves a level onto an External policy, it copies the level’s current policy, including whether a request needs approval in Ravenna before it’s filed in OIG. A new level starts from a copy of your default access policy. After that, the approval settings aren’t editable on the level. On external levels, the access level form shows Access Policy as External and Eligible Groups locked, and hides the other policy settings. You can’t change an external level’s policy, including with the bulk Set Policy action. Eligibility sync needs the optional okta.accessRequests.condition.read scope. Without it, levels still move to an External policy with no expiry, but their eligible groups aren’t synced. The sync status reports Request conditions could not be read: grant okta.accessRequests.condition.read to sync eligibility. Ravenna leaves a level’s eligible groups as they were when it can’t fully resolve them. This happens when:
  • A requester group in the OIG condition hasn’t synced into Ravenna yet
  • No active request condition covers the catalog entry
  • The condition uses a requester type other than Everyone or groups
  • The entry is owned by a group rather than an Okta application
Ravenna never opens a level to everyone because it couldn’t read OIG. OIG still checks its own conditions when Ravenna files the request.
Learn more about external access levels

​
How requests work

1

The user requests access in Ravenna

The user picks an external access level, and the request goes through the level’s access policy.
2

Ravenna files the request in OIG

After the request is approved in Ravenna, Ravenna files an OIG access request for the requester against the matching catalog entry.
3

OIG approves and provisions

OIG runs its own approval and provisioning. Ravenna marks the entitlement and the access request Submitted, closes the ticket, and tells the requester their request was forwarded. The ticket timeline shows that Ravenna submitted the access request to the connected system. For group-based levels, the new group membership appears in Ravenna on the next Okta sync.
Ravenna doesn’t follow the OIG request after filing it. Track approval in Okta. If OIG denies the request or it expires, the entitlement stays Submitted in Ravenna. A submitted request can still be withdrawn. When Ravenna revokes a submitted entitlement, or any entitlement that was filed with OIG, it cancels the matching OIG access request. Canceling the request doesn’t remove access OIG has already granted, so remove that access in Okta.
Ravenna files each request as a self-request for the requester. If provisioning retries, Ravenna reuses the request it already filed instead of filing a new one.

​
Troubleshooting

Cause: Ravenna’s connection check couldn’t read the OIG catalog. Usually a scope or the role is missing on the app.Solution:
  • With Private Key, grant okta.accessRequests.catalog.read, okta.accessRequests.request.read, and okta.accessRequests.request.manage on the app, and assign the Access Requests Administrator role
  • With Client Secret, confirm OIG and Access Requests are enabled in your Okta tenant. The app includes the scopes and role, so contact Ravenna support if the warning persists.
  • Choose Resync from the ⋯ menu on the Okta integration
Behavior: The check only reads the catalog. If the catalog syncs but requests fail, check that a Private Key app has okta.accessRequests.request.manage and the role.
Cause: Ravenna couldn’t match the entry to a synced application or group, or the entry isn’t requestable.Solution:
  • Confirm the entry is requestable in OIG
  • Confirm the Okta application or group behind it has synced into Ravenna
  • For group entries, confirm the group grants at least one application
  • Run another sync after the application or group appears in Ravenna
Cause: Ravenna couldn’t file the request in OIG. Most often the requester has no Okta user linked in Ravenna, or the app is missing okta.accessRequests.request.manage.Solution:
  • Confirm the requester has an Okta user and that it has synced into Ravenna
  • With Private Key, confirm the app has all three okta.accessRequests.* scopes and the Access Requests Administrator role
  • Submit the request again once both are in place
Cause: Ravenna couldn’t read the OIG request conditions or couldn’t fully resolve them, so it kept the level’s previous eligible groups.Solution:
  • Check the Okta integration’s sync status for Request conditions could not be read. With Private Key, grant okta.accessRequests.condition.read on the app.
  • Confirm every requester group in the OIG request condition has synced into Ravenna
  • Confirm an active request condition covers the catalog entry
  • Choose Resync from the ⋯ menu on the Okta integration
Cause: Ravenna filed the request, and OIG still owns approval and provisioning. Ravenna doesn’t reflect OIG approvals, denials, or expirations.Solution:
  • Find the request in OIG Access Requests and check its status
  • For group-based levels, run a sync after OIG grants access so the membership shows in Ravenna
Last modified on October 14, 2026