Retire the CRM Fields Nobody Uses to Make a Decision

CRM clutter usually started as a reasonable request

A supplier manager wanted another classification. Marketing needed a campaign value. An advisor asked for a place to save a detail from discovery. Operations made a field required because records kept arriving incomplete.

None of those requests sounds reckless. The problem shows up later. The campaign ends. The supplier program changes. The firm replaces the report. Nobody removes the field, so the record keeps asking for information that no longer changes the work.

Crowded records, weak completion, duplicate classifications, and fields built for reports nobody uses are common CRM complaints. That does not give your firm a universal field count. Ten fields can be too many if seven are pointless. Fifty can be appropriate if each one supports a real service, control, or decision.

The fix is not a mass deletion. Run a CRM field audit and make a deliberate treatment decision for every field.

Start with the decision, not the completion rate

A mostly blank field is suspicious, but blank does not automatically mean useless. A contract termination notice may be rare and still matter. A field can also be fully populated because an import fills it, even though nobody trusts or uses the value.

Ask one blunt question first: What changes when this field changes?

A field has a clear operating purpose when it does at least one of the following:

• Changes the next client or prospect action
• Supports a renewal, proposal, supplier, commission, or delivery decision
• Controls ownership, access, routing, approval, or automation
• Feeds a report the firm reviews and acts on
• Preserves evidence for a contract, commitment, exception, or required record

"It might be helpful someday" is not an operating purpose. Neither is "we have always captured it." Name the decision, the person using it, and the moment it matters.

This keeps the audit connected to how the firm works. A renewal date belongs because it starts preparation and protects timing. An opportunity stage belongs because it places the deal in a defined operating state. A favorite-sports-team field probably does not belong on every contact because somebody once suggested more personal outreach.

Build the field inventory before changing anything

Export the field list by record type. Include organizations, contacts, opportunities, contracts, suppliers, commissions, activities, tasks, projects, and any custom records your firm uses.

For each field, record:

• The field name, type, allowed values, and whether it is required
• The record type and screen where it appears
• The current owner or team that requested it
• Population and recent-change evidence
• Reports, views, filters, forms, imports, integrations, workflows, and exports that reference it
• The decision or control it is supposed to support
• The proposed treatment and approver

Do not ask advisors to review a raw list of internal field names. Show the label, where the field appears, a plain-language purpose, a sample of current values, and every known dependency. Otherwise the team will approve cleanup without realizing that "Contract Status 2" drives a renewal queue or client export.

Usage and value are different tests

Run both.

The usage test asks whether records contain the value, whether the value has changed recently, and whether a person or system reads it. The value test asks whether the field improves a current decision or protects a necessary control.

That creates four useful groups:

1. Used and valuable. Keep it, document the purpose, and confirm the field type still fits the job.
2. Used but low value. Find out why people keep entering it. The field may be required, imported, copied from an old template, or easier to use than the correct record.
3. Rarely used but valuable. Keep it only where the condition applies. Make it conditional, optional, or limited to the right record type instead of forcing everybody to complete it.
4. Rarely used and low value. This is the retirement candidate, subject to the dependency and history checks.

This is also where you catch bad design disguised as bad adoption. If advisors keep putting a supplier escalation date in notes, the date may matter. The existing field may be buried, confusing, or attached to the wrong record.

Choose a treatment instead of arguing keep or delete

Deletion is only one option. Give each field one treatment:

• Keep required. The record cannot support its intended decision without a valid value.
• Keep optional. The value matters in some cases, but forcing it produces guesses or placeholder data.
• Correct. Rename it, change the value list, clarify the definition, move it to the right screen, or assign an owner.
• Combine. Map duplicate fields into one approved field after resolving conflicting values.
• Move to history. Preserve prior values for evidence without keeping the field in the active workflow.
• Retire. Stop new entry, preserve what must be retained, remove dependencies, and then remove the field.

Required should be the hardest status to earn. If an advisor can save the record only by entering "unknown," "N/A," or a convenient default, the requirement is manufacturing bad data. Make the field conditional or optional until the process reaches the point where a real answer is necessary.

Do not delete a field before you find its dependencies

A field can look unused on the record and still drive a view, report, workflow, form, integration, duplicate rule, import, export, or client-facing document.

Microsoft's current Dataverse dependency guidance explains why referenced components cannot simply be removed. Its examples include workflows and other components that still depend on the item being changed. The product mechanics are specific to Dataverse, but the operating lesson applies to any CRM: find every dependency before you remove the field.

Microsoft also documents published and unpublished component dependencies. That distinction is a useful reminder to inspect active production use and pending configuration work. A field may be absent from today's reports while still sitting inside an unpublished workflow or planned form.

For every retirement candidate, check:

• Saved views, filters, dashboards, reports, and scorecards
• Forms, required-field rules, validation, and conditional display
• Automations, assignments, alerts, approvals, and calculations
• Imports, exports, APIs, integrations, and client portal displays
• Templates, proposals, documents, and historical reporting

The existing CRM view audit can help with the first group. Use the automation readiness test before changing a field that controls a workflow. If the field participates in duplicate matching or record survival, use the duplicate-record process before combining data.

Retire fields in two steps

First, stop the field from creating more bad data. Remove it from active forms, turn off the requirement, stop new imports, and document the approved replacement. Leave the existing values available during a short review window.

Second, test the affected work. Run the reports. Trigger the workflows. Process a sample import. Open the client portal. Generate the proposal or export. Confirm that the team can still complete the client, pipeline, renewal, supplier, and commission decisions the field once touched.

If the field carries history you may need later, export the field name, record identifier, value, last update, and retirement reason before removal. Do not paste everything into a generic notes box. That creates unstructured clutter and makes the old value harder to govern.

Record who approved the retirement, which dependencies changed, where retained history lives, when the field stopped accepting updates, and when final deletion is allowed.

Run the first audit on one record type

Do not begin with the entire CRM. Pick the record your advisors touch most often, probably the opportunity, organization, or contact.

Review every field against one month of real work. Talk through a qualified opportunity, a renewal, a stalled deal, and a closed record. Watch where the team leaves blanks, guesses, duplicates information, switches to notes, or opens a spreadsheet because the CRM structure does not fit the decision.

Then approve the treatments, map the dependencies, make the smallest safe set of changes, and test the work again. After that, move to the next record type.

Advisor OS CRM connects client organizations, contacts, opportunities, contracts, suppliers, activities, tasks, commissions, and reporting around the work a technology advisory firm performs. The point is not to collect more fields. It is to keep the right evidence attached to the decision where your team needs it.

Use the free Advisor OS agency scorecard if you want a broader check on the operating systems behind your pipeline, clients, suppliers, and revenue.