Will the real Kelly Bentubo please stand up?
With so many processes and alerts tied to a System Admin, many times an Org will just overwrite the user. We've all been there, right? I've run into this numerous times and this post will help you avoid the
potential pitfalls of the <gasp> USER OVERWRITE.
Here's a list of the items that must be changed in order for a Solo Admin to be deactivated:
Case Escalation
Case Assignment
Web-to-Lead Settings
Default Lead Owner (Lead Settings)
Lead Assignment Rules
Other items to consider:
Dashboard Running User
Report Scheduler
Email Alerts to Admin
Owner of Records
Although this takes time, it's a best practice. Why? Because of the following implications:
Chatter - Anything that the old Admin has ever posted, now appears next to your name. A bit confusing for end users when they ask a follow-up question on a post that existed before your time.
Success Community - An old Org of mine overwrote the license and I had a profile in Success Community with my name listed, asking questions and then members were tagging in my real profile in the answer. Very confusing for the new user and for me! We've all learned to post a photo next to our Active Profile in Success Community to help cut down on the confusion. There are additional implications related to # of Ideas posted and Questions Answered, which are tied to the license.
History - Any record updates or errors processed through the previous Admin, now appear as actions that you have completed. This is misleading and the same process goes for end users - don't shortcut the new user process, it disrupts your true Salesforce history. I've often wondered about compliance/legal issues related to this type of overwriting...
Access - Review your Sharing Rules and Permission Sets. This applies to regular user overwrites - you want to make sure that you're not extending access via an old license to a new user during an overwrite. The same goes for validation rules. As a best practice, I typically utilize Profile IDs to handle Validation Rule exceptions and append the Description to include details. I also utilize named users for groups referenced in my Permission Sets.
List Views/Reports - The new user is now inheriting all of the custom views and reports created by the last user. This can be a Pro for the new user to get up to speed on the critical items reviewed in the past. It's a Con if the previous user was targeting data for an initiative that the new user will not be pursuing.
So with all of these potential issues, why do we do it? Okay, first maybe there's a bit of laziness involved in taking a shortcut. The biggest benefit for an overwrite is that one person in literally swapped in for the old one, nothing else to update! As the platform continues to extend out and become more personalized through Salesforce Communities, Answers, Trailhead Points and Badges, etc., the issue of overwriting will become a much more complex debate.
Bottom line, it's not that hard. I promise! If you can spare a license during the transition, get setup as the new Admin. Run through the short list of items that need to be switched to your new license. Then feel free to login as the old user and checkout reports and list views to get up to speed.
Not to worry, if you try to deactivate the old license and have missed a step, Salesforce will alert you and include a handy link to the area that needs to be updated (ever try to delete a report that sits on a Dashboard? Or uninstall an AppExchange package that still has some fields on your page layout?)
