Skip to main content
This page walks through connecting Okta to Oleria from a blank slate: creating the Okta app, wiring up single sign-on (SSO), and turning on directory provisioning (SCIM), for whichever combination of Main Workspace and Governance App you need. It draws on SSO configuration, SCIM user provisioning, and Governance App SCIM provisioning - see those pages for the full request/response reference and troubleshooting detail; this page focuses on getting from zero to a working Okta connection.
This page is about signing in to Oleria and provisioning Oleria accounts from Okta. It is not the same as the Okta integration under Integrations, which connects Okta as a data source so Oleria can analyze your Okta tenant’s identities and access. That integration does not affect who can sign in to Oleria or how.

​
Overview

​
Main Workspace vs. Governance App

Oleria has two independent surfaces, each with its own sign-in and provisioning configuration:
  • Main Workspace - where administrators, operators, and analysts run Oleria itself: posture, access graph, workflows, and settings.
  • Governance App - a separate portal where reviewers and approvers complete access reviews, act on access requests, and work governance queues. Governance app users are a distinct population from workspace users, typically much larger (anyone in the org who might approve or review something), and usually don’t need any other access to Oleria.
Each surface has its own tab in Settings → SSO Configuration and its own tab in Settings → SCIM Configuration, with separate identity provider lists, separate SCIM credentials, and separate SCIM base URLs. You can connect Okta to one, the other, or both - they don’t have to match. For example, it’s common to enable SSO and SCIM for the Governance App (so every employee can be provisioned as a reviewer automatically) while managing the smaller set of Main Workspace administrators by hand.

​
SSO vs. SCIM vs. automatic user provisioning

Oleria has three related but independent mechanisms. SSO is for authentication only, where as SCIM and automatic user provisioning are for provisioning. See Automatically provision reviewers for the full detail on that setting - Part 2 of this page is about SCIM, not automatic user provisioning.

​
Possible provisioning flows

Because these mechanisms are independent, and each applies per workspace, several combinations are all valid. Pick the one that matches what you’re trying to achieve before you start: This page sets up the recommended SSO + SCIM flow, one workspace at a time. If you’d rather use automatic user provisioning instead of SCIM for the Governance App, see the note at the end of Part 2.

​
Prerequisites

  • Administrator access to your Oleria workspace
  • Okta super admin access - Okta’s own guidance for enabling SCIM on a custom app is to sign in as a super admin, and lesser admin roles may not see the setting.
  • Decide which workspaces - Main Workspace, Governance App, or both - you’re connecting Okta to, and whether you want SSO, SCIM, or both for each. See Possible provisioning flows above.
  • For SCIM only: your Okta org must have Okta Lifecycle Management (LCM) entitlements. LCM is a separate Okta product from SSO, and without it the Provisioning setting never appears on the app. Check this before you start - it’s the most common reason this setup can’t be completed. See Okta Lifecycle Management is required for SCIM below. SSO (Part 1) does not require LCM.
  • For SCIM into the Main Workspace: know which Oleria roles (admin, operator, analyst, governance-operator, identity-lifecycle-operator) your Okta groups should map to. See How Oleria maps roles and groups.

​
Part 1: Set up SSO

1

Open Oleria's SSO configuration page

In Oleria, go to Settings → SSO Configuration, select the Main Workspace or Governance App tab depending on which application you’re connecting first, and click Add IdP in the SAML IdP card.
2

Create the Okta app

In the Okta Admin Console, go to Applications → Applications → Create App Integration, select Classic experience since Integration Wizard is not supported at this time. Select SAML 2.0, and name it something that identifies which Oleria workspace it’s for (for example Oleria - Main Workspace or Oleria - Governance App) - this matters once you’ve done this twice for both workspaces.Image of the Integration Wizard vs Classic experience prompt
3

Copy Oleria's SP details into Okta

