Why
SCIM Is Hard

Every SaaS app has its own user schema. Slack wants userName as an email. Salesforce needs a FederationIdentifier. Google wants primaryEmail. SCIM defines a standard schema, but vendors map attributes differently — or ignore fields entirely.

Your IdP has ‘Engineering’ and ‘Marketing’ groups. Slack calls them channels, Salesforce calls them permission sets, GitHub calls them teams. SCIM Groups exist in the spec, but translating group semantics across apps is where implementations break.

You can’t add a user to a Salesforce permission set before they exist. You can’t assign a GitHub team before the org invite is accepted. SCIM doesn’t define operation ordering, so every integration needs custom sequencing logic.

Google Workspace supports SCIM for user creation but not group management. HubSpot’s SCIM is GA but limited. Many vendors implement just enough SCIM to check the box, leaving gaps that require custom workarounds.

Most vendors require SAML SSO before enabling SCIM. This creates a chicken-and-egg problem: you need SSO configured to test provisioning, but provisioning errors can break SSO flows. Debugging one often means debugging both.

SCIM 2.0 (RFC 7644) is well-defined. But vendors interpret ‘SHOULD’ and ‘MAY’ differently. Pagination, error codes, rate limits, and bulk operations vary wildly. A SCIM client that works with Okta may fail with Azure AD.

SCIM errors are often opaque. A 400 response might mean a missing required attribute, a schema mismatch, or a licensing issue. Vendor logs are sparse. There’s no standard way to test SCIM integrations before going live.

Some apps model identity as users-in-groups. Others use roles, permission sets, or team hierarchies. SCIM’s flat user+group model doesn’t map cleanly to every app’s internal identity architecture, requiring translation layers.