Direct answer
Every unused custom field costs something: a rep scrolls past it on each record, a report has to work around it, and someone eventually fills it in wrongly. To clean up, export a list of all fields with how often each is filled and where it is used, put each field through a keep, merge or retire test, consolidate messy picklists, cut required fields to the ones a process really needs, check every report, automation and integration that depends on a field before touching it, and retire fields in a set order. Finally, give field creation an owner, or the sprawl returns. This page is about fields. Stage design and duplicate records are separate jobs (see CRM fields for a service business for what a lean field set looks like, and merging duplicate CRM records for records).
Step 1: audit usage, not opinions
People will tell you every field is important. Data tells you which are actually used. Build one inventory sheet, one row per custom field, with these columns:
- Field name, object it belongs to (contact, company, deal, other) and type (text, number, date, picklist, checkbox)
- Fill rate: share of records where it has a value. Many platforms offer this in a field or property report; if yours does not, export and count in a sheet
- Recency: is it still being filled on new records, or only on old ones? A field filled in for old records and blank for anything recent has been abandoned
- Who created it and when, if the platform shows it, and who claims to use it
- Where it is used: views, reports, dashboards, automations, forms, integrations and imports. Check what your platform lets you see; some show field dependencies and some do not
- Whether it duplicates another field or the same information lives in a notes field
Step 2: apply a keep, merge or retire test
Put every field through the same short test so decisions do not become debates:
- Keep: it is filled on recent records, and someone can name the decision, report or automation that depends on it
- Merge: two or more fields hold the same idea under different names or formats, such as 'Lead source', 'Source' and 'Origin', or free-text and picklist versions of the same thing. Pick the survivor and plan a value mapping
- Retire: nobody can name what depends on it, it is rarely filled, or the answer can be worked out from another field. Also retire fields created for a one-off campaign or project that ended
- Fix: it is useful but poorly defined, such as a text field that should be a picklist. Do not retire it, redesign it
Fill rate alone is not a verdict
A low fill rate can mean an obsolete field or a field that only applies to a specific segment. Before retiring a rarely filled field, ask whether it is correctly optional for a niche case, such as a certification number that only matters for regulated clients.
Step 3: consolidate picklists
Picklists rot faster than fields. Look for values that differ only by spelling or case, values nobody has used for a long time, catch-all values like 'Other' that account for most records, and lists so long that people pick the first option they find. For each list, decide the final set of values, write a mapping from every old value to a new one, and apply the mapping to existing records in a test batch before the full run. Keep the final list short enough to choose from without scrolling, and add a rule for who may add a value.
Step 4: tighten required fields
Required fields are the most expensive kind because they slow every record creation. For each required field ask: is the process blocked without this at this moment? If not, make it optional at creation and required only at the stage where it is needed, for example a budget at proposal stage rather than at lead creation. Where your platform supports conditional or stage-based requirements, check how they work in your plan. Too many required fields also push reps to type 'n/a' and '.' into them, which is worse than a blank because it looks like data.
Step 5: check report and automation dependencies
Before you retire or merge anything, trace what depends on it. Look at reports and dashboards, saved views and filters, workflow and routing rules, email templates that insert the field, forms that write to it, and integrations that read or write it. A field that shows zero recent fills may still be the trigger for an automation, or the mapping target of a website form, and removing it silently breaks that flow. List the dependencies in your inventory sheet and clear them one by one before touching the field.
Step 6: deprecate in a safe order
Do not delete on day one. A sequence that leaves room to reverse:
- Export all field values to a file and store it, so retirement is recoverable in principle. LATYNEX does not promise data recovery after a delete on your platform; confirm what your CRM keeps and for how long
- Rename the field with a prefix such as 'ZZ_deprecated' and hide it from layouts and forms. See who complains
- Wait a defined period that fits your reporting cycle, at least one full cycle of any report that might use it
- For merges, run the value mapping in a test batch, review a sample of records, then run it on all records
- Archive or delete the field only after that period and after a final dependency check
Governance: stop it growing back
Fields multiply because creating one is easy and nobody owns the list. Name an owner for the field schema, usually an ops or sales-manager role. Require a short request for any new field stating the decision or report it supports, the type, the allowed values and who fills it. Review the inventory on a set rhythm, such as twice a year. Keep a one-page data dictionary listing each field's purpose and definition, so new hires do not guess. If you are also planning a move to a new platform, do this cleanup first: migrating dead fields only carries the clutter over, which is covered in CRM data mapping for migration.
When to bring in help
A field audit is a good internal task for a small CRM. It becomes harder with hundreds of fields, several integrations reading the same properties, or nobody who knows why they exist. The CRM Cleanup & Sales Workflow Setup package (€1,990, fixed scope) covers one CRM and one principal pipeline; larger schemas are scoped separately. See CRM & Sales Workflow Implementation.
Questions
How many custom fields is too many?+
There is no fixed number. The test is whether each field supports a decision, a report or an automation, and whether reps can find what they need on a record without scrolling past clutter. If most fields fail that test, you have too many.
Can we delete a field and get the data back later?+
That depends on your platform and plan, and we cannot promise recovery. Export the values before retiring a field, hide it before deleting, and check what your CRM keeps after deletion.
What is the safest thing to do first?+
Build the usage inventory and change nothing. Once the sheet shows fill rates and dependencies, most decisions become obvious and you avoid breaking a report you did not know existed.
Should we clean fields before migrating to a new CRM?+
Yes, in most cases. Cleaning first means you map only fields that matter and avoid carrying dead structure into the new system. The mapping document is where the final keep and drop decisions get written down.
Do required fields improve data quality?+
Only when they are truly needed at that moment. Overused required fields tend to produce placeholder values instead of real data. Require fields at the stage where they matter.