When an Admin leaves your organization, it’s tricky to safely manage the many steps of that transition. It’s also easy to screw up which can lead to automation failing silently, users encountering errors, integrations breaking or the security of your system being compromised. Here are my recommendations when you’re left flying solo.

Transfer Knowledge and Map Risks – Ideally you’ll have time before their last day for this.

• The outgoing Admin should stop working on delivering new changes to the system 1 to 2 weeks in advance if possible.
• Learn what they have been working on recently and if they have projects that their replacement will have to finish?
• Are there particular parts of the Salesforce instance that they know that you don’t?
• Risk mapping: sit down with the Admin who is leaving and each of you should write down risks that you could face. Then write down possible solutions. This can also help you focus on important areas for knowledge transfer.
• What can they help document? Especially if they are the only one who knows how it works. This happens, more often than it should.

Freeze their User – Do this when they should no longer access the system, usually on their last day. This protects your database and isn’t as risky as deactiving the user. Remember: they also have active users in all of your sandboxes!

PREPARE Before you Deactivate

Do a Metadata Search: This is the easiest way to find everything the admin is linked to in your instance. To do this use an Integrated Development Environment (IDE), which  are the tools that developers use every day but can also be an Admin’s best friend. I do metadata searches almost every day at work to see all the places fields are used in automation or which reports they are in. They can be tricky to set up, but are worth the effort. Admin Hero has a blog post about setting up an IDE. This will show you where exactly their use appears throughout the metadata of your instance.

Automation: Their user may be written into workflows, processes builders, apex or flows, and ­the easiest way to find out where is with the metadata search above. Make updates to remove references to their user. Remember: Workflows, Flows, and Process Builder only send errors to the user who last modified them, this means you need to deactivate and reactivate all declarative automation they deployed to prevent them from failing silently. Update the Apex Exception Email so that you will be notified if errors occur with the code in your system. (See below)

Lead Queue, Web to Lead, and Case Assignment rules: Make updates if any include your old Admin.

Scheduled Jobs and Reports: Make updates and move scheduled jobs and reports onto your (or other) users.

Data Export: If they scheduled your data export, reschedule it. This is also a good time to make sure your data export includes all important data.

Dashboards: Don’t let your users see this message: ” Error: The running user for this dashboard is inactive. Your system administrator should select an active user for this dashboard.” Check your Dashboards and update the running user where necessary.

Integrations: Not everyone remembers to follow best practices and set up API users for external tools and integrations. Check to see if the old Admin’s user is connected to any integrations, your website or external tool. Remember: you should also update the passwords to the tools they had access to.

Company Information: Update the Primary Contact if needed.

Update Record Ownership: Admins can end up owning a lot of records thanks to automation and mass uploads. You need to either update the ownership so that your users can continue to use those records or allow users in your instance to edit records of inactive users. Which route you choose will depend on your business processes.

Last, but Not Least

Deactivate the user: You did it! You safely deactivated an Admin user!