When is a Salesforce Field no longer useful?

One of the many advantages of CRM systems is that it is very easy for business users to add additional fields. One of the main disadvantages of CRM systems is that it is very easy for business users to add fields without giving thought to the ‘bigger picture’.

In this blog post we will discuss our approach for determining when to remove fields from the system.

TLDR: The basic principal is that when a field is no longer trustworthy, is there any point in keeping it in your production system?

Can we trust this field?

A field is untrustworthy if you (and anyone else) cannot find a consistent process for populating or maintaining that field despite reasonable efforts to do so.

Let’s take an example of an Account field that says “Number of employees at this location” and some of the questions we’d ask to determine how much we trust it:

1. Who collects/populates it?

Is it the Sales Rep? Is it the marketing department? Is it from a third party data provider?
– Don’t know and can’t find out? Back it up and delete it!

2. When is it collected?

At time of record creation? When the Account becomes a customer? When there’s an opportunity?
– Nobody knows? Remove it.

3. When was it first ‘put into production’?

This is vital if we are doing any kind of historical analysis.
– If the field is only there for trend analysis and the data appears patchy then it’s useless.

4. When was it last updated?

What’s the worst case?
– No historical value? Lose it.

5. Do we actually understand what the field means?

Is it unambiguous?
– If no one can understand what the field means, it’s useless.

Do we understand what the field means?

If you’re interested in a deep dive on field naming, see our previous post on field naming conventions.

In short, what we must do is look at the field name/label and determine if the question used to populate the field is at all ambiguous.

Even if the IT/IS/Sales Ops department understands the meaning of the field, do the people who are actually populating it? What about users who primarily speak different languages?

We work with a number of organizations and see lots of different field naming conventions. An example of an ambiguous field we saw recently was on an account that simply said “MSP Customer”. MSP means Managed Service Provider. Due to the client’s channel sales model, it was not clear if this field meant the account was a “Managed Service Provider” themselves or if this account was effectively an indirect customer since they purchased through a Managed Service Provider.

If we cannot understand what the field means, we cannot fulfil its purpose. Ultimately this not only wastes time but can also lead to inaccurate reporting, misinterpretation and misinformed business decisions.

What is the purpose of having a field anyway?

Let’s finish up by reminding ourselves of the basics. We believe there are two key purposes for having a field in a CRM:

1. To mark a record as being at a certain stage in a process and/or
2. To record data for later analysis (reporting).

If a given field is not adding any value to a current business process and it has no historical value for the reasons listed above, back it up and delete it before someone makes a business decision based on its content!