Field notes
You have 722 CRM properties. You need about 200.
One audit found 722 custom properties, 203 of them empty - most CRMs carry far more fields than anyone uses.
Most CRMs accrete far more properties than anyone uses. Run a Keep/Cut audit in order - usage, then dependency, then decision value - and bias hard toward deleting, because every field you keep is a cost you pay forever.
On this page
The last CRM I audited had 722 custom properties. About 200 of them earned their place. The rest were boxes a rep had to scroll past - or worse, fill in - every time they opened a record.
If your number is anywhere near that, you have too many properties. That turns into a data problem the day you start asking people to fill in fields nobody needs.
The fix is a Keep/Cut audit, run in a fixed order, with a heavy bias toward cutting. The bias is the part that matters, and you can run the whole thing without losing a month to meetings.
Nobody designed 722 properties. They accreted.
No one sat down and specified 722 fields. It happened one reasonable request at a time - a campaign needed a field, a new hire wanted the one their last CRM had. Every single one made sense on the day it went in.
None of them ever got removed. Adding a field feels free and pulling one feels like a risk, so the count only ever climbs. It's the same accretion behind most messy HubSpot CRMs, built in small sensible steps by people doing their jobs.
Every property is a tax, not an asset
The instinct says more fields mean more data, and more data has to be better. Most of those extra fields cost you more than they ever give back.
Every property a rep can see is a small decision you've handed them: fill it in, skip it, or guess. Multiply that across a form with sixty fields and you've taught the team that data entry is something to get through as fast as possible. Your best reps resent it and everyone else just clicks past without reading.
A required field nobody understands rarely gets left blank. It gets filled with whatever makes the form submit so the rep can move on. An empty field would at least tell you the truth. Garbage looks exactly like data, and it's what you'll be building your reports and forecasts on later.
An unused property still does damage - it's an open invitation to enter something wrong on a record you'll trust later.
How to run the Keep/Cut audit, in order
The order is the whole method. Do it out of sequence and you will waste a week arguing about fields that should have been cut in the first ten minutes.
First, usage. Pull the fill rate for every property. Anything empty or near-empty goes straight on the cut pile. In that 722-field audit, 203 were completely empty, never populated once, and those you can delete without a meeting.
Second, dependency. For whatever survives the first pass, check what relies on it. Workflows, reports, integrations, required-field settings. A half-empty field feeding a live report can stay - but now you know exactly why it exists, which you did not before you looked.
Third, decision value. For the fields that are both used and depended on, ask the last question: does anyone actually make a decision from this? If a property changes nobody's behaviour, you're keeping it out of habit, and habit isn't a good enough reason to carry a field.
Run it in that order and most of the cutting happens in the first pass, which is why the empty fields are the obvious place to start and the one almost nobody bothers with.
Why deleting beats maintaining, every time
You could keep the 500 and promise to govern them properly, but that resolve never survives contact with a busy quarter. A field you keep is a permanent cost: someone has to keep it clean and stop it drifting as the business changes underneath it. Every one you hold onto is a small liability you're carrying.
Deleting is the only move that actually reduces the load. Cleaning, documenting, training, adding validation rules all pile on more work, while removal takes work away, and when you're genuinely unsure that asymmetry is what should decide it. Cut a field you turn out to need and you've lost an afternoon rebuilding it. Keep 500 you don't need and you pay for them every day.
Archive first if it makes you nervous. Hide the field for a quarter and delete whatever nobody missed. Just be honest that archiving is a step toward deletion, not a parking spot - a field kept "just in case" is still clutter, only with a tidier excuse attached. The full property teardown is written up as a CRM audit case study if you want to see the method run end to end.
You don't need 722 properties, and you never did. Start with the 203 empty ones, because nobody is going to miss a box they never once filled in.
Common questions
How many CRM properties should I have?
There's no fixed number, but most CRMs carry far more than they use. One audit found 722 properties where about 200 earned their place; the honest test is whether anyone makes a decision from the field.
Should I delete or archive unused CRM properties?
Archive first if you're nervous - hide the field, wait a quarter, delete what nobody missed. But treat archiving as a step toward deletion, not a permanent home, or you've just relabelled the clutter.
Why do unused CRM fields cause problems?
A required field nobody understands gets filled with whatever makes the form submit, so garbage ends up looking like real data. Every field you keep also has to be governed forever, which is why cutting beats maintaining.