At some point or another, an admin user is going to leave the company – it happens in almost every Salesforce org. Hopefully voluntarily, but sometimes not. And even if the person that needs to be deactivated is not the main System Administrator for your org, there are still a lot of steps that need to be taken before deactivating any sort of admin user.
My colleague Bart Lont here wrote a great article for Salesforce Ben about some of the main things that need to be completed before deactivating a user – definitely check it out for the initial steps.
In this article, we’re going to cover some key steps that may cause errors when you’re trying to deactivate. Remember, this article is in addition to Bart’s, so be sure to complete all steps in both articles if you need to deactivate an admin.
1. Make Sure You Have Another Admin!
Your admin is the person who is going to be able to make system changes as needed. Deactivating your only admin without setting up another will leave your org in a bind that is not easily fixed. Hopefully, you have a plan in place, or at least two people who are also admins, so this never happens, but if it does, make sure you have at least one active user who can be assigned an admin profile.
2. Sandbox First
Just like everything else in Salesforce, testing is best done in Sandbox first. Spin up a partial or even developer Sandbox, and attempt to deactivate the admin. If there are any problems during the process, Salesforce will show an error and let you know exactly what needs to be fixed.
When deactivating, you’ll only receive one error message at a time. For example, if your admin is listed under five email alerts, you might only get an error for the first one and think you’re done. But no, you’ll get errors every time you try until you get all the email alerts (even if Salesforce only shows you one of them!).
That’s why it’s also best to go through these steps in the Sandbox before deactivating. Create a list of all the items that need to be modified in Production, and all the errors you get in the Sandbox. This will tell you exactly what needs to be corrected in Production, and make it faster and easier to complete your work.
Errors will show up one at a time as you try to deactivate the user, so correct the issue, and then try again.
3. Reports and Dashboards
If the admin is leaving on a scheduled date that everyone is aware of in advance, it’s best to find out what scheduled reports and dashboards are running from their user, especially if they are emailed out to a management team.
You may need to move them to a different folder or change the running user altogether. Anything that the admin is running for their own information can probably just have the schedule removed. Or, you may need to log in as the user and check what reports and dashboards are scheduled to determine if they need to be reassigned or just canceled.
4. Process Automation
Check that your Default Workflow User is someone who is still active. Update if needed.
5. Lead Settings
The Default Lead Owner is the person who will become the Record Owner of a new Lead if you do not have Lead Assignment Rules, or if Salesforce is unable to determine who the proper Record Owner should be.
Check your Default Lead Owner, and make sure it’s someone still active. Update if needed.
6. Support Settings
Check out your Default Case Owner, Automated Case User, and Email for Automated Case User Notifications. Update as needed.
7. Web-to-Lead and Web-to-Case
The Default Lead Creator (or Case Creator) is the username that will appear in the “Created By” on Leads and Cases when a record comes in from the Web form. Be sure to check these sections even if you aren’t using these features.
8. Lead Assignment Rules and Case Assignment Rules
Remove this user from any Lead or Case Assignment Rules. (Yes, even the old, inactive assignment rules!)
9. Email Alerts and Flows
You’ll need to remove the admin from any email alerts where their specific username is included. This is a good idea for any Flows too – check for email components, exceptions, or criteria that include this person.
Optional Steps
These next couple of steps are optional. They aren’t going to cause errors during the deactivation process, but it would be good to do them anyway to help keep your org clean and maintain high data quality.
10. Validation Rules
Is your admin’s username or ID specifically called out in any Validation Rules? This is especially common in orgs where the Admin serves two roles: both Sys Admin and Sales Ops. Once their user is no longer active, exceptions for them are no longer needed and can be removed.
11. Reassign Records
In some instances, you may find that your admin owns a lot of records as a placeholder. You may want to consider reassigning those records to someone who will be able to manage them going forward.
I find a simple dashboard is helpful in this scenario, with components just displaying the number of records of all the different types owned by the deactivated administrator.
Final Thoughts
While deactivating a user might not be one of the most difficult tasks, deactivating an Admin user can have a lot of unexpected consequences.
Going through these steps and the steps mentioned in Bart’s article is the best way to prevent any disruptions during an admin change. Do you have any other tips for what to do in Salesforce when an admin leaves? Let us know in the comments below!
Comments: