SCIM provisioning is automated user provisioning carried out over the SCIM protocol. An identity provider or governance tool creates accounts in an app, keeps their attributes and group memberships current, and deactivates them when the person leaves, all without anyone doing it by hand. For apps that support SCIM, it is the clean, standard way to keep them in sync with a source of truth.
It is worth separating from SCIM the protocol. SCIM is the standard. SCIM provisioning is what you do with it.
The operations
Four operations cover the account lifecycle.
Create. A new user in the source of truth becomes an account in the app.
Update. Attribute and role changes flow through, so the app account matches the current record.
Deactivate and reactivate. A leaver is suspended automatically, and restored just as fast if they return.
Group and membership sync. Directory groups map to app roles, so access follows role assignment rather than manual edits inside the app.
Together these mean a joiner appears everywhere they should, a mover's accounts update, and a leaver's accounts deactivate, without per-user work once the connection is made.
Setup
The setup is a one-time connection, not an ongoing task. Enable SCIM in the app, generate a token, and hand it to the tool doing the provisioning. From that point the sync runs on its own. The absence of per-user work after setup is the entire value of the protocol: the plumbing is laid once and then it just carries.
Where it stops
Two edges bound what SCIM provisioning can do.
The first is coverage. Only apps with a SCIM endpoint can be provisioned this way. Most of a typical stack, the standard-plan tools, the internal admin panels, the older systems, cannot, either because they never built SCIM or because they gate it behind a tier the company does not buy. For all of those, SCIM provisioning is simply not available, and the work falls back to tickets unless another method covers it.
The second is depth. For the apps that are connected, SCIM keeps accounts and group memberships in sync. It does not manage fine-grained entitlements below the group, run access reviews, or generate audit evidence. Account sync is necessary and not sufficient. The governance sits on top.
Beyond SCIM
The apps SCIM cannot reach still need provisioning, and it does not have to be manual. Where an app has a usable API, provisioning runs over that. Where it does not, a custom automation framework drives the app directly, the way an admin would, and produces the same lifecycle result. Neither path depends on a SCIM endpoint or an enterprise-tier upgrade, which is how the non-SCIM majority of the stack gets automated on any plan.
Related terms
- SCIM. The protocol SCIM provisioning runs over.
- Deprovisioning. The deactivate step, and the part that must also reach non-SCIM apps.
- Joiner-mover-leaver (JML). The lifecycle SCIM provisioning automates for connected apps.
- Birthright access. Day-one provisioning by role, which SCIM helps deliver where apps support it.