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.

The short answer: pull three facts for every field: fill rate, last update and where it is used. HubSpot’s property export carries all three. In Salesforce, the Where is this used? button shows what references a custom field, and a report shows how often it holds a value. Keep the fields with a named owner and a written definition, hide the rest from layouts and forms, and archive whatever nobody asks about within 90 days.

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.

Why do CRMs collect so many unused fields?

Unused fields are not a natural consequence of growth. They pile up 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

I 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. That sync had spent years breeding duplicate records on both sides. 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: I 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 do too many CRM fields cost?

Too many fields cost selling time and reporting trust. 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.

How do you find unused fields in Salesforce and HubSpot?

Pull three facts for every field: how often it holds a value, when it last changed and what references it. Both platforms surface those facts natively, so the audit needs no new tool. Neither can tell you who owns a field or what it means, and that is the part that decides what stays. The numbers rank the candidates. The owner-and-definition test makes the call.

In HubSpot, start with Export all properties. HubSpot’s knowledge base, updated in June 2026, says the file lists each property’s name, type, group, creator, usages and fill rate, plus the last updated time and update source for contact, company, deal and ticket properties. That one spreadsheet is most of the audit. If you would rather start from a list, the Property insights tab in HubSpot’s data quality tools flags properties as duplicate, empty or unused. When you archive, read the panel: it shows the property’s fill rate and names the workflows or property cards that block the archive until you take the property out of them. Treat archive as a countdown. HubSpot permanently deletes archived properties after 90 days.

In Salesforce, open a custom field in Object Manager and click Where is this used? It lists the page layouts, flows, email templates and Apex code that reference the field, and Salesforce Ben’s field cleanup guide (October 2025) notes Salesforce will not let you delete the field until you remove it from those places. That shows wiring, not use. For fill rate, run a report that counts records where the field is not blank, or export the object and count. The same guide notes that Field Trip, an app built to find fields populated on very few records, is no longer on AppExchange.

The numbers mislead when you let them decide. A field almost nobody fills can be the one finance reconciles against every quarter, and a field filled on nearly every record can be a default value nobody has read since the day it was set.

Field and workflow hygiene is one of the 40+ 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.