On Oleria’s Oleria details step, copy the Entity ID and ACS URL. On Okta’s Configure SAML step, enter them as the Audience URI (SP Entity ID) and Single sign-on URL. Copy or download the Request signing certificate shown on Oleria’s Oleria details step - you’ll need it later in this Part if you turn on Sign requests.Image of Okta's Configure SAML page
4

Configure the NameID

Still on Configure SAML, set Name ID format to Persistent and Application username to Email.
Application username is also the value Okta sends as userName when you add SCIM in Part 2, so leave it on Email rather than Okta username or a custom expression. Oleria identifies an account by one email address, and Okta’s matching queries look that address up by userName. If Application username resolves to something other than the user’s email - a user.login on a different domain, say - then userName and the provisioned emails value disagree, Okta can’t find the account it created, and it retries the create on every sync. Keep Application username, the app’s email attribute mapping, and the email attribute statement in the next step all pointing at the user’s email.
5

Add the required attribute statements

This step is on a different page than the previous one for most Okta orgs today. On Okta Identity Engine (OIE) orgs - the default for new orgs - Attribute Statements aren’t part of the Configure SAML page at all; add them afterward on the app’s Sign On tab, under Attribute Statements. Only on legacy Okta Classic Engine orgs do they appear further down the same Configure SAML page.
Add an attribute statement Name email, Name format Unspecified, Value user.profile.email, and a second Name name, Name format Unspecified, Value user.profile.firstName + " " + user.profile.lastName.Image of Okta's Sign On tab with Attribute Statements sectionSee Connect a SAML identity provider for why each of these is required.
6

Assign users

Assign the app to the users or groups who should be able to sign in to Oleria.
7

Enter the SAML IdP details in Oleria

On the Sign On tab copy the Identity Provider metadata URL. Back in Oleria, complete the SAML IdP details step: give the identity provider a Name, paste the Okta metadata URL into Metadata, and decide whether to turn on Sign requests and/or Encrypt SAML responses. Click Add identity provider.
8

If you turned on Sign requests: upload the request signing certificate to Okta

Skip this step if you left Sign requests off. Otherwise, go back to the Okta app’s General tab, open SAML Settings → Edit, and click Show Advanced Settings. Upload Oleria’s Request signing certificate (downloaded in pem format earlier in this Part) next to Signature Certificate, then set Signed Requests to Validate SAML requests with signature certificates.Image of Okta's SAML Settings advanced settings with Signature Certificate upload
9

If you turned on Encrypt SAML responses: download and upload the response encryption certificate

Skip this step if you left Encrypt SAML responses off. Otherwise, back in Oleria you’ll see a prompt to download the Response encryption certificate generated specifically for this identity provider - download it in pem format. In Okta, in that same Show Advanced Settings view, set Assertion Encryption to Encrypted and upload the certificate next to Encryption Certificate.Before:Image of Okta's SAML Settings advanced settings before setting Assertion Encryption to EncryptedAfter:Image of Okta's SAML Settings advanced settings after setting Assertion Encryption to Encrypted
10

Confirm sign-in works

Sign out of Oleria, go to https://www.oleria.com/sign-in, select the new identity provider, and confirm you land back in Oleria signed in.

​
Part 2: Set up SCIM

You can add SCIM provisioning to the same Okta app you just created for SSO - Okta supports provisioning on custom SAML apps once you turn it on, provided your org is licensed for it.

​
Okta Lifecycle Management is required for SCIM

Outbound SCIM provisioning is part of Okta Lifecycle Management (LCM), a separate Okta product from SSO. If your org isn’t entitled to LCM, the Provisioning setting simply isn’t rendered: the App Settings dialog shows only Application label, Application visibility, Auto-launch, and the two notes fields, with no Provisioning options to select. Nothing is greyed out, so it reads as though the setting doesn’t exist.LCM is included in Okta’s Essentials, Professional, and Enterprise suites and in the Okta Identity Governance add-on. It is not included in the Starter or Core Essentials plans, where it’s a paid add-on.Quickest way to check: in the Okta Admin Console, look at any other app in your org that should provision users (for example a directory app like Google Workspace). If no app in the org has a working Provisioning tab, your org doesn’t have LCM. Your Okta account team can confirm whether it’s in your contract or needs to be added.If you can’t add LCM, Oleria still has working options - see Alternatives without Lifecycle Management.
1

