Salesforce Developers Spring Cleaning Guide

If you’ve had Salesforce in your company for more than a few years, chances are that you have a load of customizations from previous users/uses that are now obsolete. As business priorities and processes change, customizations become irrelevant and simply occupy valuable space in your system. So, as your organization’s Salesforce developers, what should you do? Simply ignore them and hope they won’t interfere with today’s processes? I think not.

You’ll need to carry out a decommissioning process through which you can remove such customizations without interrupting the deployment throughout the organization. The first step is to identify the irrelevant customizations: Apex code, Visualforce pages, objects, custom fields, end-of-life features, validation rules, etc. Once you’ve done this, follow these best practices as you go through the five decommissioning steps described below:

Step #1: Research

Send an email or chatter post to let users of the customization know about the impending deletion. Ensure that your message outlines the customization, reason for deletion, any replacement thereof, and a person to be contacted with concerns or queries about it. You can either change names to show the customization within its environment or add a comment where the name can’t be changed. Allow two weeks to one month following notification so users can determine which part of their work is affected, if any.

Step #2: Communication

Send an email or chatter post to let users of the customization know about the impending deletion. Ensure that your message outlines the customization, reason for deletion, any replacement thereof, and a person to be contacted with concerns or queries about it. You can either change names to show the customization within its environment or add a comment where the name can’t be changed. Allow two weeks to one month following notification so users can determine which part of their work is affected, if any.

Step #3: Restriction

Next, eliminate access to said customization. It is easier to reauthorize a customization if found necessary than trying to recreate it after deletion. Many customizations allow you to simply deactivate them – validation rules, triggers, processes and workflows among others. For others like custom objects and fields, you can use Profiles and Field Level Security to limit access. Remove from page layouts and apps where possible.

Step #4: Monitoring

Institute a final waiting period following restriction to monitor effects before final deletion – about 30-90 days is appropriate. For custom objects and fields, ensure that their data is backed up before and after the monitoring phase and compare to find any changes. Ensure that there’s a developer and administrator tasked with the final examination and deletion after the waiting period lapses.

Step #5: Decommissioning

You probably have a standard lifecycle outlining the decommissioning, once the above steps have been followed. Begin by creating a backup of the customization’s data/metadata such as through the Force.com IDE that downloads metadata as an XML file. There are a variety of ways to back up; use what is most comfortable/procedural for you. The customization can now be deleted from your Org. Since you can’t delete using change sets, you have to leverage Setup for customizations deletion. You can also use Force.com ANT Migration tool that has a destructiveChanges.xml file, or any third-party deployment app to remove changes.

Congratulations, you have now safely decommissioned your customization. Rinse and repeat until your list is all done.

Author bio:

The author is a competent customer relationship professional with extensive knowledge of the Salesforce CRM platforms, including the Salesforce developers packages. In his spare time, he likes to travel and spend time with his family.