Out, as Well as In

Module 4 of 5 in the chapter Getting Users In and Out: Provisioning, chapter 12 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: When someone leaves, what has to happen in Salesforce, and how does it get there?

The login stops, the user doesn’t

Chapter 4 made a promise about single sign-on: when someone leaves, you switch them off once, at the identity provider, and they’re out of everything. That’s true for the login. It isn’t the whole story.

Switch Priya off at the identity provider, and she can’t sign in through single sign-on any more. But what about her Salesforce user? It’s still there, and still active.

Click to enlarge

What’s still there, if the leave never reaches Salesforce?

• Her licence. An active user holds one.
• Any other way in. If she ever had a Salesforce password, or the org allows logins that don’t go through the identity provider, she may still get in.
• Her app tokens. Apps she approved may still hold refresh tokens for her (chapters 8 and 9).
• Her work. Records she owns, reports and jobs scheduled as her, things assigned to her.

And remember module 2: just-in-time never removes anyone. She stops logging in, so it never hears about it.

So leaving isn’t done until it reaches every place she had access, Salesforce included.

Freeze or deactivate

Salesforce gives you two switches.

Deactivate is the real one. A deactivated user “can’t log in” (S4), and no longer counts against your licences, though it doesn’t change your bill: that’s the licence count (S8). Her records stay, with her name on them, for you to reassign.

Freeze is for when you can’t deactivate yet. Some things block deactivation: say she’s selected in a custom hierarchy field, or she’s the only recipient of an email alert. Then “freeze the user’s account first to prevent logins while you reassign ownership, memberships, and so on” (S8), and deactivate later. But know what freezing doesn’t do: “Freezing user accounts doesn’t make their user licenses available… To make their user licenses available, deactivate the accounts” (S7).

A word on freezing from a different angle. I’ve seen teams freeze everyone to keep them out during maintenance. What does a frozen user see at the login screen? A very generic message. They don’t know why they can’t log in, so they try password resets, and the help desk fills up. If you want to keep people out for a while, a login flow is a much cleaner tool: let them log in, and hold them in a waiting room with a message. Freezing is for people you’re removing.

What else to tidy

Deactivation isn’t the last step. From Salesforce’s own considerations (S8):

• Reassign what she owned. “Processes can’t update records that are owned by inactive users.”
• Remove her permission sets. “Inactive users can still be assigned to permission sets and permission set groups. We recommend that you remove these assignments.”
• Revoke her app tokens. Revoke the OAuth tokens apps hold for her (chapter 8 showed revoking a token; chapter 13 covers the lifecycle). Revoke them whether or not deactivating her has already done it: it costs a minute, and you’ll know.
• Integration users are different. Some user types can’t be deactivated at all, “such as the Automated Process user or integration users” (S8). Their leaving is retiring the integration: its app, its credentials, its permission sets.

The identity provider pushes

Doing all that by hand, for every leave, is how leaves get missed. The better answer is to make the place that knows, the identity provider, tell Salesforce.

That’s SCIM, the open standard System for Cross-Domain Identity Management. Salesforce has SCIM endpoints, at /services/scim/v2/, for its users, with Salesforce’s own extensions (S4):

• Joins: create the user, with a POST.
• Moves: update her, with a PATCH, including her profile, permission sets and role.
• Leaves: deactivate her. Not delete: “In Salesforce, you deactivate user objects rather than deleting them” (S4).

The identity provider calls those endpoints with an OAuth access token (S4), so the identity provider’s connection is itself an integration, with its own app and its own integration user (chapter 8). Many identity providers can do this; how each one sets it up is in its own documentation. Salesforce’s own Identity Connect retirement notice warns what happens when provisioning isn’t covered: “users not being able to access Salesforce or compliance and de-provisioning issues” (S9).

Now chapter 4’s promise is really true. Switch her off once, at the identity provider, and the leave reaches Salesforce the same day.

Steve Trucking: the staff

Steve Trucking’s staff, in dispatch, finance and account management, sign in through the company’s identity provider (Checkpoint 1). So the identity provider is where the truth lives. A new dispatcher is created in Salesforce when she’s created there, with the dispatch permission set. When she moves to finance, the identity provider changes her access in Salesforce. When she leaves, she’s deactivated in Salesforce the same day, and a report shows records still owned by people who’ve left, for someone to reassign.

And the admins? Made by hand, with a direct login and MFA, as a backup plan. Not through the identity provider: if it’s down, someone still has to get in.

Test knowledge. In my experience, know the difference between freezing and deactivating a user, and how an identity provider can provision and deprovision Salesforce users.

What’s next

Module 5: the other way round. Salesforce as the source.

What an architect decides here

• How every leave reaches Salesforce, for every group of people.
• Freeze or deactivate, and who does the tidying: records, permission sets, tokens.
• Whether the identity provider pushes users with SCIM, and with which integration user.
• How integration users are retired, since they can’t be deactivated.

Explore

• Manage Salesforce User Identities with SCIM (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• Considerations for Deactivating Users (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
• Freeze or Unfreeze User Accounts (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)