· Salesforce Guide · 7 min read
Everything to Check Before Deactivating an Admin User in Salesforce
Deactivating an admin user without proper preparation can break critical business processes. Here's a comprehensive checklist of all areas that will fail if not first addressed.
Critical Checklist: What Breaks When You Deactivate an Admin User
Deactivating an admin user in Salesforce can immediately break automation, integrations, and business processes if that user is referenced anywhere in your configuration. Before deactivating, you must identify and reassign all dependencies. Here’s everything that may fail:
1. Approval Processes
What Breaks: Any approval process with the user as a designated approver will fail when records reach that step. Records will become stuck in “Pending” status, blocking business processes. For example, if an admin is the sole approver for discount requests over 20%, those approvals will fail immediately upon deactivation.
Where to Check: Setup → Approval Processes → Review each process’s approval steps
Action Required: Replace the user with another approver, a queue, or a dynamic approver (like Manager field)
2. Integration Users & Named Credentials
What Breaks: External integrations using the deactivated user’s credentials will fail immediately. This includes API integrations, OAuth connections, and any third-party systems authenticating as the admin user. An API integration using the admin’s credentials to connect to Salesforce will stop working, breaking third-party connections instantly.
Where to Check: Setup → Named Credentials, Setup → Connected Apps, Setup → Auth. Providers. Look for any OAuth connections under Setup → the Admin User’s page → Login Attempts; these will point you to automated connections and you may need to identify their source and change the configuration in the external system.
Action Required: Create a dedicated integration user and update all named credentials and connected apps
3. Flow Automation
What Breaks: Flows that reference the user in assignment elements, email alerts, or as the running user will fail. A flow that assigns cases to the admin user will error out, leaving cases unassigned and breaking your support process.
Where to Check: Setup → Flows → Review all active flows
Action Required: Update user lookups, assignment elements, and email “from” addresses to use an active user
4. Apex Code References
What Breaks: Apex classes or triggers that hardcode the user ID or query for the user will fail. A trigger that sends notifications to a hardcoded admin user ID will fail, potentially breaking critical business logic.
Where to Check: Developer Console → Search codebase for the user’s ID or username
Action Required: Update code to use a different user, custom setting, or remove hardcoded references
5. Custom Metadata & Settings (User References in Flows/Code)
What Breaks: Custom metadata types or custom settings that reference the user ID will fail if used in formulas or code. A custom setting that stores the admin’s user ID to be used for assigning cases in flow will break the next time it runs if the user has been deactivated.
Where to Check: Setup → Custom Metadata Types, Setup → Custom Settings, Apex Code, Flows. Best option to check all at once is to use something like VSCode to pull down all the org’s metadata. Then you do a global search across the files for references to the admin’s ID or name.
Action Required: Review and update any hardcoded user IDs or user lookups in metadata
6. Assignment Rules (Lead & Case)
What Breaks: Assignment rules that route records to the deactivated user will fail, leaving records unassigned. Leads from a specific region assigned to the admin will remain unassigned, breaking your sales process and potentially losing opportunities.
Where to Check: Setup → Lead Assignment Rules, Setup → Case Assignment Rules
Action Required: Replace the user with an active user or queue
7. Escalation Rules
What Breaks: Escalation rules that assign cases to the deactivated user will fail. High-priority cases that escalate to the admin will fail to escalate, potentially violating SLAs and leaving critical issues unresolved.
Where to Check: Setup → Escalation Rules
Action Required: Update escalation actions to assign to an active user or queue
8. Email Alerts
What Breaks: Email Alerts that send emails “from” the deactivated user will fail. A workflow that sends emails from the admin user will fail to send, breaking customer communication workflows.
Where to Check: Setup → Email Alerts
Action Required: Change email alerts to use a different user or system email address
9. Queue Memberships
What Breaks: If the user is the only member of a queue, records assigned to that queue cannot be processed. A support queue with only the admin as a member will have no one to process cases.
Where to Check: Setup → Queues → Review all queues
Action Required: Add other users to queues where the admin is a member, or remove the admin from queues
10. Scheduled Jobs (Apex & Flow)
What Breaks: Scheduled Apex classes or scheduled flows that run as the deactivated user will fail. A nightly data sync job running as the admin will fail, breaking critical data operations.
Where to Check: Setup → Apex Classes (check @future and scheduled methods), Setup → Scheduled Jobs
Action Required: Reschedule jobs to run as a different user or system context
11. Data Loader & Integration Operations
What Breaks: Scheduled data loader operations or integrations running as the deactivated user will fail. Nightly data imports using the admin’s credentials will fail, breaking data synchronization.
Where to Check: External tools (Data Loader, ETL tools) configured with the user’s credentials
Action Required: Update credentials in all external tools to use a dedicated integration user
12. Platform Event Subscriptions
What Breaks: Platform event subscriptions running as the deactivated user will fail. Real-time integrations listening to platform events will stop receiving updates.
Where to Check: Setup → Platform Events → Review event subscriptions
Action Required: Update subscriptions to run as a different user or system context
13. Delegated Approvers
What Breaks: If the admin is set as a delegated approver, those delegations will fail. Approvals delegated to the admin when the primary approver is unavailable will fail.
Where to Check: User record → Delegated Approvers related list
Action Required: Remove the admin as a delegate or update delegation settings
14. Territory Management Assignments
What Breaks: Territory assignments that include the deactivated user will fail to route records correctly. Accounts assigned to territories with the admin will fail to route to sales reps.
Where to Check: Setup → Territory Management → Territory Assignments
Action Required: Remove the user from territories or reassign to active users
15. Record Ownership
What Breaks: Records owned by the deactivated user will only be editable by others where sharing rules permit. Critical opportunities or cases owned by the admin will be locked, preventing updates.
Where to Check: Run reports to find all records owned by the user across all objects
Action Required: Mass transfer ownership to an active user before deactivation
16. Custom Object & Field Defaults
What Breaks: Default values in custom objects or fields that reference the user ID will fail when creating or updating records. A custom field with a default value of the admin’s user ID will fail to populate.
Where to Check: Setup → Object Manager → Review default values and formulas
Action Required: Update default values to use a different user or remove the reference
17. Sharing Rules (Owner-Based)
What Breaks: Sharing rules based on record ownership by the deactivated user will stop working. A sharing rule that grants access to records owned by the admin will stop functioning.
Where to Check: Setup → Sharing Settings → Review all sharing rules
Action Required: Update sharing rules to use different criteria or remove user-specific rules
18. Chatter & Collaboration
What Breaks: @mentions of the deactivated user in Chatter posts will fail, and the user cannot receive notifications. Automated Chatter posts that @mention the admin will fail silently.
Where to Check: Chatter feeds, groups where the admin is a member
Action Required: Remove @mentions or update collaboration workflows (less critical but can cause confusion)
19. Knowledge Article Ownership
What Breaks: Knowledge articles owned by the deactivated user may become inaccessible depending on sharing settings. Published knowledge articles owned by the admin may become uneditable.
Where to Check: Setup → Knowledge → Review article ownership
Action Required: Transfer article ownership to an active user
Closing Thoughts
Deactivating an admin user requires systematic review of every automation, integration, and configuration that references that user. Missing even one reference can break critical business processes. Before deactivation, create a dedicated integration user for system operations, transfer record ownership, and thoroughly test all automations after making changes. Consider using Salesforce’s “Find References” feature in Setup, or searching across the metadata files for references to the user. Always complete changes in a sandbox first if possible.
