Skip to main content
This page walks through connecting Microsoft Entra ID to Oleria from a blank slate: creating the enterprise application, 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 Entra connection, and on one Entra-specific wrinkle that complicates connecting both the Main Workspace and Governance App to the same Entra tenant.
This page is about signing in to Oleria and provisioning Oleria accounts from Entra ID. It is not the same as the Microsoft Entra ID integration under Integrations, which connects Entra as a read-only data source so Oleria can analyze your Entra tenant’s identities and access - that integration doesn’t 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 Entra to either, or both. Critically for Entra specifically: both tabs share the same Oleria service provider - the same Entity ID and the same ACS URL - see Entra’s one-app-per-Entity-ID rule below before you create a second Entra app.

​
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 (Main Workspace vs Governance App), 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. If you’d rather use automatic user provisioning instead of SCIM for the Governance App, see the note at the end of Part 2. If you need both Oleria workspaces connected to Entra, read the next section before creating a second enterprise application.

​
Entra’s one-app-per-Entity-ID rule

Microsoft Entra requires every SAML relying party - every enterprise application configured for SAML SSO - to have a unique Entity ID (Identifier) within the tenant:
“There cannot be two applications in a single Microsoft Entra tenant with the same entity identifier.” - Microsoft Learn
Entra enforces this because it uses the Entity ID to work out which application should receive a given SAML response; without a unique identifier per app, it can’t disambiguate. This is sometimes described as one Entity ID per “relying party trust” (RPT) - that’s not a separate object you configure, it’s just what Entra calls an application once it’s set up for SAML SSO. Every enterprise app with SAML SSO configured is a relying party trust; there’s no way to do SAML SSO without one, and no way around the uniqueness rule by avoiding the term. This collides with Oleria’s design: as the SSO configuration page notes, the Main Workspace and Governance App tabs show the same Entity ID and ACS URL, because they share one Oleria service provider. If you create two separate Entra enterprise apps - one per Oleria workspace - both need Oleria’s Entity ID, and Entra will reject the second one with an error like “please enter an identifier which is unique within your organization.” The fix: use a single Entra enterprise application for both workspaces, rather than creating two. Complete Part 1 once to create that one app, then when you reach the SSO Configuration Governance App tab in Oleria, add its identity provider using the same Entra app’s federation metadata URL instead of creating a second app. One Entra app, one Entity ID, satisfies Entra’s rule, and both Oleria workspaces get a working IdP.
A single shared Entra app means the same set of assigned Entra users/groups can sign in through either workspace - Entra assignment doesn’t distinguish which Oleria workspace a sign-in is destined for, since that’s determined by which button the user selects on Oleria’s own sign-in page. If you need a genuinely different population gated at the identity provider for each workspace, don’t reuse one Entra app; instead, connect Entra to only one workspace and use a different IdP, or manual provisioning, for the other.

​
Prerequisites

  • Administrator access to your Oleria workspace, and Global Administrator (or equivalent) access in Entra to create and configure enterprise applications.
  • Decide which workspace(s) - Main Workspace, Governance App, or both - you’re connecting Entra to, and whether you want SSO, SCIM, or both for each. See Possible provisioning flows above.
  • For SCIM into the Main Workspace: know which Oleria roles (admin, operator, analyst, governance-operator, identity-lifecycle-operator) your Entra groups should map to. See How Oleria maps roles and groups.
  • For SCIM: a Microsoft Entra ID P1 or P2 license. Automatic provisioning is a premium Entra feature, and provisioning groups - which is how the Main Workspace grants roles - requires P1 at minimum. Check this before you start. See Entra ID P1 or P2 is required for SCIM below. SSO (Part 1) works on Entra ID Free, except for token encryption, which also needs P1 or P2.

​
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 one you’re connecting first, and click Add IdP in the SAML IdP card.
2

Create the Entra enterprise application

In the Microsoft Entra admin center, go to Entra ID → Enterprise applications → New application → Create your own application, select Non-gallery application, and name it something that identifies it as the Oleria connection (for example Oleria) - if you plan to share this one app across both workspace, avoid naming it after just one workspace.
3

Copy Oleria's SP details into Entra

On Oleria’s Oleria details step, copy the Entity ID and ACS URL. In the Entra app, select Single sign-on → SAML → Basic SAML Configuration, and enter them as the Identifier and Reply URL. Click Save and close the panel.Navigation:Image showing navigation to Basic SAML Configuration in EntraBasic SAML Configuration panel:Image showing Basic SAML Configuration panel in Entra
4

Configure the NameID and required claims

