To offboard a Salesforce user safely, remove their ability to log in first, reassign what they own second, and deactivate the account third. Salesforce does not let you delete users, so deactivation is the end state. Doing the steps in the right order keeps reports, approvals and automations working, and gives you a record that access was removed on time.
Below is the checklist we use as a starting point, in the order that avoids surprises. Adapt it to your org, and keep a copy for each departure.
Why offboarding goes wrong
Most offboarding problems have one cause: the request arrives late and informal. An email from HR says someone left last Friday, the admin deactivates the account on Monday, and then three things break. A dashboard that ran as that person stops updating. An approval process stalls. Records sit with an inactive owner.
The risk is not just tidiness. A former employee with a working login is an access problem, especially when your org holds donor or client data. Funders and auditors increasingly ask for proof of timely removal. Our SOC 2 checklist for Salesforce covers the evidence they tend to expect.
Before the last day: plan the handover
Do these while the person is still around and can answer questions.
- Confirm the date and time access should end, and who approved it.
- List what the user owns. Records, reports, dashboards, list views, email templates, scheduled jobs and flows they built or run.
- Decide who takes over each item, by User Id rather than name in your tracking sheet.
- Check roles that depend on them. Are they a default owner for leads or cases, a queue member, an approver or an email alert recipient?
- Ask what is connected to their login. Mobile app, email integration, calendar sync, API tokens and connected apps.
On the last day: cut off access
- Freeze the user. In Setup, search Users, open the user and choose Freeze. A frozen user cannot log in, but the license is still consumed, and freezing is useful when you need access gone immediately but the account cannot be deactivated yet because of dependencies. See Salesforce's help article on freezing and deactivating users.
- End active sessions. Open the user's detail page, review their sessions and end any that are still active. Check that your edition shows this option.
- Remove access outside Salesforce login. Revoke connected app and OAuth tokens, and remove the person from the identity provider (such as Okta or Microsoft Entra ID) if you use single sign-on. If you provision users from an identity provider, disabling them there should deprovision them in Salesforce. See our article on automating user provisioning from Workday or ADP.
- Remove from groups. Public groups, queues, account and sales teams, and any distribution-based sharing.
- Remove permission set assignments if the account will be kept for a while. These do not matter much once the user is deactivated, but they matter if the account is ever reactivated.
Within a few days: reassign what they owned
This is the step people skip, and it is where things break later.
- Records. Search Mass Transfer Records in Setup Quick Find, or use report-based transfer, or a data loader update, to change the owner of leads, accounts, contacts, cases and other objects. Decide whether to give everything to one person or route by territory or program.
- Reports and dashboards. If a dashboard runs as the departing person, change the running user to an active, appropriately permissioned user before deactivating. Otherwise the components can break. See this admin checklist for pitfalls when deactivating that covers running users.
- Automations. Flows, approval processes, assignment rules and scheduled jobs that name the user. Approval processes that include the user as a named approver will stall. Scheduled jobs they own may need to be reassigned or recreated.
- Defaults. If the user is a default owner or creator (for example for leads or cases, or the default workflow user), Salesforce will not let you deactivate until you choose someone else. Check Lead Settings, Case Settings and Process Automation Settings in Setup.
- Email templates, list views, Chatter groups. Move ownership of anything the team still uses.
- Open tasks and events. Reassign to the new owner so follow-ups are not lost.
Deactivate
Once the reassignments are done, open the user in Setup and clear Active. Deactivating frees the license so it can be reused, which matters when licenses are a real cost for a small organization. Salesforce will show an error if something still depends on the user, such as one of the defaults above. Fix it and try again.
Leave the deactivated record as it is. It stays in Salesforce, which is what you want for audit trails and for records that still show them as creator.
After: prove it and keep a record
Keep a short record for each departure. At minimum:
- User Id
- Date the request arrived and date access ended
- Who approved
- What was reassigned and to whom (by Id)
- Who completed the checklist
That record answers an auditor's question in a minute. Then run a periodic check for gaps. This query counts active users who have not logged in for 90 days, which often catches someone who left without anyone telling you:
SELECT COUNT() FROM User WHERE IsActive = true AND LastLoginDate < LAST_N_DAYS:90
Our guide to finding over-permissioned users uses this and other queries for a fuller review.
Making offboarding automatic
A checklist works when someone remembers to start it. To make it reliable, tie it to your HR system or ticketing process, so a termination event starts the work automatically. Options include provisioning from your identity provider, a Salesforce flow that creates a task for each step, or a managed process.
Troppus's Onboard360 is built for this kind of user lifecycle automation in Salesforce, including role-based provisioning templates, lifecycle events such as new hire, role change, leave and termination, and an audit trail.
Frequently asked questions
Should I freeze or deactivate a departing user?
Freeze first if you need immediate cutoff and have cleanup left. Deactivate when the cleanup is done. A frozen user still uses a license.
Can I delete a Salesforce user?
Not through the standard setup. Users are deactivated, not deleted. Deactivation preserves history for records they created or owned.
What happens to records owned by a deactivated user?
They remain owned by that user until you transfer them. Sharing based on ownership or the role hierarchy may behave differently, so reassign ownership promptly.
How fast should access be removed?
As close to the end of employment as you can. Set your own target, such as the same day, and write it into your policy.
What about contractors and volunteers?
Treat them the same way. Give contractors an end date at the start, and consider a permission set with an expiration date for short-term access.
Need help tightening the process?
We can review your current offboarding, your default owners and your dependent automations in a short session. Book a free Salesforce health check and leave with a list of fixes.