| name | scim-provisioning-integration |
| description | Use when designing or reviewing SCIM-based user lifecycle provisioning into Salesforce from Okta, Azure AD / Entra, or another IdP — create/update/deactivate, group-to-permission-set mapping, attribute mapping, and deprovisioning semantics. Triggers: 'scim provisioning', 'okta scim salesforce', 'entra salesforce provisioning', 'user deactivation automation', 'group to permission set mapping'. NOT for SSO/authentication setup (see single-sign-on skills). |
| category | security |
| salesforce-version | Spring '25+ |
| well-architected-pillars | ["Security","Reliability","Operational Excellence"] |
| triggers | ["scim provisioning from okta to salesforce","how should entra provision salesforce users","deactivation lag on salesforce users","group to permission set mapping strategy","scim attribute mapping for salesforce"] |
| tags | ["security","scim","provisioning","identity","permission-sets"] |
| inputs | ["identity provider and directory source of truth","target group-to-permission-set / role mapping","deprovisioning SLA and frozen-vs-deactivated policy"] |
| outputs | ["SCIM attribute mapping document","group-to-entitlement mapping","deprovisioning runbook"] |
| dependencies | [] |
| version | 1.0.0 |
| author | Pranav Nagrecha |
| updated | 2026-04-23T00:00:00.000Z |
SCIM Provisioning Integration
SCIM turns an IdP into the source of truth for who exists, what they are allowed to do, and when they leave. Done well, it eliminates the "orphan user" problem that every manual provisioning model produces. Done poorly, it creates silent license burn, privilege creep, or worse — users who still have active API tokens after HR thinks they were deprovisioned.
Salesforce accepts SCIM via the User SCIM 2.0 API (enabled per-org) and supports attribute mapping, group-to-Permission-Set-License mapping, and freeze/deactivate via standard SCIM patch semantics. Okta, Entra, OneLogin, and other major IdPs ship Salesforce SCIM connectors; the connector mechanics vary slightly, but the design decisions are the same.
The job is to decide: what's the source of truth, which attributes flow, which groups map to which entitlements, and what happens at termination.
Before Starting
- Confirm which IdP is the source of truth and whether HR or IT owns the upstream data.
- Confirm the Permission Set License count and whether Salesforce licenses are a constraint.
- Confirm the deprovisioning SLA (same-day? within 15 minutes?).
- Confirm legal/compliance policy on user deletion vs deactivation (Salesforce generally deactivates; users cannot be deleted once they own records).
Core Concepts
What SCIM Covers
- Create — IdP triggers user creation when a user is added to an assigned group.
- Update — profile attribute changes flow from the IdP on change.
- Deactivate — user is set to
active = false when removed from the assigned scope.
- Group-to-entitlement — IdP groups map to Salesforce Permission Sets, Permission Set Groups, or Public Groups.
What SCIM Does Not Cover
- Profile selection (Salesforce requires a profile; most IdPs use a default-profile strategy with entitlement layered via Permission Sets).
- Role Hierarchy assignment (often still manual or handled by Apex downstream).
- Record ownership reassignment on termination.
Deactivation Semantics
Salesforce does not delete users — it deactivates. A SCIM DELETE or PATCH active=false freezes login but does not reassign records or revoke tokens automatically. A complete deprovisioning runbook must also:
- Revoke active OAuth tokens for connected apps.
- Freeze the user first (instant effect) before deactivation (slower).
- Reassign ownership of open records, API tokens, queues, and scheduled jobs.
Common Patterns
