# SCIM provisioning from the customer's IdP
## The order
1. Set up the enterprise SSO connection for the customer's org first. SCIM
rides on the SSO connection; there is no standalone SCIM setup.
2. Enable SCIM provisioning on the connection in the dashboard.
3. Clerk generates a SCIM base URL and a bearer credential for the
connection. Hand both to the customer's IdP admin to enter in their
provisioning settings (Okta, Entra ID, and friends all speak SCIM).
4. The IdP starts pushing: user creates, profile updates, suspensions, and
group membership changes, which sync into the Clerk organization.
5. Test with a small pilot group in the IdP before the customer points
their whole directory at it.
## What you get
- Deprovisioning that actually works. When the customer disables a user in
their IdP, the suspension propagates and the user loses access instead of
lingering until someone remembers to remove them.
- Group sync into org membership, so the customer's team structure maps to
your org without manual role assignment per hire.
## The traps
- SCIM suspension is not the same as your app's own deactivation logic. If
your database keeps a separate active flag, sync the SCIM-driven state
into it via the membership webhooks, or the two systems disagree about
who is active.
- The bearer credential Clerk generates is long-lived. Treat it like the
secret it is: the customer stores it in their IdP, you never log it, and
you rotate it if it leaks.
- Group-to-role mapping is a design decision, not automatic magic. Decide
which IdP groups map to which Clerk roles before the first sync, and
write the mapping down where both teams can see it.
## Checklist
- A deprovisioned test user cannot sign in and cannot use an existing
session within your session-revocation expectations.
- Your audit log records SCIM-driven changes distinctly from manual ones,
so a confused customer admin can tell what the IdP did versus what a
human did.