8 Reasons Why You Shouldn’t Delete an Empty Field

We all know that every user request, every new project, and every new managed package adds fields. It may be easy to add these fields, but it’s difficult (even dangerous) to delete fields because there is often very little intelligence around the implications.

So it’s far safer to leave the fields as they are; let’s explore this further.

The Temptation is Real…

Eventually, the number of fields on objects climbs until it hits the limits – that’s 100, 500, or 800 depending on the Salesforce edition. The question is: “Which fields can you delete?”

Whoa! Stop right there.

Take a moment to think about the question before you change anything. It’s not an easy question to answer, although it seems like the simplest answer is to look for fields with no data. You can do this manually or use one of several free apps. However, as Salesforce becomes more complex, integrated, and strategic, this can be a very risky approach.

“I deleted one custom field that blew up 40+ reports, 3 dashboards, and two weeks of my life.” – OrgConfession #707

Just because a field has no data, does not mean that it can be deleted. Below are eight situations where a field may be empty, but is still critically important for the org. Deleting it could have dire results, and these might not be apparent until it is way too late to fetch the field out of the recycle bin.

8 Reasons Not to Delete an Empty Field

The field could be:

1. A brand new field so it has not yet been populated.
2. A field used by an integration where it is populated then cleared.
3. A field only used at quarter-end or year-end, and not yet in use. 
4. A field used in intermediary calculation and cleared afterwards. 
5. A checkbox where the valid value is blank.    
6. A dropdown list where the valid value is blank.
7. Needed for an integration app to work because it is part of their default setup, but it is not used in your org.
8. Tied into automation or record types, and a nightmare to delete.

Now you can see why just relying on field population (e.g. the field is empty) could trip you up.

Where Is This Used?

Within Salesforce, the “Where is this used” button is available for custom fields, but not for standard fields. This button will show you where a field is referenced, for example, in a formula, page layout, or Apex class.

However, you need to be clear about the results. It uses the Dependency API which does not analyze all metadata (i.e. record types, reports, or dashboards) and it is only for custom fields. It does provide up to 2,000 results which should be enough!

Pay It Forward: Document Your Changes

If you document WHY a field was created and HOW it was used at the time of creation, then it is easier to evaluate if a field can be deleted downstream.

Description Field

It can be as simple as putting some notes in the Description field, which is available for many metadata items. This field should be used to document who uses the field or any linked automations, etc.

I know, this is ‘delayed gratification’ or ‘altruism’, because you don’t get any immediate benefit, but you do need to get into the habit of at least adding a description! That includes all of us when hosting demos, writing articles, developing Trailhead training, building Managed Packages, and extending the core platform.

Create a Metadata Dictionary

Often the Description field is not enough to describe why a particular piece of metadata was created and how it is used. You want links to existing documents, process diagrams, and screenshots. Plus, not every metadata type has a Description field. 

The advice from Salesforce optimization experts is to create a metadata dictionary for your orgs (production and sandboxes). This creates a central resource for storing all that documentation. The good news is that you can use the Metadata API to build the metadata dictionaries, whilst keeping it up to date and in sync. You can even create some automated documentation.

There are utilities to export the metadata into a spreadsheet, but keeping it up to date as each org changes can be a thankless task, particularly for an org of significant size.

Create Some Business Processes Maps

There is huge value in documenting business processes and how they relate to specific fields – “a picture tells a thousand words”. It is the WHY. A well-documented process is a living document. It will be very valuable when it comes to validating new user requests. It is also great training material that can be embedded in Salesforce page layouts. Check out this handy Trailhead badge on process mapping.

Create a Change Log

Every time you make a change you are building up technical debt. But if you are tracking the changes as user stories and linking them to the metadata items in the data dictionary, then you are providing yet more documentation that helps when it comes to deleting and cleaning up. Bear in mind that one user story could impact many metadata items. 

Again, you could use a spreadsheet for a relatively simple org that doesn’t change much, or you could create a custom object. But do not underestimate the discipline required to keep it up to date when you are under pressure to deliver new features. Instead, ensure that updating your change log is part of your development process!

Do Your Detective Work Before Deleting

Here is a list of the different areas where you can look for clues to complete a more comprehensive analysis. And as you do this detective work and find out something useful, document it. 

• Field population: Is it empty and when was it last populated?
• Field “Where Used”: Is the field used in other metadata i.e. formula fields, automation, validation rules, record types, and reporting?
• Field dependency: What metadata is dependent on this field i.e. formula fields, automation, validation rules, record types, and reporting?
• Process diagrams: What processes is it used in, and who is using it?
• Stakeholders: Who owns it and can they tell you if it is still important?
• External documentation: Are there requirements, user stories, specifications, process maps, or diagrams that refer to the field?
• Feedback and requirements: Is there any user feedback about the field or requirements to change it?
• Change log: When was it created and last modified, and by which users?
• Integration documentation: It is used in or required by any integrations?

This seems like a huge list and it can be time-consuming to do manually, bouncing around Salesforce Setup and keeping track in a spreadsheet. However, there are tools that can help you, as much of this can be done automatically. These tools leverage the Salesforce APIs and have custom code to fill in the gaps. They are called Change Intelligence Platforms and are a new emerging category.

What Is a Change Intelligence Platform?

Change Intelligence Platforms automatically analyze and build a metadata dictionary, augmented with automated documentation. They also provide the ability to document any information that cannot be created automatically, such as stakeholders, or linking external documentation as you find it. Change Intelligence Platforms can perform the analysis every night, so you are always working off the most up-to-date information.

If at this point you are saying, “I cannot afford tooling”, then it is likely that you just don’t have the budget (not that you can’t see the benefits). There are multiple benefits including faster, automated, comprehensive analysis. The time saved and risks avoided may be enough to create a solid business case for purchasing a Change Intelligence Platform.

The cost benefit case is an easy calculation: It is your time vs the cost of the Change Intelligence Platform app.

Your Time =

• Time to maintain the documentation/metadata dictionary +
• Time to perform the “where used” and impact analysis for a metadata item (each time) +
• Time to troubleshoot and fix the org if you missed something and the org breaks +
• The cost of the downtime to business users if you missed something and the org breaks

Change Intelligence Cost

• It takes two minutes of effort to set up the connection to the org.
• A metadata dictionary is created and performs the analysis automatically.
• An analysis is performed every night, picking up changes that were made and highlighting them – up-to-date information is always available.

“I used to take 2-3 hours to analyze the impact of a metadata item. With Elements, it takes 2-3 minutes.” – Salesforce Consultant

Elements.cloud is a Change Intelligence Platform. Whilst it is not free, it is affordable for even the smallest org, and we have a license specifically for consultants. Talk to us about a free Proof of Concept.

Summary

One aspect of optimizing your org is deleting fields. It is good practice to clean up unused fields but it may become an urgent necessity as you hit field limits. Increasingly complex orgs mean that you need to ensure you investigate a field fully to understand the potential knock-on effects of deleting it. 

Do not get fooled into simply deleting fields with no data! You can do the analysis in spreadsheets and free apps, but using a Change Intelligence Platform will provide far more comprehensive, automated analysis, with fewer errors.