How to Find and Remove Unused Custom Fields in Salesforce

Every Salesforce org accumulates custom fields the way a garage accumulates boxes. Someone created them for a one-time report. A previous admin built them for a project that never launched. A vendor integration seeded twenty fields, and the vendor was replaced two years ago.

The result: orgs with 200, 300, sometimes 500+ custom fields on Account and Opportunity alone, most of which nobody uses. This is not just clutter. It is a direct threat to data quality, rep productivity, and any AI tool that reads from your CRM.

Why unused fields matter more than you think

Unused fields create three compounding problems. First, they slow down your reps. Every field on a page layout is a decision a rep has to make: fill it, skip it, or wonder whether it matters. Research consistently shows that form completion rates drop as field count rises. If your Opportunity layout has 60 fields and 25 of them are irrelevant, your reps are spending cognitive energy on noise.

Second, unused fields that still hold partial data become poison for AI models. A forecasting copilot or lead scoring engine that ingests Salesforce data treats every populated field as a signal. If a deprecated field called "Legacy_Region__c" still has values on 40% of records, the model will try to learn from it. That learning is based on stale, incomplete data, and it degrades output quality in ways that are difficult to detect.

Third, unused fields make your metadata harder to govern. Every field is a surface area for permissions, field-level security, and integration mappings. More fields means more complexity in every security review, every integration build, and every new admin's onboarding.

Step 1: Pull your field inventory

Start with a complete inventory. Go to Setup, then Object Manager, select the object (Account, Contact, Opportunity, Lead are the priority), and export the field list. For each field, note the API name, data type, created date, and last modified date.

If you have access to Salesforce CLI, you can pull metadata for all custom fields across objects in a single command. This gives you an XML file per field with creation metadata. For larger orgs, tools like Salesforce Optimizer (free inside Setup) generate a report that flags fields with low population rates.

Step 2: Check field population rates

A field that exists on zero records is easy to remove. The harder cases are fields populated on 10% or 30% of records. For these, run a SOQL query to count non-null values. A field populated on fewer than 5% of records and not referenced in any report is a strong candidate for removal.

Be careful with formula fields and roll-up summaries. These may not hold data themselves but compute values from other fields. Removing a source field without checking dependent formulas will break calculations silently.

Step 3: Map field dependencies

Before removing any field, check five places: page layouts, record types, validation rules, flows and process builders, and Apex code. Salesforce does not natively surface all of these dependencies in one view. You will need to search your metadata or use a dependency analysis tool.

Also check integrations. Third-party tools that sync via API may reference fields by API name. Removing a field that an integration expects will cause sync failures, often silently. Pull your connected app list from Setup and check API logs for recent calls referencing the field.

Step 4: Categorize before you delete

Sort your unused fields into three buckets. First, fields with zero population and zero dependencies: delete these immediately. Second, fields with low population but possible integration references: flag these for review with your integration team before removing. Third, fields with moderate population but no current business use: archive the data first (export to a CSV or data warehouse), then remove the field.

Document every deletion. Keep a changelog with the field API name, the date removed, and why. This protects you from the inevitable "who deleted that field?" question six months later.

Step 5: Set a governance policy to prevent recurrence

Cleaning up unused fields is a one-time project. Preventing their return is a policy. Establish a rule: every new custom field requires a documented business justification, an assigned owner, and a sunset date. Run a quarterly audit of field population rates and flag anything below 10% for review.

This is where a data stewardship model pays for itself. When someone owns each object's field inventory, field sprawl stops compounding.

What this has to do with AI readiness

If you are deploying or planning to deploy AI tools on your Salesforce data (forecasting copilots, lead scoring, account intelligence, or agent-based workflows), your field hygiene is the first thing to fix. Every AI model is only as good as the data it reads. A clean, intentional set of fields produces clean, intentional outputs. A bloated set of deprecated fields produces noise that your AI cannot distinguish from signal.

This is one of six dimensions in the AI-Ready RevOps Framework. Data Foundation carries the highest weight in the Readiness Index because it is the most common point of failure.

Try it free →CRM Data Quality Scorecard

Frequently asked questions

How many unused custom fields does a typical Salesforce org have?

Most mid-market Salesforce orgs accumulate between 100 and 400 custom fields that are no longer referenced in reports, layouts, flows, or integrations. These fields add cognitive load for reps, slow down page loads, and contaminate any AI model that reads from the object.

Can I safely delete unused custom fields?

Not immediately. A field with no data and no references in code, flows, reports, or layouts is safe to remove. But always check for hard-coded API references in integrations, Apex triggers, and third-party apps before deleting. Export a field dependency report first.

How do unused fields affect AI tools?

AI tools that read from Salesforce objects treat every populated field as a potential signal. Unused fields that still hold stale or partial data introduce noise. The model may weight that noise alongside real signals, producing less accurate predictions, lead scores, or forecasts.

---

← All articles