Salesforce SCIM is a standard way for an identity system, such as Okta or Microsoft Entra ID, to create, update and deactivate Salesforce users automatically. Instead of an admin keying in each new hire and remembering to turn off each leaver, your HR-driven directory does it. It removes a lot of manual work, but it does not decide what a person is allowed to see. That part still needs to be designed.
This guide explains what SCIM is, what Salesforce supports, how the common identity providers connect, and the mistakes we would watch for. Everything about Salesforce and the identity providers below was checked against vendor documentation in November 2026.
What SCIM is, in plain language
SCIM stands for System for Cross-domain Identity Management. It is an open standard for passing user records between systems. One system holds the source of truth for people (your directory). Another system (Salesforce) receives those people as user accounts.
Salesforce's own documentation says it supports user provisioning and management through SCIM, with extensions to the SCIM 2.0 specification so Salesforce-specific user properties can be managed. You send create, read, update and disable operations to SCIM endpoints, and each request needs an OAuth 2.0 access token (Salesforce Help, SCIM overview, checked November 2026).
What SCIM does for a Salesforce admin
When provisioning is set up well, the lifecycle looks like this:
- Joiner: a person is added to the right group in your directory, and a Salesforce user is created for them.
- Mover: their title, department or manager changes in the directory, and the Salesforce record is updated.
- Leaver: they are removed or disabled in the directory, and their Salesforce user is deactivated.
That last step matters most. Forgotten accounts are one of the most common findings in an access review, and a former employee with a working login is a real risk for any organization holding client or donor data.
Salesforce never deletes a user. It deactivates them. Salesforce's documentation states that you deactivate user objects rather than deleting them, which keeps history intact and lets you reactivate the user later (Salesforce Help, SCIM overview, checked November 2026).
What SCIM does not do
SCIM moves identities. It is not an access design. Three things it does not solve on its own:
- It does not decide what the person can do. A new user still needs a profile and the right permission sets. If you map everyone to one broad profile, you have automated over-permissioning. Our guide to permission sets vs. profiles covers how to structure that.
- It does not clean up existing access. If a leaver already had extra permission sets or sharing, deactivation stops the login, but the underlying design may still be messy.
- It does not replace single sign-on. Provisioning creates the account. SSO decides how the person signs in. They work well together but are configured separately.
How the common identity providers connect
Not every connector uses SCIM in the same way, so it helps to read the documentation for your specific tool.
Okta. Okta's Salesforce integration supports pushing new users, pushing profile updates, pushing user deactivation, importing new users and profile updates from Salesforce, and reactivating users (Okta Help, Salesforce supported features, checked November 2026). Okta also notes that profile changes made on the app side are overwritten by the Okta values, so decide up front which system owns each attribute (Okta Help, provisioning, checked November 2026).
Microsoft Entra ID. Microsoft documents automatic provisioning and de-provisioning from Entra ID to Salesforce. Its tutorial describes connecting to Salesforce's user provisioning API, and it has a few specifics worth knowing (Microsoft Learn, Salesforce provisioning tutorial, checked November 2026):
- It needs a dedicated integration user with a custom profile that has API Enabled, Use Any API Auth and Manage Users.
- It signs in through the SOAP API
login()call. Microsoft notes Salesforce disables that call by default for orgs created in Winter '26 and later, and that a Winter '27 release update requires the Use Any API Auth permission for SOAP sign-ins in all orgs from December 1, 2026. - Entra imports Salesforce profiles and shows them as application roles. Each user needs a valid role assigned, and the default mapping supports one role per user.
- It cannot be configured on a Salesforce trial account.
The takeaway: do not assume one setup guide fits every tool. Confirm what your provider actually calls in Salesforce and what it needs to be allowed to do.
Who should use it, and who can wait
SCIM-style provisioning pays off when you have:
- A central directory you already trust (Okta, Entra ID or similar).
- Regular joiners and leavers, such as seasonal staff, volunteers with logins, or contractors.
- A compliance or funder expectation that access is removed promptly.
- More than a handful of Salesforce users, so manual steps are easy to miss.
If you have a small team, no central directory and few changes, a written offboarding checklist may be enough for now. Our Salesforce user offboarding checklist is a good place to start, and it still applies when you automate.
If your identity provider is more than you need, there is another path: automating the user lifecycle inside Salesforce. Troppus's Onboard360 is a Salesforce-based product for that, with role-based provisioning templates, automated access assignment, lifecycle events (new hire, role change, leave, termination) and an audit trail. Which route fits depends on what you already own.
A safe rollout in six steps
- Take an inventory. List current active users and who they map to in your directory. Orphans and duplicates show up here.
- Define roles first. Decide which profile and permission sets each job type receives before you automate anything.
- Create a dedicated integration user. Give it only the permissions the connector documents. Do not reuse a person's admin login.
- Test in a sandbox. Run joiner, mover and leaver cases with fake users before touching production.
- Start with one pilot group. Assign a small group, watch the provisioning logs, then widen.
- Review on a schedule. Check for failed syncs, license limits and users who exist in Salesforce but not in the directory.
Common problems to expect
- License limits. If there are no licenses left, creation fails. Microsoft lists this as a known error.
- Duplicate usernames. Salesforce usernames must be unique across all Salesforce orgs, so a username can collide with one in another org.
- Missing required fields. Users missing attributes such as email or alias will fail to create.
- Manual email approvals. Microsoft notes Salesforce requires email changes to be approved before they take effect, so you may see repeated update entries until that happens.
- Credentials that expire. A reset password or token on the integration user can silently break the sync.
Frequently asked questions
Is SCIM included with Salesforce?
Salesforce's documentation says SCIM support is available in Salesforce Classic and Lightning Experience in all editions (Salesforce Help, SCIM overview, checked November 2026). The identity provider side is usually a separate subscription, and which provisioning features you get depends on that vendor's plan.
Does SCIM delete Salesforce users?
No. Salesforce deactivates users rather than deleting them. The record remains, so reports and history that reference the user keep working.
Does SCIM assign permission sets?
It depends on the connector and how it is configured. In the Entra tutorial, the default mapping assigns one profile per user. Test permission set assignment in a sandbox before assuming it is covered.
Is SCIM the same as single sign-on?
No. SCIM manages the account's existence and attributes. Single sign-on manages how the person logs in. Many teams use both.
Do we still need access reviews if we automate?
Yes. Automation keeps accounts in step with your directory. It does not tell you whether the access itself is appropriate. See our guide to finding over-permissioned users in Salesforce.
Want a second pair of eyes on your user lifecycle?
If you are weighing identity-provider provisioning, in-Salesforce automation or a better checklist, we can look at how users are created and removed in your org today and tell you where the gaps are. Book a free Salesforce health check.