Enable provisioning on the Okta app

Image showing the expected Provisioning radio group in App SettingsOpen the same Okta app from Part 1. On the General tab, click Edit next to App Settings, then set Provisioning to SCIM - some Okta orgs show this as a Enable SCIM provisioning checkbox instead of a radio group - and click Save. A new Provisioning tab appears on the app.
No Provisioning setting in the dialog? The most likely cause is that your org isn’t entitled to LCM, as described above. Two other causes: the app is an OIDC integration rather than SAML 2.0 or SWA (Okta doesn’t support SCIM on custom OIDC apps created in the Classic experience), or the app was created through the Okta API or Terraform rather than the Admin Console, which can leave the provisioning options absent or unconfigurable. If the app is a SAML 2.0 app created in the Admin Console and your org does have LCM, contact Okta Support to check whether the provisioning feature needs activating for your org.
2

Get Oleria's SCIM credentials

In Oleria, go to Settings → SCIM Configuration and select the same workspace you used in Part 1 (Main Workspace or Governance App). Copy the SCIM Base URL, Client ID, Client Secret, and OAuth Token URL.
3

Configure the API integration

On the Okta app’s Provisioning tab, select Integration, click Edit. Enter Oleria’s SCIM Base URL as the SCIM connector base URL, for unique identifier enter userName, and check Push New Users, Push Profile Updates, and Push Groups. Set Authentication Mode to OAuth 2, under OAuth 2 set Grant Type to Client Credentials, and enter Oleria’s OAuth Token URL as the access token endpoint along with the Client ID and Client Secret you copied.
Oleria’s SCIM API only issues short-lived tokens through this client credentials exchange - it does not accept a single, static, long-lived bearer token. Use OAuth 2 / Client Credentials here, not the HTTP Header (bearer token) authentication mode. Okta mints and automatically refreshes its own token from the Client ID and Client Secret, so there’s nothing to manually re-enter later. See Authenticate to the SCIM API for how this same OAuth 2.0 Client Credentials flow works if you’re ever calling the API directly instead of through Okta.
Image of Okta's SCIM connection settings
4

Turn on the provisioning actions you need

Under Provisioning → To App, click Edit and enable Create Users, Update User Attributes, and Deactivate Users.
5

Confirm userName and email carry the same address

Still under Provisioning → To App, scroll to Oleria Attribute Mappings and confirm the app’s email attribute maps to Okta’s user.email, which is the default. Combined with Application username set to Email in Part 1, that makes userName and emails carry the same address - which is what Oleria stores and what Okta’s matching queries search on.Okta requires an email on every user, so there’s no fallback to configure here. The two ways this drifts are changing Application username away from Email, and remapping email to something other than user.email; either one leaves the two values disagreeing for some users, which shows up as repeated create attempts for users who already exist in Oleria.
6

Main Workspace only: push groups from Okta

Main Workspace only: Oleria grants roles through group membership, not directly on the user (see How Oleria maps roles and groups).Governance App: there is no group-to-role mapping to configure - every provisioned user is assigned the single reviewer role automatically. You only need users pushed, not groups.
In Okta, go to the app’s Push Groups tab and push each Okta group whose members should get Oleria access. Okta then creates the matching group in Oleria automatically via SCIM, with membership synced, but without a role set. Okta’s Push Groups doesn’t support mapping a role or any other custom attribute onto the group it creates, so a newly-created group falls back to Oleria’s read-only analyst role until you assign it a different one in the next step.
7

Main Workspace only: assign each group a role in Oleria

