SCIM provisioning explained: add and remove users

Every new hire needs accounts, and every leaver needs them removed. SCIM provisioning lets your identity provider do both in your other business apps: add someone in Google Workspace or Microsoft Entra ID and their accounts are created; suspend them and those accounts are switched off.

Single sign-on answers who can sign in. SCIM answers a different question: which accounts should exist at all. Without it, someone still has to create each account by hand on day one and remember to remove it on the last day. The second half is the one that gets missed.

What SCIM is

SCIM stands for System for Cross-domain Identity Management. Version 2.0 is an open standard published by the IETF in 2015, in two parts: RFC 7643 describes the data (users, groups and their attributes) and RFC 7644 describes the protocol (how one system sends changes to another over HTTPS).

Piece	What it does
Users	One record per person: a user name, full name, email addresses and an active flag
Groups	Named sets of users, often used to decide roles or access in the connected app
ServiceProviderConfig, ResourceTypes, Schemas	Discovery endpoints that tell the identity provider what the connected app supports
Bearer token	Usually a secret the connected app issues so the identity provider can authenticate its requests

The lifecycle of an account

1. Joiner. You add a person in the identity provider and assign the connected app. The identity provider sends a create request (a POST to the Users endpoint) and the account exists before the person ever signs in.
2. Mover. The person changes name, team or role. The identity provider sends an update (PATCH or PUT), and group changes can move them between roles in the connected app.
3. Leaver. You suspend or remove the person. The identity provider usually sets the account to inactive, or deletes it, and the connected app stops accepting them.

Identity providers generally send these changes on a schedule rather than at the moment you click, so expect a short delay between a change in the directory and each connected app. For urgent leavers, suspend the account in the identity provider and check each app's own member list as well.

SCIM or sign-in time provisioning

Question	Sign-in time (just-in-time)	SCIM
When is the account created?	When the person signs in through single sign-on	When you assign the person in the identity provider
Can you share work with them before they sign in?	No, the account does not exist yet	Yes
What happens when they leave?	They can no longer sign in, but the account stays active in the connected app	The account is deactivated or removed
Do group changes reach the connected app?	Usually at the next sign-in, if at all	Yes, through group updates

Many teams use both: single sign-on for the sign-in itself, SCIM to keep the list of accounts right. The guide to single sign-on for a small business covers the sign-in half.

Setting it up

1. Check support on both sides. Entra ID can provision users to apps that expose a SCIM endpoint. Google Workspace supports user provisioning for a set of supported apps. Ask the vendor which identity providers they have tested.
2. Create a token in the service. The service gives you a SCIM endpoint address and a bearer token. Treat the token like a password.
3. Connect the identity provider. For a custom app, paste the endpoint and token into the identity provider's provisioning settings; for a supported catalog app, the identity provider may ask you to authorize the connection instead. Then test the connection.
4. Map attributes and groups. Decide which directory groups become which roles in the connected app. Keep the default for new people narrow; see choosing a default role for new members.
5. Start with a pilot group. Provision a few people, check their accounts and roles, then widen the scope.

Apple devices have their own version of this idea: directory sync in Apple Business Manager creates Managed Apple Accounts from your identity provider. See Apple's directory sync for Managed Apple Accounts.

What SCIM does not do

• It does not set permissions inside a record. It creates the account and can place it in groups. What each role can see is still decided in the connected app; see who can see which fields.
• It does not replace a record of changes. Keep the identity provider's logs and each app's own history; the guide to audit trails for small businesses explains why both matter.
• It does not move data. A leaver's records stay in the connected app for someone else to take over.

Frequently asked questions

What does SCIM stand for?

System for Cross-domain Identity Management. It is an open standard, defined by the IETF in RFC 7643 and RFC 7644, for sending user and group changes from one system to another.

Do I need SCIM if I already use single sign-on?

Not always. Single sign-on stops a leaver from signing in, which covers most of the risk. SCIM adds the rest: accounts that exist before day one, group-based roles, and accounts that are actually deactivated rather than left behind.

Is SCIM the same as directory sync?

They solve the same problem. Directory sync is a general term for copying people from a directory into another system. SCIM is one open standard for doing it, which many business apps support.

What happens to a user's data when SCIM removes them?

That depends on the service. Many apps deactivate the account and keep the records the person created, so a colleague can take them over. Check this before you connect provisioning, especially if the service deletes accounts outright.