In Attributes & Claims:
  • Edit the Unique User Identifier (Name ID) claim, set Name identifier format to Persistent, and set the Source attribute to user.objectid (or another stable, opaque identifier).
  • Add a new claim named email with source attribute user.mail, and another named name with source attribute user.displayname. Leave Namespace blank on both - Oleria requires these two exact, short claim names.
  • If some users have no mail value, add a Claim transformation to the email claim: source user.mail, transformation IfEmpty, parameter user.userprincipalname. That way every user gets an address in the claim.
Image showing Attributes & Claims in EntraSee Enter the SAML IdP details for why each of these is required.
Use the same email attribute here and in SCIM. Oleria identifies an account by its email address, so the value in this email claim has to match the address SCIM provisions for that user (Part 2, where the same attribute goes to both userName and emails). If sign-in presents one address and SCIM provisioned another, the signed-in user won’t match their provisioned account, and a user who signs in before SCIM reaches them can end up with a second account. Pick one attribute - mail, falling back to userPrincipalName when it’s empty - and use it in all three places.
5

Assign users and grab the metadata

Assign the users or groups who should be able to sign in through Oleria to the app, then in SAML Certificates, copy the App Federation Metadata Url.
6

Enter the SAML IdP details in Oleria

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

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

Skip this step if you left Sign requests off. Otherwise, in the Entra app’s SAML Certificates section, click Edit across from Verification certificates, check Require verification certificates, and upload Oleria’s Request signing certificate, downloaded in cer format earlier in this Part.Image showing SAML Signing Certificate pannel in Entra
8

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

Skip this step if you turned off Encrypt SAML responses in the Oleria SAML Configuration page.Back in Oleria you’ll see a prompt to download the Response encryption certificate generated specifically for this identity provider - download it in cer format. In Entra, open the app’s Token encryption page (a separate page from SAML Certificates - requires a Microsoft Entra ID P1 or P2 license), select Import Certificate, upload the certificate, then activate it from the … menu next to the imported certificate.Image showing Token encryption page in Entra
9

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

​
Entra ID P1 or P2 is required for SCIM

Automatic provisioning is a premium Entra capability: Microsoft’s licensing reference lists automated user provisioning to SaaS apps as available on Entra ID Free, but automated group provisioning to SaaS apps as P1 and above. In practice, treat P1 as the requirement:
  • Main Workspace - needs P1 or P2. Oleria grants roles through group membership, so the provisioning job has to push groups, and group provisioning is a P1 feature.
  • Governance App - user provisioning alone is enough here, since every provisioned user gets the reviewer role automatically and there are no groups to sync. This is the one case Microsoft’s table says Free covers. Treat it as unsupported on Free anyway unless you’ve confirmed it in your own tenant: provisioning logs are themselves a P1 feature, so on Free you have no way to see why a sync failed.
P1 is included in Microsoft 365 E3, E5, and E7, Microsoft 365 F1 and F3, Enterprise Mobility + Security E3, and Microsoft 365 Business Premium. P2 is included in Microsoft 365 E5 and E7 and in EMS E5. Both are also sold standalone. Many organizations already hold P1 through Microsoft 365 E3 without realizing it.If your tenant is on Entra ID Free and upgrading isn’t an option, see Alternatives without Entra ID P1.
1

Get Oleria's SCIM credentials

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

Open the Provisioning tab

On the same Entra enterprise application from Part 1 (or, if you’re only setting up SCIM without SSO, a new Non-gallery application).
3

Enter the SCIM Connectivity details

In the Connectivity section set the authentication metod to OAuth2 client credentials grant, for Tenant URL paste Oleria’s SCIM Base URL, for OAuth token endpoint paste Oleria’s OAuth Token URL, for Client identifier paste Oleria’s Client ID, and for Client secret paste Oleria’s Client Secret, credentials should be sent by Header, and finally Scope should remain empty. Click Test Connection to confirm Entra can reach Oleria, then click Save.Image showing Entra Provisioning Connectivity section
4

Turn on provisioning

In the Provisioning section, set Provisioning Mode to Automatic, and set Provisioning Status to On, then click Save. This enables Entra to call Oleria’s SCIM API and create, update, and deactivate users and groups.Image showing Entra Provisioning section
5

Review the attribute mappings

Entra proposes default attribute mappings for Provision Microsoft Entra ID Users.
  • Map the same attribute to both userName and emails[type eq "work"].value, and make it the same attribute as the SAML email claim from Part 1. Use the expression Coalesce([mail], [userPrincipalName]) for both: it prefers mail (correct for guest accounts, whose userPrincipalName is not a real address) and falls back to userPrincipalName for users whose mail is empty.
  • Confirm that either the name parts or name.formatted or both are mapped. This should exist by default.