In Oleria, under Settings open Manage Users, select the Groups tab, and for each group you push, select it, click Change role, choose the role it should map to, and click Save. Every current and future member of the group inherits that role. See Assign a role to a group for the full walkthrough.Oleria’s Manage Users page:Image of Oleria's Manage Users page on Groups tabThe detail page for a particular group:Image of a particular group's detail pageChanging the role mapping for that group:Image of the Change role dialog
8

Assign and provision

Assign the users or groups who should get Oleria accounts to the app (Main Workspace: via the groups you just pushed; Governance App: directly, or via any group). Okta provisions matching users into Oleria within its usual sync interval.
9

Verify

In Oleria, confirm the new users appear (Main Workspace: in Manage Users with the expected role; Governance App: in the governance reviewer list). Deactivate or unassign a test user in Okta and confirm they lose access in Oleria.
Alternative for the Governance App: if you don’t need directory-driven deprovisioning and don’t want to build the Okta provisioning connector above, you can skip this Part entirely and use Oleria’s built-in automatic user provisioning instead - it only requires SSO (Part 1) to already be working. Follow Automatically provision reviewers to enable it and set allowed email domains. Remember this is not SCIM: it only creates accounts on sign-in and never deactivates them, so it’s not a substitute for SCIM if you need automatic offboarding.

​
Alternatives without Lifecycle Management

If your Okta org isn’t entitled to LCM and adding it isn’t an option, you can still get most of the way there. What’s available depends on which workspace you’re provisioning.
There is no way to work around the LCM requirement from inside Okta. In particular, adding one of the generic SCIM 2.0 Test App integrations from the Okta Integration Network doesn’t help: LCM gates the Provisioning tab on catalog apps exactly as it does on custom apps, and those test apps authenticate with a static bearer token or basic auth rather than the OAuth 2.0 Client Credentials flow Oleria’s SCIM API expects. Okta Workflows is not a workaround either - it’s licensed as part of Lifecycle Management and Okta Identity Governance.
A common split is automatic user provisioning for the Governance App reviewer population plus hand-managed Main Workspace admins - that combination needs only SSO, and no LCM.

​
Set up the second workspace

Okta has no restriction on reusing the same Audience URI (SP Entity ID) or SCIM base URL pattern across multiple apps, so connecting the second workspace is simply repeating Part 1 and Part 2 with a second, separately-named Okta app pointed at the second workspace’s Oleria details and SCIM credentials. You do not need to reuse or share anything between the two Okta apps.

​
FAQ

​
Okta and identity provider basics

Okta is a cloud identity service. It holds your organization’s user accounts and groups, and it’s what your people authenticate against when they open the Okta dashboard or any application your organization has connected to it.Connecting it to Oleria means those same work accounts sign in to Oleria, and, once SCIM is on, that Okta decides who has an Oleria account at all.Where those accounts originate doesn’t matter to Oleria. Okta’s Universal Directory may hold them natively, or they may be synced in from on-premises Active Directory or an HR system. Oleria only ever talks to Okta, so the accounts, groups, and attributes it sees are the ones that exist in Okta.
An identity provider (IdP) is the system that holds user accounts and vouches for who someone is. A service provider (SP) is the application the person is trying to reach, which trusts the identity provider instead of storing passwords itself. In this setup, Okta is the identity provider and Oleria is the service provider.A SAML sign-in runs like this:
  1. The user opens Oleria’s sign-in page and selects your identity provider.
  2. Oleria redirects their browser to Okta, which authenticates them with whatever your org requires (password, MFA, sign-on policies).
  3. Okta sends the browser back to Oleria’s ACS URL carrying a digitally signed SAML assertion that says who the user is.
  4. Oleria checks the signature against the certificate in the metadata you gave it, and signs the user in.
Oleria never sees the user’s Okta password, and it can’t sign anyone in that Okta hasn’t vouched for.
They are Oleria’s two identifiers in the SAML handshake, and you paste both into Okta’s Configure SAML step:
  • Entity ID (Okta calls it Audience URI (SP Entity ID)) - the unique name of Oleria as a service provider. It’s a name, not a page you can open. Okta includes it in the assertion so Oleria can confirm the assertion was meant for it.
  • ACS URL (Okta calls it Single sign-on URL) - the Assertion Consumer Service URL, the exact address Okta posts the signed assertion to. It has to match character for character.
