← All articles

GTM Operations

Your CRM Has 47 Required Fields. Reps Fill Out 6.

Every required field is a tax on the 28% of the week a rep spends selling, and most of the fields get read by nobody. Here is the two-number audit that finds the tax and the one-line test that stops it coming back.

· 12 min read

Forty-seven required fields on the opportunity object. I pulled the populate rate on all of them last quarter. Six were filled above 90% of the time. Twenty-two sat under 20%. Nine had never been referenced by a single active report or dashboard. Reps were entering data into fields that fed nothing, gated by validation rules that blocked the save until they typed something, anything, into a box no human would ever read.

That is the part nobody prices in. A required field looks free because it costs an admin thirty seconds to check the box. The rep pays for it, not the admin, and the rep is the most expensive minute in the building. Reps spend only 28% of the week selling and about 41% on admin and internal busywork (Salesforce, State of Sales 2024). When I add a required field, I am taxing that thin slice of selling time to feed a report that in most cases does not exist.

So picture the whole surface at once. Every required field on the object as a dot in a field, and watch it collapse to the handful that earn their place. That collapse is the entire audit, and I will build the numbered version of it below.

47 fields dissolve to 6The required-field surface, collapsed to what earns its place
47The full mandate47 required fields on the opportunity. Every one blocks the save. Every one taxes the 28% of the week a rep sells.
47
Required fields on the opportunity
6
Filled above 90% of the time
28%
Of a rep week that is actual selling (Salesforce 2024)

The audit is two numbers per field

You do not need a maturity model for this. You need two columns.

The first is populate rate: of the records created in the last ninety days, what fraction have a real value in this field. Not a default, not “N/A,” a real value. In Salesforce you can get this from a report grouped by the field with a rowcount, or a quick aggregate query per field:

SELECT COUNT(Id) total,
       COUNT(Competitor__c) filled
FROM Opportunity
WHERE CreatedDate = LAST_N_DAYS:90

Divide filled by total and you have the populate rate. Anything under 20% is a field reps are actively refusing, and refusal is data. They are telling you it does not help them sell.

The second is reference count: how many active reports, dashboards, list views, routing rules, and automations read this field. This one is more work. You export the report metadata and grep the field API names, you check flow and validation rule definitions, you look at what the roll-ups roll up. A field with a populate rate of 4% and zero references is a field that should not exist, and no amount of nagging reps to fill it changes that.

When I ran this, the two numbers correlated almost perfectly. The fields reps ignored were the fields nothing consumed. Reps had already figured out which data mattered. The CRM config never caught up.

That correlation is the finding that makes the whole audit defensible. It means you are not overriding rep judgment, you are catching up to it. Reps are not lazy about data entry in some general way. They are precise about it: they fill the fields that come back to help them, the amount that drives their commission and the close date that drives their forecast, and they starve the fields that vanish into a database nobody queries. The populate rate is a vote, taken thousands of times a quarter, on which fields earn their keep. When you demote a 4%-populate, zero-reference field, you are ratifying a decision the sales team already made and enforcing it in the config.

Populate rate across the 47 required fields
Six fields carry real data. The long tail under 20% is the tax: fields reps refuse because nothing downstream reads them. Refusal is a signal, not a compliance problem.
View as table
ItemValue
Amount98%
Close Date97%
Stage96%
Next Step71%
Lead Source44%
Competitor12%
Use Case8%
Decision Process4%

The two-number picture, laid out as the audit table I keep. This is the reconciliation the hero animation is drawing: the top three fields are the disc that survives, the bottom three are the dots that dissolve.

FieldPopulate rateActive referencesVerdict
Amount98%40+Keep, load-bearing
Close Date97%40+Keep, load-bearing
Stage96%40+Keep, load-bearing
Next Step71%3Keep, earns its mandate
Lead Source44%6Keep, but fix the entry path
Competitor12%0Demote to optional
Use Case8%0Demote to optional
Decision Process4%0Remove

Bad data is not free either, so keep the real fields honest

The instinct when you hear “demote fields” is that data quality suffers. The opposite is true, because the fields you are cutting hold no real data anyway. Bad data is expensive on its own terms: B2B contact data decays at roughly 30% a year (ZoomInfo), poor data quality costs the average organization about $12.9M a year (Gartner), and 55% of business leaders say they do not trust their own data assets (Experian, 2024 Global Data Management report). A CRM stuffed with 4%-populate fields full of “N/A” is not high quality that you are about to wreck. It is the bad-data problem those numbers describe, dressed up as completeness.

Data problemValueSource
B2B contact data decay~30% per yearZoomInfo
Cost of poor data quality~$12.9M/yr per orgGartner
Leaders who distrust their data55%Experian 2024
Rep week spent selling28%Salesforce 2024

Cutting readerless required fields improves data quality by concentrating rep attention on the few fields that come back and get audited. Sparser and true beats complete and fictional.

The test that survives contact with a VP

