A team member gives notice, and someone suggests the obvious cleanup step: deactivate their Salesforce user. Then the questions start. What happens to the leads that used to route to them? What about the approval process where they're the final approver? The scheduled report that runs under their name every Monday?
Salesforce doesn't let you delete users — you can only deactivate them — and that's deliberate. User records are referenced all over your org: in automation, ownership, sharing, and audit history. Deactivating without checking those references is how orgs end up with failed flows, stuck approvals, and web-to-lead forms quietly erroring on a Friday afternoon.
This guide covers what actually breaks when you deactivate a Salesforce user, how to find every reference before you flip the switch, and the checklist that keeps departures boring instead of disruptive.
Deactivating a Salesforce user freezes their access but leaves their record — and everything pointing at it — in place. Records they own stay owned by an inactive user, assignment rules and flow field updates that reference them can fail or route into a void, approval steps assigned to them stall, scheduled jobs and dashboards that run as them stop, and you cannot deactivate a user who is the sole recipient of a workflow email alert. The safe path: freeze the user first, inventory every place they're referenced (assignment rules, flows, approvals, scheduled jobs, integrations, default owners), reassign or repoint each one, then deactivate. Vantage Point builds this deactivation audit into offboarding runbooks as part of its Salesforce consulting work.
Salesforce has never allowed user deletion. Every record owner, every created-by stamp, every approval history entry, and every audit trail row references a user ID. Deleting the user would orphan all of it.
Deactivation is the compromise: the user loses all access, the license frees up for reassignment, but the record remains so historical data and references stay intact. That's also the trap — because nothing looks different after deactivation, broken references surface days or weeks later as failed automations and confused users.
Salesforce offers a middle step worth using: freezing. A frozen user can't log in, but all automation keeps working while you inventory and reassign their dependencies. For any departure that isn't amicable-or-urgent, freeze on day one and deactivate when the checklist is done.
The failures fall into six categories, roughly in order of how painful they are.
The single most common breakage. A flow with an assignment element pointing at a specific user — "set Owner ID to Jane Smith" — will fault when Jane is inactive. Legacy workflow field updates and Process Builder processes with named-user targets behave the same way, and processes can't update records owned by inactive users at all. These are often invisible until a record hits the automation path and errors.
Lead and case assignment rules that route to the departing user keep firing — into an inactive owner's queue of work nobody sees. Web-to-lead and Email-to-Case configurations with a default owner or default case creator set to that user can fail record creation outright. Active assignment rules that point to a deactivated user produce exactly the outcome you're trying to avoid: new records assigned to someone who will never log in again.
Any approval step with the user as a designated approver stalls: records sit in "Pending" forever with no one able to act. Salesforce blocks deactivation outright if the user is the sole approver on an active approval process or the sole recipient of a workflow email alert — but it doesn't block the subtler cases, like being one named approver among several steps.
Scheduled Apex jobs, scheduled report runs, and dashboards with a "running user" set to the departing person stop or error on deactivation. Because these run in the background, the failure mode is silence: the Monday pipeline report simply never arrives.
The expensive surprise: an integration that authenticates as the departing user — a middleware connection, a marketing automation sync, a custom script — loses access the moment the user is deactivated. Integrations should run under a dedicated integration user for exactly this reason; deactivation season is when you find out which ones don't.
Deactivated users lose records manually shared with them or shared via account teams — and users above them in the role hierarchy can lose inherited access that flowed through that user's position. Record ownership itself stays put: opportunities, accounts, and cases remain owned by the inactive user until you transfer them.
There's no single "where is this user used" button, so the inventory is a sweep:
| Step | Action | Why |
|---|---|---|
| 1 | Freeze the user on their last day | Blocks access immediately without breaking automation |
| 2 | Transfer owned records (accounts, opportunities, open cases, leads) | Processes can't update records owned by inactive users; pipelines need live owners |
| 3 | Repoint assignment rules and default owners | New inbound records must land on active users or queues |
| 4 | Fix hard-coded references in flows, workflow rules, and processes | Prevents automation faults on the next record that hits the path |
| 5 | Replace them in approval processes and email alerts | Salesforce blocks some of these; the rest stall silently |
| 6 | Reassign scheduled jobs, reports, and dashboard running users | Background jobs die quietly under inactive users |
| 7 | Move integrations to a dedicated integration user | Removes the person-dependency entirely |
| 8 | Update queue and public group memberships | Prevents unmonitored single-member queues |
| 9 | Deactivate, then reuse the license | Only after steps 1–8 check out |
The durable fix is architectural: automation should reference roles, queues, and public groups — never named individuals. A flow that assigns follow-up to "the onboarding queue" survives any departure; a flow that assigns it to a specific named rep becomes a production incident when that rep changes roles. The same logic applies to approval processes (use manager hierarchies or queues) and integrations (dedicated integration users with least-privilege profiles).
Teams that adopt this pattern describe the difference plainly: offboarding becomes a ten-minute membership update instead of a metadata archaeology project. If your org has years of accumulated hard-coded references, a one-time audit that converts user-bound automation to group-bound automation pays for itself the very next departure.
Vantage Point's Salesforce consultants run structured org audits that surface every hard-coded user reference, fragile assignment rule, and person-dependent integration — then refactor them to queue-, group-, and role-based designs that survive staff changes. For teams that want this handled continuously, our managed services and ongoing support include offboarding runbooks and proactive org health checks. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
Vantage Point can audit your assignment rules, flows, approvals, and integrations for single-person dependencies — and fix them before the next resignation letter arrives. Talk to Vantage Point about a Salesforce org health check.
No. Salesforce only allows deactivation, because user records anchor record ownership, sharing, approval history, and audit trails. Deactivating removes all access and frees the license while preserving every historical reference.
They stay owned by the inactive user until transferred. The records remain visible and reportable, but some automation — including Process Builder processes — can't update records owned by inactive users, and pipelines lose an accountable owner. Transfer open records before deactivating.
Freezing immediately blocks login while leaving every automation, schedule, and reference intact — ideal for the gap between a departure and completed cleanup. Deactivation is the permanent step, taken after records and references are reassigned.
Common blockers: the user is the sole recipient of a workflow email alert, the sole approver on an active approval process, a default case creator or owner, or referenced in custom hierarchy fields. Resolve each dependency and retry.
The rule keeps firing, but the record gets assigned to someone who will never see it — or, in configurations where the user is a default owner, creation can fail. Always repoint assignment rules to active users or queues before deactivation.
No. Integrations should authenticate as a dedicated integration user with a least-privilege profile. Integrations running under a departing employee's credentials break the moment that user is deactivated — usually at the worst possible time.