Your org is your organization’s own instance of Okta: your users, your groups, your applications. It has a URL like https://acme.okta.com, which is where end users land, and an Admin Console at https://acme-admin.okta.com. From the end-user dashboard you can also reach it with the Admin button. Everything on this page happens in the Admin Console, under Applications → Applications.Many organizations also have a preview org, usually https://acme.oktapreview.com, that mirrors production. It’s a good place to walk through this setup once before doing it for real, as long as you point it at a matching Oleria workspace.
An app integration is the object in your org that represents an outside application your people use, along with the settings for how sign-in and provisioning work with it. Creating one doesn’t install anything; it records that your org trusts that application and who is allowed to use it.The Okta Integration Network (OIN) is Okta’s catalog of applications with the SAML and SCIM fields pre-filled. Oleria isn’t in the OIN, so you create a custom SAML 2.0 app integration and fill in the URLs and attribute statements yourself, which is what Part 1 walks through.When Okta offers a choice between the Integration Wizard and the Classic experience while creating it, choose Classic experience. The Integration Wizard is not supported for this setup at this time.
They are two generations of Okta’s underlying authentication engine. Identity Engine (OIE) is the default for new orgs and for most orgs today; Classic Engine is the older one some long-standing orgs still run.It matters here for one reason: on Identity Engine, attribute statements aren’t part of the Configure SAML page, and you add them afterward on the app’s Sign On tab under Attribute Statements. On Classic Engine they appear further down the Configure SAML page itself. Same result, different page.To check which you’re on, look at the Okta version number in the Admin Console footer. A version ending in E, such as 2026.02.0 E, means Identity Engine.
An attribute statement is one fact about the signed-in user that Okta includes in the SAML assertion. Oleria needs three things in total:
  • Name ID format set to Persistent. Application username decides what value goes into it; this setup uses Email.
  • Two attribute statements named exactly email and name, both with Name format Unspecified. Unspecified is what keeps the names arriving as plain email and name rather than wrapped in a namespace URI, which is what Oleria looks for.
If any of the three is missing or shaped differently, Oleria rejects the sign-in.
Use a super admin account. Okta’s own guidance for enabling SCIM provisioning on a custom app is to sign in as a super admin, and narrower roles such as application administrator may not render the Provisioning setting at all, which looks identical to not being licensed for it.If a section described here is missing or read-only for you, check the admin role you signed in with before assuming it’s a licensing problem, then check Okta Lifecycle Management is required for SCIM.
Outbound SCIM provisioning is part of Okta Lifecycle Management (LCM), which is licensed separately from SSO. The quickest check is to open any other app in your org that provisions users, such as a directory app, and look for a working Provisioning tab. If no app in the org has one, your org doesn’t have LCM.Okta Lifecycle Management is required for SCIM covers which Okta plans include it, and Alternatives without Lifecycle Management covers what to do if adding it isn’t an option. SSO in Part 1 needs no LCM.
Assignment, on the app’s Assignments tab, controls who is allowed to use the app: who can sign in through it, and, once provisioning is on, who Okta pushes to Oleria.With SSO alone, assignment creates nothing in Oleria. An assigned user who has no Oleria account can complete the Okta half of the sign-in and still be denied, until an account exists for them through SCIM, automatic user provisioning, or Manage Users. With SCIM and Create Users enabled, assigning someone is what triggers Okta to create their Oleria account.
Outbound provisioning is event-driven rather than scheduled. When you assign someone, change their profile, or deactivate them, Okta pushes that change to Oleria as it happens, usually within a minute or two, and retries on failure. There’s no sync cycle to wait for the way there is with a scheduled directory import.Group membership is the exception worth knowing: use Push now on the app’s Push Groups tab to force a group and its membership through immediately instead of waiting for the next change to trigger it.
Two places, and picking the right one saves time:
  • Reports → System Log for everything. Filter by the Oleria app to see both sign-in events and provisioning events, including the error Oleria returned when it refused a SCIM request.
  • The Admin Console’s Tasks page, where Okta collects provisioning actions that failed and need attention, so a broken push doesn’t only live in the log.
