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.
Quick Answer
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.
Key Takeaways (TL;DR)
- You can't delete users: Salesforce only allows deactivation, because user records anchor ownership, sharing, and history.
- What breaks: hard-coded user references in flows and assignment rules, sole-recipient email alerts, approval steps, scheduled jobs, dashboards, and default record owners.
- Freeze first: freezing blocks login immediately while you clean up references — deactivate only after reassignment.
- Design the fix: point automation at queues, public groups, and roles instead of named individuals so departures stop being incidents.
- How Vantage Point helps: org audits and offboarding runbooks through our managed services team.
Why Can't You Just Delete a Salesforce User?
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.
What Actually Breaks When You Deactivate a User?
The failures fall into six categories, roughly in order of how painful they are.
1. Hard-coded user references in flows and processes
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.
2. Assignment rules and default owners
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.
3. Approval processes
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.
4. Scheduled jobs, reports, and dashboards
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.
5. Integrations and connected apps
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.
6. Sharing and hierarchy side effects
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.
How Do You Find Every Place a User Is Referenced?
There's no single "where is this user used" button, so the inventory is a sweep:
- Assignment rules: export lead and case assignment rules and grep for the user's name; check the default owner settings on web-to-lead, web-to-case, and Email-to-Case.
- Flows and processes: use flow list views filtered by "hard-coded" suspects, or search metadata via the Salesforce CLI or a tool like Salesforce Optimizer / a metadata search utility for the user's ID.
- Approval processes: review every active approval process for named approvers; also check delegated approver settings on the user record itself.
- Scheduled items: check Scheduled Jobs (Setup), scheduled reports, and dashboards where they're the running user.
- Queues and public groups: note membership — queue membership itself doesn't break anything, but a queue whose only member departs is an unmonitored pool.
- Integrations: list connected apps and ask the practical question: whose credentials does each one use?
- Owned records: run reports by owner for every object the person touches, and use mass transfer (or the data loader) to reassign before deactivation.
What Does a Safe Deactivation Checklist Look Like?
| 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 |
How Do You Stop This From Being a Recurring Fire Drill?
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.
How Vantage Point Helps
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.
Is Your Org One Departure Away From Broken Automation?
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.
Frequently Asked Questions
Can you delete a user in Salesforce?
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.
What happens to records owned by a deactivated user?
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.
What is the difference between freezing and deactivating a user?
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.
Why won't Salesforce let me deactivate a user?
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.
Do assignment rules still work if they point to an inactive user?
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.
Should integrations ever run under a regular user's account?
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.
