When organizations talk about Rippling's identity management capabilities, the conversation usually starts with the HR side: joiner-mover-leaver workflows, automated provisioning triggers, and who owns the access request process. That's the right conversation to have — but it tends to stop before reaching the technical layer where the actual provisioning work happens.

SCIM and SSO are the infrastructure underneath those HR workflows. Get them right, and automated provisioning works as described: a new hire appears in your identity provider, apps are provisioned on schedule, and access is revoked the moment a termination is processed.

Get them wrong, and you end up with provisioning errors that nobody notices until an employee can't log in on their first day, or an ex-employee who still has access because the SCIM sync failed silently three weeks ago.

This is a guide to what IT actually configures in a Rippling SCIM and SSO implementation — attribute mapping, protocol selection, group-based provisioning, and the failure modes worth designing around from the start.

The Architecture: How Rippling Fits into Your Identity Stack

Understanding how Rippling works with your identity provider (IdP) requires understanding what role Rippling plays in the stack. In most mid-market implementations, Rippling serves as the source of truth for employee data — it knows who is employed, what their role is, where they're located, and what department they're in. The IdP (Microsoft Entra ID, Okta, Google Workspace, or others) serves as the authentication authority — it issues tokens, enforces MFA policies, and controls session behavior.

SCIM is the protocol that keeps employee data synchronized between Rippling (the source) and your IdP and downstream apps (the consumers). SSO is the authentication protocol (SAML or OIDC) that applications use to verify a user's identity through the IdP rather than managing their own passwords.

These are complementary but distinct systems. SCIM provisions accounts. SSO authenticates them. You can implement one without the other — but the full security and operational benefit comes from both working together. Our piece on identity lifecycle management covers the HR ownership and workflow design; this post covers the technical configuration layer.

SCIM 2.0: What It Does and What IT Configures

SCIM (System for Cross-domain Identity Management) version 2.0 is the open standard that Rippling uses to push employee data to connected applications and identity providers. When a new employee record is created in Rippling and their start date arrives, a SCIM API call goes to the configured endpoint in your IdP or app, creating the user with the correct attributes.

The SCIM provisioning flow works like this: Rippling holds the authoritative employee record. On the trigger event (new hire start, role change, termination), Rippling constructs a SCIM request with the user's attributes and sends it to the receiving system's SCIM endpoint. The receiving system creates, updates, or deactivates the user record accordingly.

Attribute Mapping: Where Most Implementations Get Sloppy

Attribute mapping is the configuration that tells Rippling which fields from the employee record to send to a target application, and what to call them on the receiving end. This is where most implementations get sloppy — and where silent provisioning failures originate.

