Glossary
SCIM (System for Cross-domain Identity Management)
The standard for keeping user accounts in sync automatically: when HR adds, moves or removes someone, the identity provider pushes the change to every connected application over SCIM, so nobody keeps an orphaned login.
General definition
SCIM (System for Cross-domain Identity Management) solves the last step of enterprise identity. Single sign-on tells an application who is logging in; SCIM tells it who should have an account in the first place, and who should not any more. The standard, published by the IETF in 2015, defines a core schema for users and groups (RFC 7643) and a REST protocol over JSON (RFC 7644). An identity provider such as Okta or Microsoft Entra ID acts as the SCIM client and pushes changes to the application, which exposes /Users and /Groups endpoints as the SCIM server.
- Create: a new hire appears in the directory and the IdP POSTs a user to every assigned application
- Update: name, email, department or group membership changes are sent as PUT or PATCH
- Deactivate and delete: a leaver is set to
active: falseor removed, closing access everywhere within minutes - Groups: group membership maps to application roles, so access follows the org chart
- Filtering and paging: the IdP can query the application to reconcile drift
The alternatives are just-in-time (JIT) provisioning and custom API provisioning. JIT creates the account at first login through SAML or OIDC, which covers onboarding but does nothing for offboarding: the account lingers until someone notices. Custom provisioning uses the application’s own user API, driven by the customer’s backend or an integration platform; it is as complete as SCIM but bespoke. SCIM’s advantage is that identity providers already speak it, so the customer’s IT team configures it without writing code.
In procurement, SCIM support is a common line item for software sold into large or regulated organisations because deprovisioning is an audit control: reviewers want evidence that access ends when employment does. It matters most for workforce products where every employee has a login. For customer-facing products, where the end users are patients, clients or members rather than staff, the population is managed by the business’s own systems and provisioning runs through APIs instead.
In the Ethora ecosystem
Ethora’s provisioning model is API-first. Each App has its own users, and the customer’s backend creates, updates and removes them through the API, obtaining short-lived JWT chat tokens so end users never see a separate Ethora login. That covers the SCIM use case for the people who matter most in a healthcare, finance or insurance deployment: the patients, clients and staff whose identities the customer already manages in its own systems or directory.
For the team members who administer the platform, roles and ACL settings are managed in the admin panel, and enterprise SSO against the corporate identity provider is available on dedicated deployments. Because every App is isolated inside the shared or dedicated cluster (see multi-tenancy), provisioning is scoped per App, and every account change is written to the audit trail so an offboarding review can show when access ended.
