Salesforce User Deprovisioning: The 12-Step Admin Checklist for Security and Compliance

Every employee departure is a security event. The average enterprise takes seven days to revoke Salesforce access after an offboarding — seven days during which a former employee's login, API tokens, and connected app sessions remain live. For a disgruntled departure, that is seven days of unrestricted access to your pipeline, your customer data, and your automations. In a regulated industry, it is also seven days of potential compliance exposure. Whether you are offboarding a single rep or managing a post-acquisition org consolidation that moves hundreds of users at once, the sequencing matters — and most orgs get it wrong.

Deactivation vs. freezing — understand the difference first

Freezing a user blocks their ability to log in but leaves the license active and the user record entirely unchanged. The user still counts against your license limit. Freezing is a temporary measure — right for a medical leave, a suspension pending investigation, or a contractor gap. It is not a deprovisioning action.

Deactivating a user removes login access and frees the license for reassignment. Deactivation is permanent in intent — you use it when someone has left the organisation for good.

What deactivating a user does not do is equally important to understand. It does not delete their data. It does not automatically reassign any records they own. It does not revoke OAuth tokens or connected app sessions that were established before the deactivation — those sessions remain technically valid until the token expires or is explicitly revoked. And critically: you cannot delete a Salesforce user. Attempting to delete a user throws an error. Deactivation is the permanent end state.

Steps 1–3 — Before you touch the deactivation button

Step 1: Audit their record ownership

Pull a report of every record owned by this user: Accounts, Contacts, Opportunities, Cases, and any custom objects in your org. Pay particular attention to open Opportunities with deal value attached, active Cases, and Accounts where this person is the named owner — these are the records that will become operationally invisible the moment you deactivate. Records owned by a deactivated user disappear from territory-based list views and trip assignment rules, creating silent failures that surface days later as "where did that pipeline go?" conversations.

Identify a temporary owner and document the transfer before you touch anything else. Assign it now — before step six.

Step 2: Export what you need

If the departing user managed key accounts directly, download their email-to-case threads and any email correspondence tied to open Cases. Export reports and dashboards stored in their personal folders — these are not accessible to other users and will be effectively lost on deactivation. Reports in personal folders do not transfer; they disappear. If those reports contain valuable team logic, recreate them in a shared folder before proceeding.

Step 3: Identify connected apps and API access

Navigate to Setup → Connected Apps → Manage, then click through each app and view the list of logged-in users. Revoke OAuth tokens for any session tied to this user explicitly. If this user is a named credential on any integration — Apex callouts that run under a specific user's session, external service credentials scoped to their login — update those integrations now. Their session will break on deactivation, and a broken integration discovered at 2 a.m. is a preventable incident. For broader security hygiene across your org, cross-reference the Salesforce security deadlines your org needs to meet.

Steps 4–6 — The deactivation sequence

Step 4: Transfer owned records

Use Salesforce's built-in Mass Transfer Records tool: Setup → Data Management → Mass Transfer Records. Select the object type, enter the departing user as the current owner, select the new owner, and run the transfer. Do this for each object type where the user owns records. For Opportunities, you can transfer open and closed separately — in most cases you only need to transfer open Opportunities, but confirm with the replacement owner.

Step 5: Reassign open Cases and Opportunities

For edge cases the mass transfer does not catch — queued Cases, Opportunities in unusual stages, records with sharing rules that exclude the new owner — use a SOQL query in Data Loader to pull a CSV and bulk-update ownership directly. A query like SELECT Id, OwnerId FROM Opportunity WHERE OwnerId = '[userId]' AND IsClosed = false gives you a clean working set. Update and re-import.

Step 6: Deactivate the user

Setup → Users → find the user → Edit → uncheck the Active checkbox → Save. That is the deactivation. The user loses login access immediately. The license is freed. Do not attempt to delete — as noted above, Salesforce will throw an error, and the user record is required for historical data integrity across every record they ever touched.

Steps 7–9 — What deactivation doesn't handle automatically

Step 7: Email-to-Case routing rules

If the departing user is named as a case owner in any Email-to-Case routing address configuration, new inbound emails will continue to assign cases to the deactivated user — silently. The case gets created, it gets assigned, and nobody sees it because the owner's list view no longer exists. Check Setup → Email-to-Case → Routing Addresses and replace any reference to the deactivated user with a queue or an active user.

Step 8: Approval processes

