What is SCIM provisioning?
SCIM (System for Cross-domain Identity Management) is an open standard that lets an identity provider such as Microsoft Entra ID or Okta create, update, and deactivate user accounts in connected apps automatically. When someone joins, changes roles, or leaves, the change reaches every connected app within minutes, without an admin re-typing it anywhere.
Updated August 30, 2026
How does SCIM work?
SCIM 2.0 is a small REST API defined in RFC 7643 and RFC 7644. The app being provisioned exposes the API; your identity provider calls it with a bearer token. Assign a person to the app and the provider sends a JSON record of that person. Change their title or manager in the directory and the provider sends the update. Deactivate them and the provider tells the app that too.
The direction is what matters: the identity provider pushes. The app never holds a credential to your directory, nothing polls on a schedule, and a change lands in the connected app minutes after it lands in the directory.
What fields does a SCIM record carry?
The core schema covers the account basics: user name (usually the work email),
display name, work email and phone, job title, and an active flag. An
enterprise extension adds the organizational fields: employee number, department,
cost center, and manager. Manager is the field an org chart is drawn from,
and because it is part of the standard, any SCIM-capable identity provider can
send it.
What is the difference between SCIM and SAML?
They solve different problems, and most companies that use one end up using both.
| SCIM | SAML | |
|---|---|---|
| What it does | Moves account data into the app | Signs people in to the app |
| When it runs | When the directory changes | When a person signs in |
| What you get | Accounts that exist and stay correct | Single sign-on with existing credentials |
SAML answers "is this person who they claim to be" at the moment they sign in. SCIM keeps the app's picture of your people correct between sign-ins, including for people who never sign in at all.
When should you use SCIM instead of a scheduled sync?
Both give you the same end state: an app that mirrors your directory. The difference is where the work happens and how fast changes land.
- SCIM pushes changes within minutes and keeps directory credentials out of the app entirely. It needs an identity provider with a provisioning engine (Microsoft Entra ID, Okta, JumpCloud, and OneLogin all have one) and a few minutes of configuration on the IdP side.
- A scheduled pull sync has the app read the directory with its own credential on a schedule. Setup lives in the app instead of the IdP, which is often the easier path for a small IT team.
- A CSV upload needs no IT involvement at all, and suits a bootstrap or an HR system with no API.
If your identity provider already provisions your other apps, SCIM is the natural choice. If provisioning would be new ground, a pull sync gets you the same chart today, and you can switch to SCIM later.
Does Sprooster support SCIM provisioning?
Yes. Sprooster exposes a SCIM 2.0 endpoint at /api/scim/v2 and accepts pushes
from any SCIM 2.0 provisioning engine, including Microsoft Entra ID and Okta. It
reads the enterprise extension's department and manager fields to draw the org
chart, treats deactivation as "drop off the chart, keep the history", and logs
every push in the same audit trail its scheduled syncs write. A workspace admin
mints the bearer token in Settings; the
SCIM setup guide has the exact values for Entra ID
and Okta.
Sprooster can also fill the chart by pull sync from Entra ID, Google Workspace, or BambooHR, or from a CSV upload. Pick one source per workspace.