Okta’s log is almost always more specific about a SAML failure than what the user sees in the browser. Check it first when a sign-in doesn’t work.
No. Provisioning is a one-way push from Okta into Oleria: Okta creates, updates, and deactivates Oleria accounts, and Oleria never writes back into your directory. SSO doesn’t change how anyone authenticates to Okta; it only lets Oleria accept the result.Deleting the app integration later stops both sign-in and provisioning. It doesn’t remove the Oleria accounts that already exist, so remove those in Manage Users if you need them gone.This is also why the Okta integration under Integrations is a separate thing: that one reads your org so Oleria can analyze it, and it has no bearing on who can sign in.

​
Sign-in troubleshooting

The person isn’t assigned to the app integration. Open the app’s Assignments tab and add them, or add a group they belong to. Okta blocks everyone else by design, which is what makes assignment your access control for Oleria sign-in.
The Single sign-on URL or Audience URI (SP Entity ID) in Okta doesn’t exactly match Oleria’s ACS URL and Entity ID. Trailing slashes, http instead of https, and a truncated paste all count as a mismatch. Re-copy both values from Settings → SSO Configuration in Oleria and paste them again on the app’s Configure SAML step.
Authentication succeeded and the content of the assertion is the problem. Check, in this order:
  1. Name ID format is Persistent, with Application username set to Email.
  2. Attribute statements named exactly email and name exist, both with Name format Unspecified.
  3. If you turned on Sign requests, Oleria’s request signing certificate is uploaded to Okta under Signature Certificate, and Signed Requests is set to Validate SAML requests with signature certificates.
  4. If you turned on Encrypt SAML responses, Assertion Encryption is set to Encrypted and Oleria’s response encryption certificate is uploaded next to Encryption Certificate.
Troubleshoot sign-in failures covers the certificate cases in more detail.
Your org is on Okta Identity Engine, where attribute statements live on the app’s Sign On tab under Attribute Statements rather than on Configure SAML. Finish the SAML configuration, then add them there. Only legacy Classic Engine orgs show them on the Configure SAML page.
Sign-in worked and the person has no Oleria account, or has one that’s been deactivated. SSO authenticates people; it never creates accounts. Depending on the workspace:
  • Main Workspace - the account has to come from SCIM or from Manage Users.
  • Governance App - the same, unless you turn on automatic user provisioning and add the person’s email domain to the allowed list.
If you pasted metadata XML instead of a URL when you first set the identity provider up, then the certificate provided in the metadata may have expired or been rotated. The XML is a snapshot rather than a live document, so changes to it are not captured by Oleria automatically. Get fresh metadata from the app’s Sign On tab, then open the provider in Settings → SSO Configuration, edit it, and save the Identity Provider metadata XML again.
The SAML email attribute statement resolves to a different address than the one SCIM provisioned, so Oleria can’t match the sign-in to the existing account. All three have to point at the same address: the email attribute statement on the Sign On tab, Application username, and the app’s email attribute mapping under Provisioning → To App. See Confirm userName and email carry the same address.
This is an Oleria-side validation failure rather than an Okta problem: the metadata URL is unreachable, the name is already taken, or the metadata XML is incomplete. Oleria names the specific reason in the error it shows. See Troubleshoot identity provider errors for every message and what to do about each.
Two Okta tools are useful while you configure: Preview the SAML Assertion on the Configure SAML step shows the exact assertion Okta will send, which is the fastest way to confirm the NameID format and the email and name attribute names without signing anyone in. The System Log shows what Okta thought happened on a real attempt.Treat signing in at https://www.oleria.com/sign-in as the real test, because that’s the service-provider-initiated flow your users actually take. Launching the app from the Okta dashboard tile is a different, identity-provider-initiated flow.