The core attribute set for most SCIM integrations includes: userName (typically the email address or UPN), givenName and familyName, displayName, emails (primary work email), active (boolean that controls account status), and externalId (Rippling's internal employee ID, used to match records on both sides).

Beyond the core set, most organizations need to map additional attributes that drive access control in target apps: department, title, manager (often as a reference to the manager's SCIM ID), costCenter, and custom attributes specific to the application.

The configuration decisions that matter most:

userName format consistency

Your userName in every SCIM-connected application should use the same format and come from the same source field in Rippling. If some apps use first.last@company.com and others use flast@company.com, you'll have matching failures when SCIM tries to correlate records across systems. Standardize before you connect multiple apps.

externalId as the anchor

Configure externalId to pass Rippling's employee ID to every SCIM-connected system. This is the stable identifier that survives name changes, email address changes, and org restructures. If you're matching records on email address alone, a legal name change or email domain migration will break your SCIM links and create duplicate accounts.

Manager reference mapping

Mapping the manager relationship via SCIM is valuable — it populates org chart data in connected applications and can drive approval workflow configurations. But it requires that the manager's account already exists in the receiving system when the direct report is provisioned. Sequence your provisioning to create managers before direct reports, or your manager references will fail silently and leave the field blank.

Custom attribute schemas

Some applications support custom SCIM attributes beyond the standard schema. If a target app uses department codes rather than department names for access control, you'll need to map a custom Rippling field (or a formula field derived from the standard department field) to the app's custom SCIM attribute. This requires knowing the target app's SCIM schema before you configure the connection — a step that gets skipped surprisingly often.

SAML vs. OIDC: Choosing the Right SSO Protocol

For SSO, you'll be configuring either SAML 2.0 or OpenID Connect (OIDC) depending on what the target application supports. Both accomplish the same basic goal — the user authenticates with your IdP and the application receives a token confirming their identity — but they work differently and have different configuration requirements.

SAML 2.0 is the older and more widely supported standard. It uses XML assertions passed between the application (service provider) and the IdP. SAML is the right choice when the application only supports SAML, when you're integrating with enterprise applications that predate OIDC, or when you need fine-grained attribute assertion control in the SAML response.

SAML configuration in Rippling involves: the Entity ID (the application's unique identifier, sometimes called the Audience URI), the ACS URL (Assertion Consumer Service URL — where Rippling sends the SAML response after authentication), the signing certificate (used to verify the assertion was issued by your IdP), and the attribute statements (the user attributes included in the SAML assertion, such as email, firstName, lastName, and groups).

OIDC is the modern standard built on OAuth 2.0. It uses JSON Web Tokens (JWTs) instead of XML, supports a broader range of authentication flows, and is generally simpler to configure for modern SaaS applications. If an application supports both SAML and OIDC, OIDC is usually the better choice for new configurations.

OIDC configuration involves: a client ID and client secret (issued by Rippling to the application), the authorization endpoint, token endpoint, and userinfo endpoint (all provided in Rippling's OIDC configuration), and the scopes the application requests (typically openid, email, and profile at minimum).

The key practical difference: SAML is initiated by either the IdP or the service provider (IdP-initiated vs. SP-initiated SSO). OIDC is almost always SP-initiated — the user starts at the application, which redirects them to the IdP for authentication. For end-user experience, SP-initiated SSO through a dashboard like Rippling's app catalog is the cleaner flow.

Group-Based Provisioning: Scaling Access Control Past the Individual

Provisioning individual users is the foundation, but the power of SCIM at scale comes from group-based provisioning. Rather than configuring application access for each user individually, you define groups in Rippling that map to permission tiers in target applications — and SCIM keeps group membership synchronized automatically.

A practical example: your project management tool has three access tiers — Viewer, Editor, and Admin. In Rippling, you create three groups: PM-Viewer, PM-Editor, and PM-Admin. Membership in these groups is driven by Rippling's employee attributes (role, department, seniority level). When a new hire joins the design team, they're automatically added to PM-Editor based on their department. When they're promoted to a lead role, the group membership updates and their application access level changes. No manual provisioning ticket required.

The configuration work here happens in two places: group definition and membership rules in Rippling, and group-to-role mapping in the target application. Both need to be maintained when application permission structures change — which is a common source of drift. If the target app adds a new permission tier and IT doesn't update the Rippling group-to-role mapping, users end up in the wrong access tier silently.

Failure Modes Worth Designing Around

A well-configured SCIM and SSO implementation runs invisibly. The failures are what get noticed — usually by an end user who can't access something they need, or a security team reviewing access logs. The most common failure modes:

Silent provisioning failures

SCIM requests can fail for several reasons: the receiving system's endpoint is temporarily unavailable, an attribute value violates a format constraint in the target system (a displayName that's too long, a userName with a disallowed character), or a required attribute is missing. Most SCIM implementations will retry failed requests, but if the root cause isn't fixed, the retry will fail too — and the user account won't be created.

Build monitoring into your provisioning workflow: check for failed SCIM events in Rippling's audit log at least daily during the first month after any new integration goes live.

Deprovisioning gaps

Provisioning new users is the part that gets tested. Deprovisioning is the part that gets assumed. Test your termination flow explicitly: process a test termination, confirm the SCIM deactivation event fired, confirm the account is disabled in the target application, and confirm SSO access is revoked. Do this for every application connected via SCIM, not just the primary IdP. Our piece on offboarding as a security event covers the full deprovisioning checklist.

Attribute drift

Employee attributes change — people get married and change their names, departments restructure, job titles update. If attribute changes in Rippling aren't being pushed to connected applications via SCIM update events, your connected systems accumulate stale data. Confirm that SCIM update events are enabled and working for the attributes you care about, not just create and delete events.

Certificate expiration

SAML signing certificates expire. When they do, SSO stops working for every application configured with that certificate — simultaneously, across your entire user base. Put certificate expiration dates in your IT calendar 90 days in advance. This is an embarrassingly common cause of organization-wide SSO outages.

Scope mismatch between SCIM and app permissions

If your SCIM provisioning creates user accounts but doesn't assign the correct group memberships — because the group sync hasn't been configured or the mapping is wrong — users will be able to log in but won't have the access they need to do their job. This is the most common Day 1 access failure. Test the full provisioning flow including group assignment, not just account creation.

A Note on Rippling's App Catalog vs. Custom SCIM/SSO Integrations

Rippling maintains a catalog of pre-built application integrations that have SCIM and SSO configured for the most common attribute schemas and endpoints for those applications. For apps in the catalog, the configuration work is significantly lighter — you're confirming field mappings rather than discovering them.

For applications not in the catalog, you're implementing a custom SCIM and/or SSO integration, which requires the application's SCIM endpoint URL and bearer token, the SAML SP metadata or OIDC client credentials, and documentation of the application's attribute schema. The process is well-defined but requires coordination with the application vendor's support team, and testing time should be budgeted accordingly.

The Bottom Line

SCIM and SSO aren't glamorous. They're infrastructure — and like most infrastructure, they're most noticed when they fail. A well-configured implementation means automated provisioning runs on schedule, access is revoked when it should be, and your security team has an audit trail they can actually trust.

The configuration decisions that matter most are attribute mapping consistency (especially userName and externalId), group-based provisioning design, and explicit testing of the deprovisioning flow. Get those right, and the rest tends to follow.

If you're implementing Rippling's SSO and SCIM capabilities for the first time or reviewing an existing configuration, reach out to the thePeopleStack team. We do this work regularly and can accelerate the configuration and testing process significantly.