A CRM field can look unused in the record view and still feed a report, formula, workflow, integration, or spreadsheet export. Removing it before those dependencies are understood can break a sales process or erase history the business still needs.
Treat field retirement as a small change project. Decide what the field does, map its consumers, move those consumers to a suitable replacement, and verify the result before deletion. Hiding a field, stopping new updates, and deleting the field are different decisions.
Name the field and the decision it supports
Start with the field’s API name, object, owner, and business purpose. A display label such as “Lead Source Detail” may have changed over time, so use the stable field name when checking formulas, integrations, or exports.
Ask what decision currently depends on the field. It may support segmentation, lead routing, attribution, a forecast, a sales handoff, or a historical report. If no one can name its purpose, check actual usage and consumers before deciding that the data has no value.
The CRM hygiene guide helps prioritize fields that affect decisions. This retirement workflow starts after a team has selected a specific field to review.
Map dependencies inside the CRM
Use the CRM’s field-reference or dependency tools before changing the field. Salesforce’s “Where is this used?” view can show references such as formulas, validation rules, layouts, flows, Apex, and reports. A field used in a field update or another field may not be deletable until that reference is removed.
Review each reference with its owner. A report reference may be an old test, or it may be a leadership report used every month. A flow may be active, paused, or scheduled. Record the actual business use rather than assuming that the component name explains it.
Check what the dependency list may not show
A dependency screen is a starting point, not proof that the field has no consumers. Salesforce documents limits on its reference list: some reports across related objects, joined reports, inaccessible reports, and managed-package references may not appear, and the results are capped.
Also check systems outside the CRM: web forms, marketing automation, middleware, data warehouses, spreadsheets, exports, and offline conversion uploads. Search configuration or integration maps for the API name. Ask the owners of recurring reports and data feeds whether they still read or write the field.
The revenue reporting data dictionary can help record definitions and owners. If the field affects contact-to-account reporting, check the account-matching rules before changing its role.
Choose a replacement only when the meaning matches
If a replacement field is needed, compare definitions before copying values. Similar labels do not mean two fields capture the same event, time, or level of detail. For example, a first-touch source and a latest-touch source should not be merged into one value simply because both describe acquisition.
Write the old definition, new definition, valid values, owner, and effective date. Decide whether historical values can be mapped without changing their meaning. If they cannot, preserve the old values for historical reporting and use the new field for future records.
The guide to requiring CRM fields when they become knowable covers how to time field requirements around the process that creates the data.
Move consumers and verify the change
Plan a controlled sequence. Update one group of consumers at a time, then check the records and outputs before removing the old field. Use a sandbox or other safe test area when the platform and workflow allow it.
Before deletion, confirm that:
- Automations: active and scheduled workflows use the replacement or no longer need the old field.
- Reports: filters, columns, formulas, dashboards, and exports still return the intended records.
- Integrations: forms, middleware, marketing tools, and data imports no longer write to the old field.
- Historical data: the team has decided whether to retain, map, export, or stop reporting the old values.
- Owners: sales, marketing, operations, and analytics agree on the new source of truth.
Compare a defined set of records before and after the change. Check for unexpected blanks, value shifts, broken automation, and report changes. If the evidence is incomplete, keep the field in a retired or read-only state if the CRM supports that approach, and continue checking before deletion.
Account for data recovery and history
Check the CRM’s deletion and recovery rules before removing a field. In Salesforce, deleted custom fields and their data are retained only until the organization permanently deletes them or 15 days have elapsed, whichever happens first. Salesforce also states that deleting a custom field deletes its field-history data.
Do not treat a temporary restore window as a backup or retention plan. If historical values or audit history must remain available, agree on an approved export or archive before deletion and confirm who can access it. Other CRMs may have different recovery periods and data behavior.
Record the retirement decision
Keep a short field-retirement record with the API name, purpose, references checked, affected reports and integrations, replacement mapping, data-retention decision, owners, test evidence, and deletion date. Note any dependency the team could not verify and assign a follow-up owner.
The record helps the next person understand why the field disappeared and where its data or replacement now lives. If a CRM field should remain required at a particular point in the process, document that rule instead of leaving the old requirement in place by habit.
If your team needs help tracing CRM fields through lead capture, automation, reporting, and pipeline decisions, request a marketing diagnostic to review one field and its consumers.
Sources and scope
- Salesforce Help: Find Where a Field Is Used — describes field references and limitations in the dependency view.
- Salesforce Help: Delete a Custom Field — covers deletion requirements, dependencies, recovery, and field-history effects.
- Salesforce Help: Manage Deleted Custom Fields — explains the recovery window and behavior of restored fields.
- Salesforce Help: Considerations for Field Update Actions — documents field-update dependencies that can block deletion.
Salesforce details here are platform-specific examples. Check the current CRM’s dependency view, permissions, installed integrations, and recovery behavior before applying the workflow. Accessed October 9, 2026.
How did this article land?
Choose one reaction. You can change it anytime.