Entra matches existing users with a userName filter, so userName must carry the address Oleria stored for that user. If userName and emails are mapped to different attributes and they differ for some users, Entra can’t find the account it created and tries to create it again on every cycle, which Oleria rejects as a duplicate.
Main Workspace only: Oleria grants roles through group membership, not directly on the user (see How Oleria maps roles and groups). Leave Provision Microsoft Entra ID Groups enabled so group membership syncs along with users.Governance App: there is no group-to-role mapping to configure - every provisioned user is assigned the single reviewer role automatically. You can turn group provisioning off and provision users only.
Image showing work emails attribute mapping
6

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
7

Scope and start provisioning

Under Users and groups, assign the users or groups that should get Oleria accounts. On the Provisioning tab, set Scope to Sync only assigned users and groups (recommended over syncing the whole directory), then click Start provisioning.
8

Verify

Watch the Provisioning tab’s sync status - the first cycle can take anywhere from about 20 minutes to a few hours. To check one user immediately instead of waiting, use Provision on demand; see Start with Provision on demand. In Oleria, confirm the new users appear (Main Workspace: in Manage Users with the expected role; Governance App: in the governance reviewer list). Unassign a test user in Entra and confirm they lose access in Oleria on the next cycle.
Alternative for the Governance App: if you don’t need directory-driven deprovisioning and don’t want to build the Entra 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 Entra ID P1

If your tenant is on Entra ID Free and adding P1 isn’t an option, these are the working paths. They’re the same options as the Okta equivalent, since the constraint is on the identity provider side rather than Oleria’s. 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 P1.

​
Set up the second workspace

If you need both workspaces connected to Entra, don’t repeat Part 1 with a new enterprise application - see Entra’s one-app-per-Entity-ID rule above. Instead:
  • SSO: in Oleria, go to the SSO Configuration page and select the tab for the workspace you have not yet set up. Add an identity provider using the same Entra app’s App Federation Metadata Url from Part 1.
  • SCIM: Entra allows only one provisioning job per enterprise application, so you can’t add a second Provisioning configuration to the same app you used for SSO. Create a second Non-gallery application instead, used for provisioning only - leave its Single sign-on section unconfigured entirely. Entra’s Entity ID uniqueness rule only applies to apps with SAML SSO configured, so a provisioning-only app with no SAML section touched never collides with it. Point this second app’s Provisioning details at the other workspace’s SCIM Base URL, OAuth Token URL, Client ID, and Client Secret, following Part 2 again on the new app.

​
FAQ

​
Entra and identity provider basics

Microsoft Entra ID is Microsoft’s cloud identity service, renamed from Azure Active Directory (Azure AD) in 2023. It holds your organization’s user accounts and groups, and it’s what your people already authenticate against when they open Microsoft 365, Outlook, or Teams.Connecting it to Oleria means those same work accounts sign in to Oleria, and, once SCIM is on, that Entra decides who has an Oleria account at all.Entra ID is not the same thing as on-premises Active Directory. Many organizations run both and sync accounts from AD into Entra ID with Microsoft Entra Connect. Oleria only ever talks to Entra ID, so the accounts, groups, and attributes it sees are the ones that exist in Entra ID.
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, Entra 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 Entra, which authenticates them with whatever your tenant requires (password, MFA, conditional access).
  3. Entra 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 Entra password, and it can’t sign anyone in that Entra hasn’t vouched for.
They are Oleria’s two identifiers in the SAML handshake, and you paste both into Entra:
  • Entity ID (Entra calls it Identifier) - the unique name of Oleria as a service provider. It’s a name, not a page you can open. Entra uses it to decide which application a given SAML response belongs to, which is why it has to be unique per app. See Entra’s one-app-per-Entity-ID rule.
  • ACS URL (Entra calls it Reply URL) - the Assertion Consumer Service URL, the exact address Entra posts the signed assertion to. It has to match character for character.
The Entra admin center is at entra.microsoft.com. Everything on this page lives under Entra ID → Enterprise applications. The same settings appear in the Azure portal under Microsoft Entra ID, so screenshots from either place match.A tenant is your organization’s own instance of Entra ID: your users, your groups, your applications. It has a name like contoso.onmicrosoft.com and a tenant ID in the form of a GUID. Everything on this page happens inside one tenant. If your account administers more than one, confirm which directory you’re in before you create the application.
A claim is one fact about the signed-in user that Entra includes in the SAML assertion. Oleria needs exactly three:
  • Unique User Identifier (Name ID) - the user’s primary identifier in the identity provider. Oleria requires the Name ID to use the Persistent format, but doesn’t constrain its value. Use user.objectid, the GUID Entra assigns each account, rather than an email address or username, both of which change when someone changes their name.
  • email and name - two extra claims, named exactly that. Entra prefixes new claims with a long namespace URI such as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ by default. Clear the Namespace field on both so the claim arrives as plain email and name, which is what Oleria looks for.
