Freezing a Salesforce user blocks their ability to log in immediately without changing their record ownership or releasing their license. Deactivating a user (setting IsActive = false) also blocks login, frees the license seat, and removes them from most lookups — but Salesforce won’t let you deactivate a user who still owns records that participate in active processes (queues, approval steps, default lead/case owners, etc.). That’s why “freeze first, deactivate later” is the standard offboarding pattern.
Side-by-side comparison
| Behavior | Freeze | Deactivate |
|---|---|---|
| Where you do it | User detail page → Freeze button | User detail page → uncheck Active |
| Login blocked | Yes, immediately | Yes, immediately |
| License seat | Still consumed | Released — seat is available again |
| Record ownership | Unchanged — user still owns their records | Unchanged, but you typically reassign before deactivating |
| Appears in lookups / assignment rules | Yes | No (hidden from most active-user lookups) |
| Reversible | Yes — click Unfreeze | Yes — re-check Active if a seat is available |
| Use when | You need to lock someone out right now, before you’ve untangled ownership | You’ve finished offboarding and want the license back |
The offboarding sequence interviewers expect to hear
A senior offboarding flow looks like this:
- Freeze the user the moment HR confirms termination. This kills any active sessions and blocks new logins instantly.
- Reassign records — open opportunities, cases, leads, custom object records, queue memberships, approval-process delegates, default owners on lead/case assignment rules.
- Remove from groups, queues, territories, sharing rules so future records don’t flow to them.
- Deactivate the user to release the license seat.
- Optional: if the user is a system admin or has elevated permissions, also reset their MFA registration and remove them from any connected-app installed-by lists.
Skipping step 2 is the classic mistake — Salesforce will block the deactivation, or worse, your assignment rules will quietly fail because they point at an inactive user.
”Why not just deactivate immediately?”
Two reasons interviewers like to probe:
- Speed. Freezing happens in one click. Deactivation can be blocked by validation rules, ownership constraints, or running flows that reference the user — sometimes you need an hour or two of cleanup before deactivation actually succeeds.
- Reversibility cost. If a freeze turns out to be a mistake (wrong user, premature offboarding), unfreezing is trivial. Reversing a deactivation requires an unused license seat to be available, which is not guaranteed in a fully-licensed org.
Common follow-up: what about deletion?
Salesforce does not allow deletion of user records. Once a user exists, they exist forever — the row is referenced as a foreign key by every audit field (CreatedById, OwnerId, LastModifiedById) on every record they ever touched. Deactivation is the closest equivalent to deletion. This is why interviewers ask the freeze-vs-deactivate question instead of a “delete a user” question.
Verified against: Salesforce Help — Freeze or Unfreeze User Accounts and Deactivate Users. Last reviewed 2026-05-17.