Over time, Salesforce orgs tend to become cluttered with technical debt and functionality that is no longer being used. The longer the technical debt and unused functionality is allowed to exist the more expensive it becomes because of confusion, complexity, and potential project delays.

Salesforce cluttering happens as a result of basically any of the following:

• Development / Administration not trained about Salesforce,
• Rapid delivery consistently prioritized over long term value,
• Heavy customization,
• Poor or lacking governance,
• Organization unaware of best practices,
• Inherited instances / mergers,
• lots of fields due to process gaps/misunderstandings/not knowing about what is currently there

Don’t worry, it’s possible to make a come back from Salesforce technical debt and clean up the org. Cluttered systems is a really good opportunity to improve the system, and really improve the business as a whole.

Reasons to Declutter The Salesforce Org

• Difficult to use. High number of fields, minimal data entry
• Bad Data, high levels of bad data leads to perception that all data is bad
• Changes – can’t disrupt business, unsure which fields are actually used, unclear who the stakeholders of certain features are today.
• Hard to maintain – hard to know how everything works

Possible Business Outcomes and Objectives from Decluttering Salesforce

• Easier to use
• Minimize required data entry, automate data quality 
• Increase trust, rep productivity
• Remove irrelevant legacy customizations
• Convert old custom code to native functionality
• Increase team understanding of org config
• Easier to maintain and administer
• Identify and close potential security gaps

Planning Before Paying Down the Technical Debt

Paying down technical debt can be really expensive and be really time consuming. It’s usually best to do it as a small project and focus on cleaning up one thing at a time.

Making data driven decisions is the key to creating a good outcome for the business. Start by identifying small quick wins that shouldn’t really impact anyone, this can be done by using automated tools to identify which fields aren’t used much, when the field was created.

One thing to keep in mind is that paying down technical debt in the Salesforce org will take longer than you think it will. You really need to avoid planning too aggressively and trying to do changes as part of agile processes so updates are happening every few weeks.

After you have cleaned up the org a lot, you should really consider making this an ongoing process as part of each sprint. This will allow the business to run a lot faster.

Identify & Communicate to Stakeholders

It’s really important to identify who your stakeholders are and make sure that you are communicating frequently with them and what the next steps will be.

It’s really important that you get buy-in from leadership for this project because you could be making some fairly large changes. It’s really important that you set clear expectations by creating a roadmap and a vision before you begin executing the project.

When communicating it’s really important to focus on the future and not what it is today. It will be different and hopefully a lot better as a result of these changes.

Create a Change Management Plan

All changes should be done in a sandbox and then pushed to a User Acceptance Testing sandbox. After changes are done to UAT, stakeholders should be able to access and review it to provide feedback.

Data Dictionary

Create a data dictionary of why you need certain fields, what department owns them, and what processes they are part of. The more you can document why you need and what you are doing with something will help you identify fields that can be removed.

Regression Planning & Test

• Testing – write a detailed regression test plan, engage with other teams, fully test before going to production
• Consider new Apex test classes, can help automate regression testing

Finding Items To Remove

System Overview, Schema Builder, Security Health Check, Salesforce Optimizer are all good free tools to use to asses the organization’s health.

By downloading all of the metadata for an org, it’s possible to determine whether a field is displayed and used anywhere. This can be done through Eclipse (Force.com IDE) or through the newer VS Code extension.

Basically, what you would do is search the metadata in your org to verify field usage in code/config/reports.

How to Remove Fields

Before deleting fields, we should spend the time to see if anyone is actually using them potentially outside of Salesforce. For example, DBAmp or Salesforce API integrations would break if somebody was using it outside of Salesforce.

The best way to do this is to hide fields via Field Level Security before removing and then delete after a period of time if nobody has noticed it missing. Before doing the delete, it’s really important to export all data with id prior to field deletion.

Backing Up Code / Metadata Configuration

Previously, backing up Salesforce code and metadata was pretty painful because of the lack of source control support.

Previously we would, create an old code Sandbox, keep it there as long as needed, delete all old, irrelevant code from live.

Now, you could probably download all of the metadata and push it into git or whatever source control system you’re using and keep an old branch around.

Fixing Underlying Process Problems

I find that a lot of the time that unnecessary fields and customizations are created, it’s the result of a communication breakdown because the Admin doesn’t understand the requirements or the Developer doesn’t understand the requirements.

One thing to keep in mind is that your users aren’t administrators, and your administrators aren’t the ones that will enter all of the data. It’s important to get feedback from users and adapt as you and the rest of the team understand the process and problems better. Don’t be scared to delete unneeded code, fields, or customizations.