If any of the three is missing or shaped differently, Oleria rejects the sign-in.
Global Administrator can do every step on this page. Application Administrator or Cloud Application Administrator is usually enough on its own: both can create an enterprise application, configure SAML SSO, assign users and groups, and configure provisioning.If a section described here is missing or read-only for you, check your Entra role before assuming it’s a licensing problem, then check Entra ID P1 or P2 is required for SCIM.
In the Entra admin center, the tenant Overview page shows the edition your tenant is licensed for (Free, P1, or P2). Billing → Licenses lists the individual license plans your organization holds.P1 is what SCIM needs, and many organizations already have it bundled into Microsoft 365 E3 without realizing it. See Entra ID P1 or P2 is required for SCIM.
Assignment, under the application’s Users and groups section, controls who is allowed to use the application: who can sign in through it, and, when Scope is set to Sync only assigned users and groups, who provisioning covers.Assignment on its own creates nothing in Oleria. An assigned user who has no Oleria account can complete the Entra half of the sign-in and still be denied, until an account exists for them through SCIM, automatic user provisioning, or Manage Users.
After you select Start provisioning, Entra runs an initial cycle across everything in scope. That first cycle commonly takes 20 minutes and can take several hours on a large directory. After it finishes, incremental cycles run roughly every 40 minutes, so a change in Entra shows up in Oleria within about that window rather than instantly.To test one person without waiting, use Provision on demand on the application’s provisioning page. It runs a single user through the connector immediately and shows each step, including the exact request and Oleria’s response. See Start with Provision on demand.
Two different logs, and picking the right one saves time:
  • Sign-in logs, under Entra ID → Monitoring & health → Sign-in logs, for anything about SSO. Filter by Application to your Oleria application. Every failure carries an AADSTS error code and a description that is far more specific than what the browser shows the user.
  • Provisioning logs, on the enterprise application’s provisioning page, for anything about SCIM. They show each user Entra tried to create, update, or disable, and the error Oleria returned if it refused. Provisioning logs require a P1 or P2 license. See Read the provisioning logs.
No. Provisioning is a one-way push from Entra into Oleria: Entra creates, updates, and deactivates Oleria accounts, and Oleria never writes back into your directory. SSO doesn’t change how anyone authenticates to Microsoft; it only lets Oleria accept the result.Deleting the enterprise application 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 Microsoft Entra ID integration under Integrations is a separate thing: that one reads your tenant so Oleria can analyze it, and it has no bearing on who can sign in.

​
Sign-in troubleshooting

Entra allows one SAML application per Entity ID, and both Oleria workspaces publish the same Entity ID. Use one shared Entra application for SSO rather than two. See Entra’s one-app-per-Entity-ID rule for why, and Set up the second workspace for how to add the second workspace without a second SAML application.
The person isn’t assigned to the enterprise application. Open the application’s Users and groups section and add them, or add a group they belong to. Entra blocks sign-in for everyone else by design, which is what makes assignment your access control for Oleria sign-in.
The Reply URL in the application’s Basic SAML Configuration doesn’t exactly match Oleria’s ACS URL. Trailing slashes, http instead of https, and a truncated paste all count as a mismatch. Re-copy the value from Settings → SSO Configuration in Oleria and paste it again, and check the Identifier while you’re there.
Authentication succeeded and the content of the assertion is the problem. Check, in this order:
  1. Unique User Identifier (Name ID) uses the Persistent format with a stable source attribute such as user.objectid.
  2. The email and name claims exist, are spelled exactly that, and have an empty Namespace.
  3. If you turned on Sign requests, Oleria’s request signing certificate is uploaded to Entra under Verification certificates.
  4. If you turned on Encrypt SAML responses, Oleria’s response encryption certificate is imported and activated on the application’s Token encryption page. An imported but inactive certificate behaves as though you never uploaded it.
Troubleshoot sign-in failures covers the certificate cases in more detail.
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.Entra emails a warning before the certificate expires, to the notification address on the application’s SAML Certificates section. Point that at a monitored mailbox rather than one person.
It’s useful for reading the error Entra itself reports, since it shows the AADSTS code and a suggested fix in place. 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.
This is an Oleria-side validation failure rather than an Entra 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.

​
Start with Provision on demand