Any approval process with this user named as a specific approver will stall the next time a record hits that step. The submitter gets no error — the approval simply never advances. Navigate to Setup → Approval Processes → search for the user's name across all active processes. Replace named-user approvers with role-based or queue-based approvers wherever you find them. This is also a good moment to review whether any approval processes have this user as the only approver on a critical step — a single point of failure the Summer '26 admin checklist flags as an org health risk.

Step 9: Scheduled reports and dashboard running users

Dashboards in Salesforce run as a specific user — the "running user" whose permissions determine what data the dashboard displays. If the departing user is the running user on any dashboard, that dashboard stops refreshing on schedule the moment they are deactivated. Go to Reports & Dashboards → Dashboards → All Dashboards, filter by running user, and update every affected dashboard to a current active user with equivalent data access. Similarly, check for scheduled reports owned by the departing user and reassign or recreate their schedule.

Steps 10–12 — Compliance and documentation

Step 10: GDPR / CCPA — the right-to-erasure question

Deactivating a user is not the same as erasing their personal data. Under GDPR Article 17, if a former employee submits a right-to-erasure request, you are required to remove their personal data from Salesforce wherever it appears as field data — name, email address, phone number, mailing address — across the User record, any Contact or Lead records derived from their details, and any custom objects capturing personal information.

The User record itself cannot be deleted in Salesforce, but the name and email fields can and must be overwritten with anonymized values — for example, "Former Employee 2024-001" and "deleted-001@noreply.example.com". Salesforce has no native "GDPR delete" button. Without a custom solution or a managed package like Steward, this requires a manual field-by-field audit across potentially dozens of objects. Document every field changed and retain the audit log — regulators want to see evidence that the erasure was systematic, not ad hoc.

Step 11: Document and archive the offboarding

Create an offboarding record — a custom object, a Case, or a note in your ITSM system — that captures: who was deactivated, the exact timestamp, who approved the deprovisioning, what records were transferred and to whom, which integrations were updated, and whether an erasure request was processed. This is your audit trail. SOC 2 Type II audits specifically look for evidence that access was revoked promptly and that the revocation was authorised. "We deactivated them" is not sufficient evidence. A timestamped record with approver attribution is.

Step 12: License reclaim and 30-day verification

After deactivation, verify your license count decreased in Setup → Company Information. Then schedule a reminder for 30 days out: run a report of records still owned by the deactivated user. Stragglers are common — records created by automation after the deactivation, records missed in the initial transfer, or records in custom objects you overlooked. If you are on Sales Cloud Unlimited, run the Salesforce Optimizer after the 30-day mark to catch any remaining references to the deactivated user across org configuration.

Automating deprovisioning — don't do this manually at scale

Manual deprovisioning works when you are offboarding one or two users per quarter. It does not work when you are running a high-growth team, absorbing headcount from an acquisition, or operating in a sector with high employee turnover.

The automation path in native Salesforce starts with a Record-Triggered or Schedule-Triggered Flow on a custom Offboarding object (or an "Offboarding Initiated" checkbox on the User record). The Flow handles: updating the Active field to false, triggering a mass ownership transfer via an Apex action, updating routing rule references, and logging the offboarding record for audit. Flow cannot revoke OAuth tokens natively — that requires an Apex callout to the Salesforce Connected Apps API — but it can flag the tokens for review and generate a task for an admin to complete.

For orgs offboarding more than 100 users per quarter, the native Flow approach becomes fragile. Steward is QuickBild's managed package purpose-built for this volume: it automates the full deprovisioning sequence — ownership transfer, token revocation, routing rule updates, and GDPR anonymization — triggered by a webhook from your HR system. When Workday or BambooHR marks an employee as terminated, Steward fires the entire Salesforce sequence without admin intervention. The offboarding record, the audit trail, and the compliance documentation are generated automatically.

The 3 mistakes that create compliance risk

1. Assuming deactivation equals access revocation. OAuth tokens and connected app sessions established before deactivation remain technically valid. An integration or a personal script running under the departed user's token will continue to execute until the token expires or is explicitly revoked. Deactivation stops interactive login — it does not terminate programmatic access already in flight.
2. Skipping approval process and routing rule audits. These failures are silent. No error fires, no alert surfaces, and no user complains — until a deal stalls in an approval queue for three weeks or a customer's support email goes unresponded because it was assigned to a deactivated case owner. By the time the failure surfaces, the root cause is invisible.
3. No documentation. A verbal "we deactivated them on Tuesday" fails a SOC 2 audit. It also fails a GDPR investigation. Every deprovisioning needs a timestamped, approver-attributed record. Without it, you cannot prove compliance — you can only assert it, which is not the same thing.