Here is the rule I now apply to every request for a new required field: make it required only if a report or a routing rule reads it. That is the whole test. If a live report groups by it, filters on it, or sums it, or if a routing rule or automation branches on it, the field earns its mandate. If not, it goes on the layout as optional or it does not go on at all.

The one-line test Does anything downstream read this field?
”Make this field required”does a live report or rule read it?YESrequired, earns its mandateNOoptional until the report is real
A required field is a promise that someone downstream needs the value. If no consumer exists, the mandate is a tax with a nice name. Route every request through this one gate.

This test is useful because it moves the argument off opinion. When someone asks me to make Competitor required “so we have visibility,” I ask which report shows competitor win rates. If that report exists and someone reads it weekly, easy yes. If the answer is “we should build that,” then the field is optional until the report is real and someone owns it. Visibility that nobody looks at is not visibility. It is a tax with a nice name.

Validation rules are where the tax compounds

The populate rate tells you what reps skip. Validation rules tell you what they cannot skip, and that is where the real damage hides. I found an org with 60-plus active validation rules on the opportunity, several firing on every save regardless of stage, a few contradicting each other so that closing a deal required a specific dance of fields entered in a specific order. Reps had learned the dance. They also had a shared doc of dummy values that satisfied the rules without meaning anything, which is how you end up with fourteen opportunities where the next step reads “asdf.”

The dummy-value problem is worse than the empty-field problem, and it is worth being precise about why. An empty required field at least fails loudly: the save is blocked, the rep is annoyed, and you can measure the friction in the populate rate. A field satisfied with “asdf” fails silently. The record saves, the populate rate reads 100%, the dashboard shows a full column, and every number built on that field is quietly poisoned. You have converted a visible cost, rep friction, into an invisible one, wrong data feeding real decisions. That is a strictly worse trade, and it is the trade every unenforceable validation rule makes by default. The rep will always find the cheapest path through the gate, and if the cheapest path is a garbage value, garbage is what you will collect.

Bloat like that does not announce itself. Each rule was reasonable the day it shipped. Stacked, they turn closing a deal into a compliance exercise, and the rep pays the cost every single time, not once. I now treat validation rules the same as required fields: each one has to trace to a consequence someone can name. What breaks downstream if this value is wrong or missing? If the honest answer is “nothing, we just like it clean,” the rule comes off.

Here’s how I’d build it: the field-audit build

This is the audit I run on the two busiest objects every couple of quarters. Five steps that turn “the CRM feels heavy” into a demote list you can act on without a committee. It is the numbered version of the dissolve at the top: steps two and three measure which dots survive, step four clears the rest.

The field-audit build
  1. 1

    List every required field and rule

    Pull all required fields and all active validation rules on your two busiest objects (usually opportunity and account). This is the full surface area of the tax, the 47 dots in the hero field.

  2. 2

    Compute populate rate per field

    For each field, compute the share of records created in the last 90 days with a real value. Not defaults, not N/A. Sort ascending. Everything under 20% is a candidate for demotion.

  3. 3

    Count references per field

    Grep report and dashboard metadata, flow and validation definitions, and roll-up sources for each field API name. A field with low populate and zero references is proven dead weight.

  4. 4

    Demote the readerless fields

    Any field under 20% populate with zero references gets demoted to optional this week, no committee required, because you can prove no one consumes it. Remove the ones that feed nothing at all.

  5. 5

    Read the validation rules last

    Read every rule that fires on every save. Each must trace to a named downstream consequence. "We like it clean" is not a consequence. Retire the rules that gate the save for no reader.

What the trade looks like

The heavy config The audited config
Required fields 47, most read by nobody ~10, each with a named consumer
Data quality Complete-looking, full of "asdf" Sparser, but true
Rep time Taxed on every save Minutes back into selling
New-field request "For visibility," approved Gated by the reads-it test
Validation rules 60+, some contradictory Only those tracing to a consequence
Same objects, same reps. The audited config gives minutes back to the 28% and keeps only data that something reads.

What to do Monday

Pull the populate rate on every required field on your two busiest objects. Sort ascending. Everything under 20% goes on a list. For each one on that list, find the report or rule that reads it. The fields with no reader get demoted to optional this week, no committee required, because you can prove no one is consuming them. Then count your active validation rules and read the ones that fire on every save.

You will give reps back real minutes, and those minutes go straight into the 28%. That is the trade every time: less required, more selling. The org that trusts its reps to know what matters keeps less data and more of it is true. For the record-level version of this same “classify before you panic” discipline, see the owner-mismatch triage, and for the standard that keeps new fields honest before they ship, see the data contract for GTM.

salesforce data-quality

Keep reading

One email. Every week.

One email a week: an operating problem I solved or botched, with the model, the numbers, and what I would change. No roundups, no theory, unsubscribe whenever it stops being useful.

The newsletter opens soon.

Connect a provider in src/config.ts