# 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.