Deactivating user accounts can be an occasional pain, but deactivating a System Administrator user can be a nightmare. Depending on how long the individual has been with the company, and especially if they are a solo Admin, their name is probably associated with multiple critical settings and must be updated.

Aside from deactivating the user, there is quite a bit of work that should ideally be done before hand. Knowledge transfer is a critical component to replacing the Salesforce Administrator. Unfortunately, not many former Salesforce Admins get the opportunity to onboard their replacement. That is why documentation and training are vital parts of this process.

Transferring Knowledge

Two weeks (the typical notice timeframe in the United States) is not a lot of time to transfer a wealth of knowledge. Generally, there is little or no formal documentation existing in the organization, and there is too much tribal knowledge to make the transfer to a full-time or even temporary replacement efficient.

The departing Salesforce Admin should focus the majority of their time (or as much time as can be dedicated) to documentation. Use this opportunity to create or think through a documentation strategy if one doesn’t already exist. See How to Document Your Salesforce Instance for more details and ideas. Personally, I prefer a WIKI as a repository for this type of information. It can be edited by multiple people, can be published internally and lives online, so it’s never stuck on someone’s hard drive.

Here’s another great resource. My friend, Amber Boaz lead this session at Dreamforce 2015, and it’s worth watching; Best Practices for Documenting Your Salesforce Org.

However, before jumping into full-on documentation mode, the departing user should put together a document that outlines all of their existing open tasks and projects. If Salesforce is being used to track admin requests, run a report and discuss the list to determine what can be placed on hold, what can be transferred (if resources exist) and what will get completed. The idea is to map out what the existing workload looks like so that priorities and proper communication can be set.

Once this list is put together, the Admin user should spend as much time as possible on documentation. Start first with the business processes that keep the business afloat. What are the tasks that are done on a regular basis (such as manual deduplication of records or data exports), who are the recipients, and when is it done? I like to include details on specific configuration with the “logistics” of how a process works; referencing things like formula fields and workflows critical to the overall process being written about.

The documentation doesn’t have to all be extremely detailed. In some instances, it’s nice to have a general statement about a topic with a point person than it is to mention nothing at all.

During this process, the users’ manager and any other team members who will be filling in should sit with the user to go over the documentation, watch a demo of the process and ask any questions necessary to fully understand the logic. If a WIKI is being used, it’s the perfect time to collaborate and make adjustments so that everyone is on the same page.

Okay, now I know that some of you are thinking, “But, I’m a solo Admin. I don’t have the time to do all of this?”

Yup, totally get it. To be honest, you’ll probably work more in the next two weeks than you have in quite a while. To be honest, documentation should have been done on a regular basis to prevent this influx of work. Now that it’s time to leave, it’s only fair that the org is properly represented and the business can continue as close to usual as possible once you’ve departed. So, type as quickly as you can and attempt to transfer as much information as possible.

While the process of documentation is not easy (or fun), hopefully, it’s painful enough for the departing Admin user that they’ll learn a valuable lesson and document the heck out of their next org on an ongoing basis.

Deactivation Checklist

While it’s helpful to have a checklist, I can’t promise that this will be an all-inclusive list of items that need to be updated. Depending on your org and org settings, 3rd party contracts, and overall business process, there may need to be more that should be evaluated.

Don’t be afraid to leverage this checklist as a discussion point as well. There are several items that can be done before the Admin user leaves the building on their last day. Get some of the work completed ahead of time (where it makes sense) so that the process of fully deactivating the user doesn’t become a burden.

Company Information – it is possible that the departing Admin is listed as the primary contact for the Salesforce org. This will need to be changed before deactivation.

Default Lead & Case Creator – a default Lead and Case creator need to be set to have a fall-back owner. Even if the org is not using one of these objects, the default owner is set and must be updated to completely deactivate. Updating these defaults is as easy as selecting a different default user from the existing user base.

Dashboards – most dashboards will have a “running as” user assigned. Most of the time, this is the System Administrator. When the user becomes inactive, the entire dashboard or specific components may no longer work. The running as user should be reassigned before deactivation as to not disrupt others.

Big Deal Alerts – if these alerts are being used, ensure that all settings are updated as needed to deliver the big deal alert email on schedule.

Workflow Rules, Field Updates, and Validation Rules – many orgs still reference a specific user in their workflow and validation rules. This is a dangerous practice as users can fluctuate on a regular basis. It’s important then to validate that workflow rules don’t reference the specific Admin user and that any field updates where the user is specifically referenced are noted and updated accordingly.

Approval Process or Delegated Approvals – if the user was referenced as a delegated or assigned approver in any approval processes, these will need to be updated.

Scheduled Jobs – scheduled jobs where the user is referenced will need to be updated.

Weekly Export – weekly exports, which are an export of your Salesforce data, should be transferred as well if currently being managed by the Admin. Transferring the exports to a different user ensures no disruption in backup processes.

Web-to-Lead Default Creator – again, the user may be referenced as the default record creator on web to lead forms. If this is the case, the code should be updated.

Integrations – may integrations require a System Admin user’s credentials to make the connection between Salesforce and an external service, or the user’s Salesforce ID may be referenced direction in lines of code or other locations throughout integrations. All of these touch points need to be updated and validated before the user leaves. This information should also be included in the documentation.

While there are a lot of details to consider within Salesforce, there are just as many to discuss outside of Salesforce. For example, if this individual is the primary contact on any contracts (with Salesforce App partners for example), it’s important to contact those organizations and update the billing contact.

Be sure that access to the user’s email and desktop files are provided by IT to the manager, so that important communications and files don’t slip through the cracks. If possible, the user should set up an Out of Office response noting that he or she no longer works that the company and who to contact instead.

When the user does leave the office for the last time, be sure to freeze the user’s account fist. Freezing the account doesn’t deactivate the license, but it does prevent the user from logging in and will buy the team extra time to make the necessary updates to Salesforce before deactivating the account.

Do you have suggestions for items that should be considered when deactivating a Salesforce Admin in Salesforce? Leave a comment below!