​
Provisioning troubleshooting

In most cases your org isn’t entitled to Okta Lifecycle Management, and Okta renders no Provisioning options at all rather than greying them out. See Okta Lifecycle Management is required for SCIM, and Alternatives without Lifecycle Management if you can’t add it.Two other causes worth ruling out: you’re signed in with an admin role narrower than super admin, or the app was created through the Okta API or Terraform rather than the Admin Console, which can leave the provisioning options absent.
Work through the integration fields in order:
  • SCIM connector base URL is Oleria’s SCIM Base URL, not Oleria’s sign-in address.
  • Unique identifier is userName.
  • Authentication Mode is OAuth 2 with Grant Type set to Client Credentials, not HTTP Header. Oleria’s SCIM API only issues short-lived tokens through this exchange and never accepts a static bearer token.
  • The access token endpoint is Oleria’s OAuth Token URL.
  • Client ID and Client Secret are pasted whole, with no leading or trailing spaces.
Confirm you copied all four values from the correct tab of Settings → SCIM Configuration. The Main Workspace and Governance App have separate credentials and separate base URLs, and using one workspace’s secret against the other’s URL fails here.
In rough order of likelihood:
  • Create Users isn’t enabled under Provisioning → To App. Turning on SCIM doesn’t enable the individual provisioning actions.
  • Nobody is assigned to the app on the Assignments tab.
  • You pushed a group under Push Groups but never assigned it. Pushing a group creates the group in Oleria; assignment is what provisions the people in it. They’re separate actions on separate tabs.
  • The push failed and is waiting in the Admin Console’s Tasks page, or recorded as an error in Reports → System Log.
Three causes, all common:
  • Push Groups wasn’t checked in the app’s Provisioning → Integration settings, so Okta never pushes groups at all.
  • The group hasn’t been added on the Push Groups tab. Okta pushes only the groups you list there, one at a time, not every group in the org.
  • Group provisioning requires Lifecycle Management, exactly as user provisioning does. See Okta Lifecycle Management is required for SCIM.
Use Push now on the Push Groups tab to force an immediate push once the setup is right.
Oleria grants roles through group membership, never on the user record, and Okta’s Push Groups can’t set a role on the group it creates. Until you map it, its members fall back to Oleria’s read-only analyst role.In Oleria, go to Settings → Manage Users, select the Groups tab, select the group, click Change role, and choose the role it should grant. Every current and future member inherits it. See How Oleria maps roles and groups.This doesn’t apply to the Governance App, where every provisioned user gets the reviewer role automatically.
Deactivate Users has to be enabled under Provisioning → To App. Without it, Okta pushes creates and updates but never tells Oleria to disable anyone, so unassigning someone in Okta silently leaves their Oleria account active.With it enabled, the change travels within a minute or two. Confirm it in Reports → System Log, then in Manage Users. If nothing happened, check that the person was removed from every group assigned to the app, not just one.
Okta sends the app username as userName, and the app username format is set per app. If your users arrive in Oleria identified by their Okta username rather than their email, set Application username to Email on the app’s Sign On tab, which also keeps SSO and SCIM identifying people the same way.For any other attribute that arrives wrong, check the profile mappings under Provisioning → To App, then push one affected user again rather than waiting for their next change.
Okta matches existing users on userName. If the address Okta sends as userName doesn’t match the one Oleria stored, Okta can’t find the account it already created and tries to create it again, which Oleria rejects as a duplicate.Confirm Application username is Email and that the app’s email attribute maps to user.email, so userName and emails agree. See Confirm userName and email carry the same address.
For the request and response shape of every SCIM endpoint, see the SCIM user provisioning and Governance App SCIM provisioning reference pages.

​
Contact us

For questions, contact us at support@oleria.com.