Salesforce User Deactivation: The Complete Admin Checklist
Deactivating a Salesforce user sounds simple — flip a toggle, done. In practice, a careless deactivation breaks automations, orphans records, and leaves the license tied up anyway. Here's how to do it right.
Why deactivation is more than flipping a switch
When you deactivate a Salesforce user, you're not deleting them — their records, activities, and history stay in the org. What you're doing is preventing them from logging in and freeing the license for reassignment. But Salesforce has a checklist of dependencies that can block the deactivation or cause problems afterward if you skip them.
The most common admin complaint: "I deactivated the user, but now [workflow / flow / queue / approval process] is broken." This guide covers every dependency so your deactivation is clean.
TL;DR: Before deactivating, transfer record ownership, reassign queues and approval processes, update automation defaults, and check for scheduled reports. After deactivating, confirm the license is released and document the change. Takes 20–30 minutes per user when done properly.
Step 1 — Identify what the user owns
A departing user may own hundreds or thousands of records across Leads, Contacts, Accounts, Opportunities, Cases, and custom objects. Salesforce lets you deactivate a user regardless of their record count, but those records will show up as owned by an inactive user — which breaks views, assignments, and round-robin rules.
Before deactivating, run a quick report across each object type using an "Owner" filter set to the user. Focus on:
- Open Leads and Opportunities — these have active business impact. Transfer to the user's manager or replacement immediately.
- Open Cases — especially any that are SLA-sensitive. Transfer to the queue or the assigned support rep.
- Custom object records — check any process-critical custom objects your org uses.
Salesforce's built-in "Transfer Records" tool (under Setup → Users → the user's detail page) handles bulk transfer across most standard objects. Use it. Don't try to reassign records manually.
Step 2 — Handle queue and group memberships
If the user is a member of a queue (Lead or Case queue, for example), remove them from the queue before deactivating. Leaving an inactive user in a queue doesn't prevent deactivation, but it does mean records assigned to that queue may route to the inactive user during round-robin, where they sit indefinitely.
Check: Setup → Queues → each relevant queue → Queue Members → remove the user.
Also check Public Groups. If the user was in a public group used in sharing rules, folder access, or email alert routing, remove them from the group first.
Step 3 — Reassign approval processes
This is the most common cause of broken automations post-deactivation. If the user was a designated approver in an approval process, requests submitted after deactivation will route to an inactive user — where they sit, stuck, until an admin manually reassigns them.
Check every approval process where the user is listed as an approver:
- Setup → Process Automation → Approval Processes → check each active process
- Look for "Assigned Approver" steps that name the user specifically (vs. manager-based routing)
- Replace with a current active user or a queue
Also check: are there in-flight approval requests currently assigned to this user? Recall them or manually reassign before deactivating.
Step 4 — Update flow and workflow defaults
Workflows, Flows, and Process Builder automations can be configured to send email alerts to specific users, assign tasks to specific users, or create records owned by specific users. If the target is the departing user, these automations fail silently after deactivation.
Search for the user's name in:
- Setup → Process Automation → Workflow Rules → alert recipients
- Setup → Process Automation → Flows → any "Assign User" or "Send Email" actions targeting the specific user
- Setup → Cases → Assignment Rules and Escalation Rules
- Setup → Leads → Assignment Rules
This is the most time-consuming part of the deactivation checklist. There's no bulk search across all automation types in the Salesforce UI — you have to check each category. Salesforce's "Optimizer" report sometimes flags these, but it's inconsistent.
Step 5 — Handle scheduled reports and dashboards
If the user had scheduled reports or dashboards, those schedules stop working at deactivation. The reports themselves don't disappear — they're just no longer delivered. If other stakeholders relied on those scheduled deliveries, take one of two actions:
- Clone the report/dashboard to a new owner and recreate the schedule, OR
- Transfer ownership of the scheduled report to an active user (the "Change Report Owner" option in Reports)
Also check if the user owns any dashboards that are shared org-wide or used in embedded analytics. Transfer those to a service account or a team lead before deactivating.
Step 6 — Check Connected App OAuth tokens
If the user authorized any third-party apps via OAuth (Slack, Gong, Salesloft, SpendReady, or any other connected app), those tokens are tied to their credentials. After deactivation, API calls made with those tokens will fail with an authentication error.
Check: Setup → Connected Apps → OAuth Usage → filter by the user's name → revoke any active tokens.
For integration users (headless accounts used by data pipelines), don't just deactivate — make sure the integration is reconfigured to use a different service account before cutting off access.
Step 7 — Deactivate the user
Once you've worked through the checklist above:
- Setup → Users → find the user
- Edit → uncheck "Active" → Save
- Salesforce may present blocking errors at this point (e.g., "User is sole member of queue X") — resolve each one and retry
Common deactivation blockers:
- User is the only member of a queue → add another member before deactivating
- User is the default workflow user → Setup → Process Automation → Workflow Settings → change Default Workflow User
- User is the org's default case owner → Setup → Cases → Support Settings → change Default Case Owner
- User is the Automated Case User → same as above
Step 8 — Confirm the license is freed
After deactivation, the license should return to your available pool. Confirm via Setup → Company Information → User Licenses → check the "Active Users" count dropped by one relative to "Total Licenses."
If the user had Permission Set Licenses assigned (Einstein, Revenue Intelligence, etc.), those are freed automatically at deactivation — you don't need to manually remove PSL assignments, though it's good hygiene to do so for clarity.
Making deactivation part of your offboarding process
The cleanest orgs treat Salesforce deactivation as a required step in the HR/IT offboarding checklist — not as something the Salesforce admin does weeks later when they notice an inactive user in a report.
A practical approach: when HR notifies IT of a departure, the notification includes a "Salesforce deactivation" checklist ticket that routes to the CRM admin. The admin completes the checklist within 24 hours of the departure date. The license is freed immediately rather than sitting assigned to an inactive user for months.
The cost of delayed deactivation isn't just waste — it's also a security risk. An active license tied to a departed employee is a potential attack surface, especially if their credentials were ever shared or if they retained their work email for a grace period.
Finding users who should already be deactivated
If you're reading this because you're about to do a cleanup rather than a single departure, you need a report of active licensed users who haven't logged in recently. The SOQL:
SELECT Id, Username, Name, LastLoginDate, UserLicenseId FROM User WHERE IsActive = true AND LastLoginDate < LAST_N_DAYS:90 ORDER BY LastLoginDate ASC NULLS FIRST
Users with LastLoginDate = null have never logged in at all — those are the highest-priority deactivation candidates, because they represent licenses that were allocated and never used.
For orgs with 50+ seats, running this query manually and working through the results ad-hoc doesn't scale. SpendReady automates the detection — weekly, with dollar figures attached to each inactive seat — so the cleanup list is always current rather than a snapshot that ages out within days of being run. See our full guide on inactive user reports for the complete SOQL and interpretation framework.