scim-provisioning-integration
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).
Best use case
scim-provisioning-integration is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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).
Teams using scim-provisioning-integration should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/scim-provisioning-integration/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How scim-provisioning-integration Compares
| Feature / Agent | scim-provisioning-integration | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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).
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 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 | Lifecycle event | Behavior | |---|---| | 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 ### Pattern 1: Single-Group-Per-PermissionSet Each IdP group maps to exactly one Permission Set. Easy to audit, easy to reason about. Recommended default. ### Pattern 2: Role-Based Group Bundle An IdP group maps to a Permission Set Group that bundles multiple Permission Sets. Fewer IdP groups to maintain; requires discipline in keeping the PSG membership current. ### Pattern 3: Birthright + Entitlement Layer All users get a "birthright" baseline set via their IdP tenant. Additional entitlements layer via explicit group membership. Good for large orgs with common baseline access. ### Pattern 4: Freeze-First Deprovisioning IdP deactivation fires a `freeze-user` call first (immediate login block), then a follow-up `deactivate` after a compensating runbook reassigns records and revokes tokens. Critical for regulated industries. ### Pattern 5: Two-IdP Topology One IdP provisions employees, another provisions contractors. Clear boundary — each tenant owns a disjoint set of users; Salesforce sees both via two SCIM connections. --- ## Decision Guidance | Situation | Recommended Approach | Reason | |---|---|---| | Simple org with linear entitlements | Single-group-per-PS (Pattern 1) | Easiest audit | | Role-based access model in IdP | PSG bundles (Pattern 2) | Maps cleanly from roles | | Regulated industry, strict deprov SLA | Freeze-first (Pattern 4) | Legally defensible | | Mixed workforce (employee / contractor) | Two-IdP topology (Pattern 5) | Ownership clarity | | Salesforce license constraints | Combine with JIT provisioning on login | Avoids pre-allocating licenses | ## Review Checklist - [ ] Source of truth for each attribute is explicit. - [ ] Group-to-entitlement mapping is documented. - [ ] Deactivation runbook covers freeze + token revoke + record reassignment. - [ ] Profile strategy is documented (default profile + PS layering vs dynamic profile). - [ ] License count monitoring in place to catch provisioning leaks. - [ ] Tested deprovisioning end-to-end against SLA. ## Recommended Workflow 1. Confirm IdP source of truth and attribute ownership. 2. Design group-to-entitlement mapping; produce the audit table. 3. Decide profile strategy (single default + PS layering is the usual choice). 4. Build the deprovisioning runbook (freeze → revoke tokens → reassign → deactivate). 5. Pilot with a small group; monitor license consumption and lag. 6. Document ownership between IT, HR, and Salesforce admin teams. --- ## Salesforce-Specific Gotchas 1. Salesforce does not delete users — SCIM `DELETE` deactivates. 2. OAuth tokens survive user deactivation unless explicitly revoked. 3. Permission Set License assignment is separate from Permission Set assignment — SCIM mapping must handle both. 4. Profile changes via SCIM are unusual; most orgs use a default profile and layer entitlements via PS/PSG. 5. Freezing is near-instant; deactivation propagation can lag a few minutes. ## Proactive Triggers - Deprovisioning runbook with no OAuth token revoke step → Flag Critical. - SCIM mapping maps IdP groups to Profiles directly → Flag High. PS layering is the common best practice. - Deactivation without prior freeze in a regulated context → Flag High. - Orphan permission set assignment not governed by SCIM → Flag Medium. - License burn > planned rate → Flag High. ## Output Artifacts | Artifact | Description | |---|---| | Attribute mapping document | IdP attribute → Salesforce User field | | Entitlement mapping | IdP group → PS / PSG | | Deprovisioning runbook | Freeze → revoke → reassign → deactivate | ## Related Skills - `security/mfa-enforcement-strategy` — authentication posture. - `security/oauth-token-management` — token lifecycle on deactivation. - `security/privileged-access-management` — elevated-access controls layered on top. - `admin/user-management-and-governance` — ongoing user operations.
Related Skills
omnistudio-lwc-integration
Use when embedding OmniScripts in Lightning Web Components, registering custom LWC elements inside OmniScript screens, or calling OmniScript/Integration Procedures from LWC. Triggers: embed omniscript in LWC, custom LWC element in OmniScript, call OmniScript from Lightning page, omnistudio-omni-script tag, seed data JSON, OmniScript launch from LWC. NOT for standalone LWC development, standard Flow embedding, or OmniScript-to-OmniScript embedding.
integration-procedures
Use when building, reviewing, or debugging OmniStudio Integration Procedures. Triggers: 'integration procedure', 'IP', 'HTTP action', 'DataRaptor', 'rollbackOnError', 'failureResponse'. NOT for Apex-only integrations unless the main design choice is whether OmniStudio is still appropriate.
integration-procedure-cacheable-patterns
Use when designing Integration Procedures (IPs) with platform cache to cut latency and callout load. Covers cache key design, TTL selection, per-user vs org-wide partitions, invalidation on data changes, and safe fallback on cache miss/stale. Does NOT cover general IP authoring (see omnistudio-error-handling-patterns) or LWC client-side caching.
slack-salesforce-integration-setup
Use this skill when setting up or troubleshooting the Salesforce for Slack managed app — including connecting a Salesforce org to a Slack workspace, configuring the three-party admin handshake, linking Slack channels to Salesforce records, enabling record preview sharing, and managing org-level limits. Triggers on: Salesforce for Slack app not connecting, Slack org connection setup, Salesforce record sharing in Slack, Slack workspace admin approval, connecting Salesforce to Slack. NOT for building custom Slack apps or Slack bots (separate development platform), not for Slack Workflow Builder Salesforce connector (use slack-workflow-builder skill), not for Flow-based Slack messaging (use flow-for-slack skill).
sis-integration-patterns
Use this skill when designing or implementing an integration between a Student Information System (SIS) — such as Ellucian Banner, Ellucian Colleague, Anthology Student, Oracle PeopleSoft Campus Solutions, or Workday Student — and Salesforce Education Cloud. Covers the canonical Education Cloud data model objects (AcademicTermEnrollment, CourseOfferingParticipant, CourseOfferingPtcpResult, LearnerProfile, PersonAcademicCredential), external ID / upsert keying strategies using SIS-native identifiers (Banner PIDM, PeopleSoft EMPLID), batch nightly upsert patterns, Change Data Capture (CDC) for enrollment status writeback, and MuleSoft/middleware watermark patterns. Trigger keywords: SIS integration, Banner integration, PeopleSoft integration, Education Cloud data model, enrollment sync, grade writeback, AcademicTermEnrollment, LearnerProfile upsert. NOT for Salesforce Admissions Connect application processing, Financial Aid integration, Learning Management System (LMS) integrations, or general ETL tooling not involving Education Cloud objects.
salesforce-to-salesforce-integration
Use this skill to implement Salesforce-to-Salesforce integration patterns — covering the native S2S feature, API-based cross-org sync, Platform Event bridging, and Salesforce Connect Cross-Org adapter. Trigger keywords: Salesforce to Salesforce integration, cross-org data sharing, S2S feature, cross-org Platform Events, Salesforce Connect cross-org. NOT for multi-org strategy or architecture decisions (use architect/multi-org-strategy), single-org data sharing, or external (non-Salesforce) system integration.
real-time-vs-batch-integration
When to use this skill: choosing between real-time (synchronous callouts, Platform Events, CDC, Pub/Sub API) and batch (Bulk API 2.0, scheduled ETL) integration patterns. Trigger keywords: should I use real-time or batch, how to sync high-volume data, when to use Platform Events vs Bulk API, integration latency vs volume tradeoff. NOT for Batch Apex internals (use batch-apex-patterns), NOT for MuleSoft middleware design (use middleware-integration-patterns), NOT for CDC field tracking configuration.
platform-events-integration
Use when publishing Platform Events from external systems via REST API, subscribing to Platform Events from outside Salesforce via CometD or Pub/Sub API, designing replay ID strategy for durable external consumers, or handling high-volume event delivery guarantees. Trigger keywords: 'external publish platform event', 'CometD subscribe', 'Pub/Sub API', 'replay ID external', 'durable subscription', 'RetainUntilDate'. NOT for Apex-only event publishing or triggering (use platform-events-apex). NOT for Change Data Capture external subscription (use change-data-capture-integration).
middleware-integration-patterns
Use when selecting or comparing middleware / iPaaS tools (MuleSoft, Dell Boomi, Workato, Informatica) for Salesforce connectivity, or when determining whether a scenario requires middleware at all versus native Salesforce capabilities. Triggers: 'which iPaaS should I use', 'MuleSoft vs Boomi vs Workato', 'when do I need middleware for Salesforce', 'message transformation orchestration middleware'. NOT for MuleSoft Anypoint Salesforce Connector configuration (use mulesoft-salesforce-connector). NOT for API-led connectivity layer design (use api-led-connectivity). NOT for native Salesforce-to-Salesforce integration, Platform Events, or CDC.
idempotent-integration-patterns
Use when designing retry-safe integrations with Salesforce — including external ID upsert strategies, idempotency key management for inbound calls, Platform Event replay safety, and Outbound Message retry handling. NOT for Salesforce duplicate management rules.
heroku-salesforce-integration
Heroku ↔ Salesforce integration paths — Heroku Connect (Postgres bidirectional sync), Heroku AppLink (expose Heroku APIs to Flow / Apex / Agentforce), Heroku External Objects (Salesforce Connect oData), Platform Events, REST API in either direction, and Salesforce Canvas for UI embedding. Decision matrix + Heroku Connect deep dive (OAuth integration user, plan-tier row limits, polling cadence, region co-location). NOT for AWS integration (see integration/aws-salesforce-patterns), NOT for generic PaaS, NOT for MuleSoft.
file-and-document-integration
Use when uploading, downloading, managing, or integrating files and documents with Salesforce — covering ContentVersion/ContentDocument, REST multipart uploads, base64 inserts, Files Connect for external storage reads, and virus scanning callout patterns. Triggers: 'upload file to Salesforce', 'ContentVersion REST API', 'Files Connect external storage', 'multipart file upload', 'document integration pattern', 'virus scan uploaded file'. NOT for Bulk API data loads, Chatter feed post content, email attachment handling via EmailMessage, or CRM Content classic libraries.