Best Practices When Deleting Salesforce Customizations

1. Research

Once you have identified specific customizations that are no longer needed research needs to be completed to get a full view of where the customization is used. A sandbox is the best environment to start your research. Custom fields can be particularly difficult to research since they can be used in a variety of places. Here is a checklist of places to look for usage:

Astro Tip: When you try to delete a custom field in Salesforce an error message will show if any validation rules, formula fields, workflows, processes, field sets or Apex reference the field. Try this in a sandbox environment as part of your research.

• In a sandbox delete the customization. Salesforce will detect many different types dependencies like validation rules and workflows.
• If you are using a Source Control System like GIT or TFS try leveraging the search capabilities within those systems.
  In the Developer Console use the “Search In Files” function located in the Edit Menu.
• Leverage the Force.com IDE to inspect your code and metadata. The IDE has a text based search function to help you find places where fields, classes or methods are referenced in code and config. If you are unfamiliar with how this can work check out AdminHero’s recent blog post on “Searching Salesforce Metadata Using The Force.com IDE”.
• Use the Developer Workbench, which like many other apps can leverage the Metadata API to search your metadata.
  Check out the Salesforce Toolkit for a variety of additional helpful tools.
• Leverage SchemaSurfer, an AppExchange app that provides a way to browse and explore object metadata inside of Salesforce

You should be sure to test removing the customization in a sandbox. Check that all apex tests run successfully after removal. Don’t forget to test your inbound and outbound system integrations and to regression test any critical business processes after removal from a sandbox.

Once your research is complete you should have a list of all the places the customization is referenced with a plan on how to go about removing the customization and to update or remove any dependencies.

2. Communicate

Notify end users that the customization is being decommissioned. You can do this using a chatter post or as part of a regular newsletter. No matter how you send the communication, be sure to include a couple key pieces of data:

• The customization being decommissioned
• An explanation as to why it is being decommissioned
• Information on if another customization replaces what is being decommissioned
• A contact person to reach out to if anyone has any questions or concerns

You should also label the customization so it can be clearly seen within the UI that it is being decommissioned and inform users what the label signifies. In the case of a custom fields, objects or workflows you can update their labels with “OLD” or “TBR” for “To Be Removed.”

With classes or triggers, whose names can’t change add comments at the top of the file to signify a change.

Insert some text at the top of a Visualforce page to warn users of the pending removal.

Allow users some time (~15 to 30 days) after they have been notified to observe if any of their day-to-day work may be impacted.

Note: Be mindful here of Customer and Partner Communities that may have access to fields, Visualforce pages and other customizations you are decommissioning. Notification and labels presented to these groups may need to vary versus an internal audience. In some cases, no notification or label may be required and you can move to the next step of restricting access.

3. Restrict

Now that you have reached the point where the changes have been communicated and clearly labeled and no one has reported any issues with the change it’s time to remove access to the customization from users. This is an important step because it may save you time as opposed to deleting the customization at this point. Having to bring back something after it has been deleting is much harder than simply re-authorizing access to the customization.

For many customizations like workflows, triggers, processes, and validation rules you can simply make them inactive. For customizations like custom fields and objects, you can leverage Field Level Security and Profiles to ensure no users have access to the fields or objects. You can also remove fields, Visualforce components and Lighting components from apps and page layouts. Rights to Visualforce pages and apps can also be revoked via profiles.

4. Monitor

Now that access has been restricted the next step is to institute a waiting period of ~15 to 90 days as a safeguard before final removal.

In the case of custom fields and objects, make a backup of their data before and after the monitoring period so you can check for any change in the data. You can also use Field History here if you have available fields for tracking.

Be sure an Administrator or Developer has an action item scheduled at the end of the waiting period to do a final examination and ensure the customization is no longer being used.

5. Decommission

Time to remove your customization from production. At this point, you should have notified all users, labeled the customization appropriately, run through tests in your sandbox environments and restricted access to the customization for a period of time. While you should follow your standard lifecycle (SDLC) here are a few items to include when decommissioning a customization.

Start by backing up the customizations metadata and data (if any). To backup metadata you can use your Force.com IDE which can download metadata in the form of an XML file. This can be stored on a file system but an even better solution is to use a Source Control System like GIT to store code and config changes in your org. Data can be backed up in a variety of ways from exporting reports to leveraging the data loader to pull down a CSV file of the data.

Now that you have backed up the customizations metadata and data you are ready to delete the customization from your Org! Unfortunately, changesets can’t be used to delete customizations in Salesforce. So for the most part Administrators will have to leverage Setup to delete customizations. Alternatively, you can leverage the Force.com ANT Migration tool with a destructiveChanges.xml file to remove changes or one of the many 3rd party deployment apps available. In either case, you have reached the final step of removing the customization from production.