Before changing any setting, reproduce the problem against a single user. In the Entra app, go to Provisioning → Provision on demand, select one affected user, and click Provision. Entra runs the full cycle for just that user and returns the result in seconds instead of waiting up to 40 minutes for the next scheduled cycle. The result is shown as four steps, and the one that fails tells you where to look: Expand any step to see the request and response payloads. That detail is what to include when you contact support.

​
Read the provisioning logs

Provisioning → Provisioning logs (also under Entra ID → Monitoring → Provisioning logs) records every object Entra processed in every cycle, kept for 30 days. Provisioning logs require Entra ID P1 or P2 - on Entra ID Free there is no way to see why a sync failed, which is why P1 is the practical requirement for SCIM. Filter by Identity (the user’s name or email) or by Status, then open a row to see the same four steps, with the request and response, that Provision on demand shows. Read the Status column first, because the three values point at completely different causes: Two behaviors that make logs confusing to read:
  • Cycles are incremental. After the first full sync, Entra only re-evaluates objects that changed, so a user who failed earlier won’t reappear in later cycles just because you fixed the mapping. Use Restart provisioning (not Save) to clear the watermark and re-evaluate everyone, or Provision on demand for a single user.
  • Persistent failures get throttled. After about four weeks of failures Entra quarantines the provisioning job and drops to one attempt per day. The Provisioning page shows the quarantine banner; fix the cause, then Restart provisioning.
A 403 on Test Connection or in the logs, rather than a 401, usually means the credentials are valid but belong to the other workspace: the Main Workspace and Governance App tabs issue separate credentials, and each is only accepted by its own SCIM base URL.

​
Provisioning troubleshooting

Automatic provisioning is a premium Entra capability. If the section is missing, read-only, or refuses Automatic, check your tenant’s license before anything else - see Entra ID P1 or P2 is required for SCIM. The same cause explains groups never syncing while users do, since group provisioning needs P1 even when user provisioning works.If upgrading isn’t an option, Alternatives without Entra ID P1 covers the paths that still work.
Work through the connection fields in order:
  • Authentication method is OAuth2 client credentials grant, not a bearer token. Oleria’s SCIM API only issues short-lived tokens through this exchange.
  • Tenant URL is Oleria’s SCIM Base URL, not Oleria’s sign-in address.
  • OAuth token endpoint is Oleria’s OAuth Token URL.
  • Client identifier and Client secret are pasted whole, with no leading or trailing spaces.
  • Credentials are sent by Header, and Scope is empty.
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:
  • The initial cycle hasn’t finished. Check the cycle status and the provisioning logs before changing anything.
  • Scope is Sync only assigned users and groups, but nobody is assigned under Users and groups.
  • Provisioning Status was left Off, or the section wasn’t saved.
  • The job is in quarantine. Entra pauses a provisioning job after repeated failures and shows a banner saying so. Fix the underlying error, then select Restart provisioning.
Use Provision on demand with one test user to see the exact request Entra sent and what Oleria answered, instead of waiting for the next cycle.
Four causes, all common:
  • Group provisioning requires a P1 or P2 license even when user provisioning is working. See Entra ID P1 or P2 is required for SCIM.
  • Provision Microsoft Entra ID Groups is disabled in the attribute mappings.
  • The group itself isn’t assigned to the application. Assigning the members individually syncs the users but never creates the group.
  • The group contains other groups. Entra’s provisioning service doesn’t follow nested groups, and skips members that are groups rather than users. Assign the inner groups directly, or flatten them.
Oleria grants roles through group membership, never on the user record, and a group that arrives over SCIM has no role mapping attached. 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.
Deactivation travels on the next incremental cycle, not immediately, so allow roughly 40 minutes. Confirm it happened in the provisioning logs, which record the disable call, and then in Manage Users.If the cycle ran and nothing changed, check that the person was actually removed from every group assigned to the application, and that Provisioning Status is still On.
Entra’s default mapping sends the mail attribute to emails[type eq "work"].value, and mail is empty for accounts that have never been given a mailbox. Map userPrincipalName there instead, and to userName, as the attribute mapping step in Part 2 describes. Fix the mapping, then use Provision on demand to re-run one affected user rather than waiting for the next cycle.
Entra matches existing users with a userName filter. If userName and emails[type eq "work"].value are mapped to different Entra attributes, and those differ for some people, Entra can’t find the account it already created and tries to create it again on every cycle, which Oleria rejects as a duplicate.Map both to the same attribute, using Coalesce([mail], [userPrincipalName]), as the attribute mapping step in Part 2 describes. Then use Provision on demand to re-run one affected user.
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.