Why this matters
Every unused CRM field adds a decision at data entry. It asks a rep to guess, skip or type something no report reads. Over time the record layout becomes a museum of old requests: a field for a trade show that ended, a text box for notes that moved to a task, a picklist copied from a spreadsheet. The cost is not storage. It is slower entry, weaker adoption and reports that look complete but are not.
Cutting fields is also a systems change. A field can be read by a form, a validation rule, a report, a dashboard, an import template or an integration. Remove it without tracing those links and a quote handoff or a finance export can fail. That is why How to cut CRM fields down to the ones you use should start with an inventory, not with a delete button.
The goal is not the smallest possible schema. The goal is a schema your team can explain. Each field should have an owner, a purpose and a place in a live process. If a field has none of those, hide it, archive its data or retire it. Do this in a sandbox first, then move changes in a planned release.
Before you start
Name the people who can say no. You need the CRM admin, a sales lead, someone from finance or delivery who receives the data, and the owner of each integration. Ask each person for the fields they read, write or report on. Do not accept a verbal list. Get report names, integration names and form names.
Export a field inventory from the CRM. Include object, field label, API name, data type, required flag, picklist values, record types, page layouts, field-level security, created date and last modified date where the system exposes it. Add columns for forms, reports, dashboards, validation rules, workflow rules, flows, approval processes and external systems. Some of this will need manual checks. That is normal.
Agree on four outcomes before you edit anything: keep, hide, archive or delete. Keep means the field stays on the layout and in reports. Hide means the data stays but leaves the main layout. Archive means you export the values and keep the field empty or read only for a period. Delete means removal after checks. Set a rule for each outcome so the review is not a debate about taste.
How to do it
Work object by object, starting with the object your reps touch most, usually contacts, companies or deals. Do not start with a global purge. A field that looks dead on a contact may be vital on a deal. Use the same review for custom fields and standard fields you can hide, because both add clutter.
Use evidence in this order: a live report or integration reads it, a required business process needs it, a rep used it in the last review period, or nobody can explain it. The last group is your candidate list. Test every change in a sandbox with real page layouts and a sample of records. Then schedule a short pilot with one team before a full release.
- Export a field inventory. List every field by object, label, API name, type and owner. Add where it appears: page layouts, record types, forms, reports, dashboards, validation rules, flows and integrations. This list becomes your working sheet and your record of decisions.
- Classify each field with evidence. Mark each field keep, hide, archive or delete. Write one line of evidence for keep and one owner for every other outcome. If nobody can name a report, form, process or integration, the field is not a keep.
- Trace every dependency. Search the CRM for the field API name and label. Check reports, dashboards, list views, workflow rules, approval processes, validation rules, form handlers, import templates and middleware. A field can be invisible on the layout and still break a nightly sync.
- Hide before you delete. Remove low-use fields from main page layouts and make them read only or hidden with field-level security. Keep the data in place and watch for requests. Hiding is reversible and shows you which fields people truly miss.
- Clean picklists and required flags. Remove retired picklist values, merge values that mean the same thing and keep active values short. Review required fields on forms: a field should be required only when the process stops without it. Move nice-to-have fields to a secondary section or make them optional.
- Archive data, then delete empty fields. Export values for fields you plan to delete, including record IDs and timestamps. Check backups and retention rules before removal. Delete only fields with no live dependency and no data you still need, then remove them from layouts, reports and integrations.
- Set a field request gate. Create one request path for new fields. Ask for the report, form or process that will use it, the owner, the data type and the picklist values. Review requests on a schedule and reject fields that duplicate an existing field or have no named consumer.
How to check it worked
Compare the before and after field inventory. Count fields on the main layouts and count required fields on the main entry forms. Open a new record as a rep would and time the entry path on desktop and mobile. If the form asks for something no report reads, the cut is not finished.
Run the reports and integrations you traced in the review. Check for blank columns, broken filters and import errors. Look at integration error logs for missing field errors. Ask the sales lead to review a sample of records for missing context. A clean layout that loses a key qualifier is not a win.
Watch behavior for a few weeks. Look for reps adding notes in the wrong field, asking where a field went, or recreating a retired field through a new request. Those are signals. If a hidden field gets repeated requests, bring it back in a smaller role. If a deleted field was truly unused, the request log stays quiet.
Mistakes to avoid
The first mistake is deleting before archiving. A field can look unused on the layout while a report, a quote template or a finance export reads it. Export values and trace dependencies before you remove anything. Hiding first gives you a cheap rollback.
The second mistake is checking only page layouts. Fields live in validation rules, record types, permission sets, form handlers, list views and middleware. Search by API name, not just the label, because labels change and API names often do not.
The third mistake is leaving retired picklist values in place. Old values keep showing up in reports and imports, and reps keep picking them. Merge synonyms, remove dead values and update any report filters that reference them. Keep a mapping sheet for historical data.
The fourth mistake is opening a new field for every request. Add a gate: a named consumer, an owner, a data type and a review date. If you want outside help, Cloudverg's Sales CRM implementation package at $9,500 fixed price is one option among others; it includes a contact, company and deal model, training and an admin guide. Do the field review first so any implementation starts from a clean list.
Frequently asked questions
How many custom fields should a CRM have?
There is no universal number. A field earns its place if a live report, form, integration or sales process reads or writes it. Keep those, hide the rest from main layouts and review the list on a schedule. A smaller schema is easier to train and easier to audit.
Can I delete a CRM field without losing data?
Usually no. Deletion can remove values from records and may break reports or integrations that still reference the field. Export the data first, check backups and retention rules, and hide or archive the field before you delete it. Delete only after a dependency check.
What should I do with a field that only an integration uses?
Keep it, but move it off the main page layout and make it read only for reps. Document the integration, the API name and the owner in your field inventory. Review it when the integration changes. If the integration stops using it, archive the data and retire the field.