Open your CRM’s settings and scroll the field list. Skip the records, go to the schema itself. Most revenue leaders have done this exactly once, during an implementation years ago, and what they remember is the scrolling.
Most B2B CRMs I open could lose three quarters of their fields, and the sales team would take a month to notice. Some could lose more. That is an operator’s read from inside a lot of instances, not a survey result, and you should weigh it as one. But I keep finding the same shape in company after company: a few dozen fields doing all the work, and hundreds more sitting there because deleting a field takes a meeting and creating one takes a click.
How many CRM fields does a sales team need?
Fewer than a quarter of the ones you have, in most of the B2B instances I’ve worked inside. A working revenue motion needs the fields a rep reads before a call, the fields routing runs on, the fields reporting is built from, and the fields finance reconciles against. Everything else is sediment.
Fields feel free because storage is free. They are not free. Every field in your schema makes a claim on a human: someone has to fill it, someone has to read it, someone has to know what it means, and someone has to notice when it stops meaning that. When none of those people exist, the field does not go away. It sits there looking like information, and whoever builds a report on top of it treats it that way.
Every extra field is a decision someone skipped
Field bloat is not a natural consequence of growth. It accumulates because creating a field takes one click and retiring a field takes a meeting, so five admins across five years each chose the click. You have as many fields as you do because the people who built your instance before you built it the easy way, not the right way.
The pattern repeats in most instances I open. A new tool needs somewhere to write, so it gets a field. A workflow trips on a validation rule, so someone creates a workaround field to route past it, with every intention of coming back.
Nobody comes back.
Then a report gets built on the workaround, and now the workaround is load-bearing. The field that was supposed to live for a sprint becomes part of your revenue architecture, undocumented and unowned, quietly feeding numbers to a dashboard your board reads.
Fourteen ways to ask where a lead came from
We worked with a company that had run Salesforce and HubSpot side by side for years, with a live sync between them, before committing to HubSpot and migrating. After the migration, the instance held 1,532 fields.
The lookalikes were the first thing you noticed. The fields any rep touches daily each existed in four or five near-identical versions: one native, one synced, one imported, one built as a workaround for one of the other three. Behind the lookalikes sat hundreds of workaround fields, created to route past some constraint and never retired once the constraint moved. And then there was Source. The instance held fourteen distinct fields answering some version of the question “where did this record come from?”
Fourteen source fields turns marketing attribution into an argument. Which field wins when two of them disagree? The one that supports the story being told that quarter. Historical reporting becomes a spider web: every thread connects to another thread, and pulling any one of them to test it moves all the others. No single person at that company had done anything wrong. Each field made sense to the person who created it on the day they created it. Compounded across years and a two-system sync, the schema was no longer a record of the business. It was a record of every shortcut anyone had taken inside it.
The cut took a few weeks, not a quarter. When it was done, roughly 240 fields remained across contacts, companies, and deals. The fourteen Source fields became one: we evaluated what each of them held, consolidated the information worth keeping into a single source field, and moved the ongoing story into campaign and event associations, where a timeline belongs. The field answers one question now. The associations answer the rest.
What does field bloat cost?
According to Salesforce’s State of Sales, 7th edition, a survey of 4,050 sales professionals across 22 countries published in February 2026, high-performing sales organizations prioritize data hygiene at roughly 1.5x the rate of underperformers, 79% against 54%. That is a correlation, not proof of causation. But the direction matches what a bloated schema does to a team, because hygiene is impossible at 1,500 fields. You cannot define and maintain a schema that size. You can only survive it.
The survival tax is measurable. Validity’s State of CRM Data Management in 2025, a survey of 602 CRM users and admins across the US, UK and Australia, found workers spend 13 hours a week hunting for basic information in the CRM. Thirteen hours a week is not a data problem the way most people mean the phrase. It is a wayfinding problem. When a rep faces sixty fields on a record, they fill the four tied to their comp plan and satisfy the required ones with whatever the validation rule accepts. Ask your ops team how many records carry “N/A” or a single period in a required field. Those entries are what it looks like when a rep negotiates with a validation rule and wins.
Your sellers were short on selling time before the hunting started. We have written before about how little of a seller’s week goes to selling, and a bloated schema takes its cut of what remains. And when quota attainment misses, the postmortem runs on these same fields, which means the explanation for the miss gets built from the same sediment that helped produce it.
The cut costs nothing but nerve
Cutting field bloat requires no purchase. Export your field list with fill rates and last-modified dates, keep every field that has a named owner and a written definition, hide everything that has neither, and archive whatever stays unmissed for 90 days. Hiding before deleting matters. A hidden field that someone asks about within the quarter earns itself a definition and an owner. A hidden field no one mentions was already gone.
The meeting where this gets contested is predictable. Someone will defend a field on the grounds that it matters. The question that settles it is not whether the field matters but who read it last, and when. If that answer takes more than a minute to produce, you have your answer.
No vendor will hand you this project, because subtraction does not generate an invoice. An enrichment vendor’s pitch adds fields. A tool vendor’s integration adds fields. The advice to carry fewer of them has no natural salesperson, which is part of why schemas grow and rarely shrink.
Field and workflow hygiene is one of the 30 checks in our free CRM diagnostic. The connection is read-only, so it can count your fields without touching a single one of them.
Two fields named Source, or fourteen
Scroll your field list this week and count the versions of Source. If you find two, you are ahead of most of the instances I open. If you find fourteen, you have a decision to make: hand the schema to the next admin the way it was handed to you, or spend a week deciding what each field means and who owns it.
One of those choices compounds. So does the other one.