How it works
SCIM defines a common format for users and groups and a REST API for managing them. The identity provider, such as Okta or Microsoft Entra ID, acts as the SCIM client; each application exposes a SCIM endpoint and acts as the server.
When IT assigns a person or group to an app, the identity provider sends a create request with the user's attributes, such as name, email, department and manager. Later changes are sent as updates, and when the person is unassigned or leaves, the identity provider deactivates or deletes the account. Group membership can be pushed the same way to drive teams or permissions.
SCIM complements single sign-on. SSO decides how people sign in; SCIM decides which accounts exist and what they contain. Used together, one change in the directory controls both access and the account itself.
How to measure it
- Compare the number of active users in the app with the number assigned in the identity provider.
- Time how long it takes for a new hire or a leaver to show up in the app.
- Check which attributes are mapped, and that department or team values match what the app uses to build groups.
Examples
- A company assigns its all-staff group to the desk booking app in Okta; every employee gets an account with their department, and new hires appear automatically.
- A leaver is deactivated in Microsoft Entra ID, and their booking account is disabled in the next sync.
Common mistakes
- Enabling SSO without provisioning, which leaves accounts to be created and removed by hand.
- Mapping inconsistent department values, which creates duplicate or empty teams.
- Deleting rather than deactivating users when history, such as past bookings, needs to stay in reports.
How Kadence helps
Kadence supports SCIM and directory sync on all plans, alongside SSO with Okta, Microsoft Entra ID, Google, OneLogin, JumpCloud and others. Teams can be built from directory attributes with custom attribute mapping, Google Workspace attributes and profile photos can sync, and SFTP directory sync covers cases where API sync is not an option.
Integrations · Security and trust
Frequently asked questions
What does SCIM stand for?
SCIM stands for System for Cross-domain Identity Management. It is an open standard published by the IETF that defines a common schema for users and groups and a REST protocol for creating, reading, updating and deleting them across systems.
What is the difference between SCIM and SSO?
SSO handles sign-in: one set of credentials checked by the identity provider. SCIM handles the account itself: creating it when someone joins, updating it when details change and deactivating it when they leave. SSO without SCIM still leaves account cleanup to someone by hand.
Is SCIM the same as directory sync?
SCIM is one way to do directory sync. Directory sync is the general idea of keeping an app's user list in step with the company directory. Some apps sync through SCIM, others through a vendor API, an HR system connection or a scheduled file transfer.
Do you need SCIM if you have an HRIS integration?
Often yes. SCIM, driven by the identity provider, controls accounts and access. An HRIS integration brings employment facts such as start dates and leave dates. Workplace teams use SCIM so everyone can sign in and book, and the HR connection to seat people before they start and release desks when they leave.
Related terms
- Single sign-on (SSO) One set of company credentials to sign in to many apps, verified by the identity provider rather than each app.
- HRIS integration A connection that syncs joiners, leavers, teams and leave dates from the HR system into workplace software automatically.
- Joiners, movers and leavers (JML) The process that keeps access, equipment, seating and records in step when people join, change role or leave.
Sources
- RFC 7643: System for Cross-domain Identity Management: Core Schema, IETF
- RFC 7644: System for Cross-domain Identity Management: Protocol, IETF
Kadence editorial team · Last reviewed