The CRM Field Audit: Which Fields to Kill Before They Kill Your Reporting

‍TL;DR: A field audit sorts every CRM field into one of three categories: actively used and trustworthy, unused and harmless, and unused but actively corrupting reports because something still references it in outdated logic. The first two categories are fine to leave alone or archive at leisure. The third category is the one that needs immediate attention, because a dead field still wired into a workflow, a report, or a scoring model produces wrong numbers that look completely normal until someone traces the specific calculation back to its source.

‍

A CRM that's been in use for more than a year or two accumulates fields the way an attic accumulates boxes: added for a specific, forgotten reason, never cleaned out, and eventually indistinguishable from fields that actually matter. Most companies know this vaguely and do nothing about it, because auditing every field feels like a large, undefined project. It's actually a specific, three-category sorting exercise that takes less time than most teams assume.

Why "we should clean up the CRM someday" never actually happens

Cleaning up CRM fields sounds like an all-or-nothing project: audit everything, decide on everything, fix everything. That scope is what makes it easy to postpone indefinitely. The actual useful version of this work isn't cleaning every field; it's specifically identifying which unused fields are still silently feeding into a report, workflow, or scoring model, since those are the only ones causing active harm. Everything else, used fields that work fine and unused fields sitting inert with no downstream effect, can wait.

The three-category sort

Why the third category is where the real damage lives

A field that's simply unused causes no harm on its own; it's clutter, not corruption. A field that's stopped being actively maintained but is still referenced somewhere in a live report or workflow is a different problem entirely: the report or workflow keeps running, producing output that looks completely normal, while quietly calculating against data that's stale, incomplete, or no longer meaningfully connected to current reality. purple path's breakdown of how bad HubSpot data quietly corrupts demand gen reporting covers this exact failure pattern from the reporting side; the field audit described here is the specific diagnostic step that catches it at the source, before it shows up as a misleading number several layers downstream.

How to actually find fields in the third category

Finding fields that are dead but still wired in requires checking two things for every field: when it was last meaningfully updated across a sample of records, and whether it appears in any active report, workflow, or scoring formula. A field that hasn't been updated in the last six months but still appears as a filter criterion in a live report is a strong candidate for this category. The check itself is mechanical: export a report showing last-modified dates by field where possible, and cross-reference that against a list of every field referenced in current workflows and reports, which most CRM platforms allow you to search or filter for directly.

Why a lifecycle stage field is the single highest-priority field to check first

Of every field type in a typical CRM, lifecycle stage deserves the first and most careful check, since it usually feeds the most downstream reports and workflows simultaneously: pipeline reporting, lead routing, and marketing-to-sales handoff logic frequently all depend on the same lifecycle stage field. A lifecycle stage definition that quietly stopped matching how sales actually works a deal, without anyone updating the underlying field logic to match, corrupts every report and workflow built on top of it at once, which makes it the single highest-leverage field to verify first in any audit.

Why custom properties added for a single, one-off campaign are the second-highest risk

Custom properties created for a specific campaign, a particular event registration field, a one-time survey response, tend to get built quickly, used for a few weeks, and then abandoned without anyone formally retiring them. These fields rarely cause dramatic damage on their own, but they accumulate quickly, and a CRM with dozens of these single-use fields becomes considerably harder to audit thoroughly the longer they're left in place, since each new one adds to the total surface area anyone doing a future cleanup has to check.

A practical audit method that doesn't require a specialist tool

A basic field audit can be run with a spreadsheet and a few hours of focused attention: export the full list of CRM fields, note the last-modified date pattern for each based on a sample of records, and separately list every field referenced in current reports, workflows, and scoring logic. Cross-referencing these two lists surfaces the third category directly: fields showing up in the "referenced by something active" list that also show up in the "rarely updated" list. This doesn't require specialized software, just a deliberate hour or two spent cross-checking two lists that most CRM platforms can export without much difficulty.

Why this audit should happen before, not after, a major CRM migration or tier change

purple path's breakdown of what breaks during a HubSpot tier migration covers how existing custom properties can interact unpredictably with new default fields introduced at a higher tier. Running a field audit before any planned migration specifically reduces this risk, since it's much easier to retire or document a dead-but-wired-in field while its context is still fresh than to untangle a conflict between an old custom property and a new default field after the migration has already introduced confusion.

Who should actually own this audit

A CRM field audit sits squarely inside the systems ownership responsibility covered in purple path's three-role RevOps framework for Series A companies. It's specifically the kind of unglamorous, structural maintenance work that a systems owner should be running on a recurring basis, not a one-time project assigned to whoever happens to have spare time during a slow week.

Why documenting the audit results matters as much as running the audit itself

Running the audit once and fixing what it finds is valuable, but the benefit compounds if the results get written down somewhere the next person to touch the CRM can actually find, rather than living only in whoever happened to run the audit's memory. A simple running document listing every field, its purpose, its current status, and the date it was last reviewed turns a one-time cleanup into a durable reference that makes the next audit faster and reduces the odds of the same dead-but-wired-in problem recurring silently a year later.

Why new fields deserve a naming and documentation convention going forward

A field audit fixes the past; preventing the same problem from recurring requires a small discipline change going forward. Requiring that any new custom property include a brief note on its purpose and an expected retirement date, if it's tied to a specific one-off campaign, makes future audits considerably faster, since the person running the next review isn't starting from zero trying to reconstruct why a given field exists. This is a small process addition that costs almost nothing to implement and meaningfully reduces how much clutter accumulates between audits.

Frequently Asked Questions

How often should a full field audit be run?

An initial full audit is worth running once as a baseline, then a lighter check focused specifically on lifecycle stage and any fields feeding active reports is worth repeating quarterly, since new custom fields tend to accumulate steadily and small drifts are much easier to catch early than after a year of unchecked growth.

Is it safe to delete a field in the "unused and inert" category immediately?

Archiving is generally safer than outright deletion, at least initially, since some CRM platforms retain historical data differently depending on whether a field is archived or deleted, and a field that appears unused in a recent sample of records might still hold historically meaningful data on older records worth preserving.

What's the fastest way to check if a field is referenced in a workflow without manually opening every workflow?

Most CRM platforms, including HubSpot, offer a search or dependency-check feature that shows where a specific property is used across workflows, forms, and reports. Using this built-in feature is considerably faster than manually opening every workflow to check for references individually.

Should this audit be run internally or by an outside specialist?

Either can work, but whoever runs it needs enough historical context to recognize why a specific field was created in the first place, since some fields that look obviously dead to an outsider may actually still matter for a specific, less obvious reporting need that isn't immediately visible from the data alone.

How does this audit connect to broader CRM data hygiene work like deduplication?

Field audits and deduplication address different problems, dead fields corrupting logic versus duplicate records inflating counts, and both are worth running as part of a broader CRM cleanup practice, though they can be tackled as separate, sequential projects rather than one combined effort.

‍

Running this three-category sort on your own CRM is a focused half-day project that can prevent months of quietly corrupted reporting. Talk to purple path about auditing your current field structure before it corrupts your next quarterly report.