How to Find and Delete Unused Salesforce Custom Fields (Step-by-Step)

The average Salesforce org accumulates over 2,000 custom fields. More than 60% of them are unused — columns that were created for a campaign that ended, a consultant engagement that closed, or a feature that shipped and then changed. Nobody deleted them.

Those unused fields aren't just noise. They slow down page loads. They clutter reports. They confuse new hires. They consume governor limits. And they make every AI-assisted workflow — from Einstein to Agentforce to custom LLM integrations — less reliable, because the data model your automation reads is full of empty columns that mean nothing.

This is a core category of admin debt: the accumulated weight of configuration that made sense once and hasn't been revisited since. Finding and deleting unused custom fields is the highest-ROI cleanup task in most orgs. It's also the most underestimated in complexity — you can't just sort by "last modified" and start deleting.

Here's the complete, safe process.

Why Unused Fields Matter

Before the how-to, the stakes.

Page load and performance. Every custom field on a page layout adds a DOM element, a render cycle, and — if it's a formula or lookup field — a computation. An Opportunity page layout with 180 fields (and 70 of them unused) loads measurably slower than one with 80. Salesforce reports this as a common driver of the "Salesforce is slow" complaint.

Report clutter. Unused fields appear in every Report Builder field picker. Your sales reps see Contract_Start_Date_Old__c next to Contract_Start_Date__c and don't know which to use. Dashboards built on the wrong field give wrong numbers. Trust in data quality erodes.

Training burden. Every field a new admin or rep encounters that doesn't make sense is a question to someone senior. Fields named Temp_Integration_Flag__c or DO_NOT_USE_Legacy_Owner__c create institutional confusion that compounds with every new hire.

Governor limits. Salesforce enforces limits on custom fields per object: 500 for most objects on Enterprise/Unlimited edition. An org with 480 fields on the Account object has no room for new ones without first removing old ones. Unused fields block legitimate work.

AI data quality. Any AI agent, scoring model, or automation that reads your Salesforce data encounters unused fields as noise. A field with 0% population that gets included in training data or model features degrades accuracy. According to Hubbl Diagnostics, 60%+ of custom fields in mature orgs are unused — in AI terms, that's a 60% noise floor on your data model.

Cleaning up unused fields directly improves data quality and is the prerequisite for any serious AI-assisted Salesforce workflow.

Method 1 — Field Trip / SOQL Queries (Manual, Slow, the Old Way)

The classic approach is to query field usage data directly via SOQL in the Developer Console.

Step 1: Find fields with low or zero population

Open Setup → Developer Console → Query Editor. Run:

SELECT QualifiedApiName, DataType, LastModifiedDate
FROM FieldDefinition
WHERE EntityDefinition.QualifiedApiName = 'Account'
ORDER BY LastModifiedDate ASC

This surfaces all Account custom fields and when they were last modified. Fields last modified 3+ years ago by someone who no longer works there are prime candidates.

Step 2: Check population rate

For any field you suspect is unused, query actual records:

SELECT COUNT(Id) total,
       COUNT(Your_Field__c) populated
FROM Account
WHERE CreatedDate = LAST_N_DAYS:365

If populated is 0 (or near 0) on a large object, the field is almost certainly dead.

The problem with this approach: It's per-field, per-object, manual. A mature org with 2,000 fields across 30 objects requires hundreds of queries. Most admins run a few queries, identify the most obvious candidates, and stop. The long tail of unused fields stays untouched.

Method 2 — Setup → Object Manager → Field Information (Manual, Partial Coverage)

Salesforce's native UI provides some visibility into field metadata.

Navigate to: Setup → Object Manager → [Your Object] → Fields & Relationships

Here you can see:

• Field label and API name
• Field type
• Last modified date
• Whether the field is required

What this doesn't tell you:

• Population rate (how many records actually have data in this field)
• Whether the field is referenced in active Flows, Validation Rules, Reports, or Dashboards
• Field history data

For each field you want to evaluate further, click into it and use the View Field Dependencies link. This shows references to the field in validation rules, workflow rules, Flows, and formula fields.

The problem with this approach: It's comprehensive for individual fields but doesn't scale. And it has a critical blind spot: it doesn't show report or dashboard references. A field that's "unreferenced" by dependent objects may still be actively used in five dashboards that your VP of Sales looks at every morning.

Before deleting any field, you must check reports and dashboards manually — Field Dependencies won't catch those.

Method 3 — Free Luxera Cloud Field Usage Auditor (60 Seconds, Full Coverage)

The fastest and most complete approach for teams that need coverage across all objects without spending hours in SOQL:

Step 1: Export your org metadata

From your Salesforce CLI or Workbench, export your .object-meta.xml files. This is a read-only export — no credentials or org access required for the auditor to process it. Alternatively, paste raw field metadata directly.

Step 2: Upload to the Field Usage Auditor

Go to the field usage auditor and paste your metadata or upload the .object-meta.xml file.

Step 3: Get scored results in 60 seconds

The auditor surfaces:

• Fields with high deletion-risk scoring (unused + no dependencies + deprecated naming patterns)
• Fields with naming signals: _old, _v2, _temp, _legacy, _bak, _DELETE, _DO_NOT_USE
• Fields with no description (reliable proxy for "created quickly without documentation")
• Fields created by users who no longer appear in recent transaction logs
• Type mismatches (e.g., a date field stored as Text, a currency field with no values)

The scoring is deterministic and client-side — your metadata never leaves your browser. You get a ranked list of deletion candidates in roughly the time it takes to make a cup of coffee.

This is the recommended starting point for any org with more than 200 custom fields. Run the auditor first to build the prioritized list, then use SOQL or Object Manager to verify the top candidates before deletion.

How to Safely Delete: The Deprecation Playbook

Never delete a field immediately after identifying it as unused. The safe process takes 30 days and has three steps. It sounds slow. It isn't — you do the active work in an hour, then wait.

Step 1: Rename with _DEPRECATED_ prefix

Before touching anything else, rename the field:

Your_Field__c → DEPRECATED_Your_Field__c

In Salesforce, you can change the field label without changing the API name. But for this process, change the field label (what users see) to [DEPRECATED] Your Field. This immediately signals to anyone encountering the field that it's scheduled for deletion.

If your org uses a metadata deployment pipeline, put the rename in a change set or package and deploy to sandbox first.

Export field history before renaming. If the field has any historical data — even if current population is 0% — export it via Data Loader before proceeding. Once deleted, field history is gone permanently. For compliance-sensitive fields (anything that might be subpoenaed or audited), consult your legal team before deletion.

Step 2: Remove from page layouts

A deprecated field should not appear on any active page layout. Go through every page layout that includes this field and remove it. This is the step where you often discover the field is actively used — it's on the page layout your sales reps use every day, just not populated because no one knows what it's for.

If removing it from the layout causes complaints within your monitoring window, you've found a false positive. Stop and investigate.

Step 3: Monitor for 30 days

Wait 30 days after the rename. Watch for:

• Any Flow or automation errors referencing the field
• Any report failures or "field not found" errors in scheduled reports
• Any user complaints about missing data
• Any API errors in your integration logs

Most orgs catch integration references this way. An old ETL pipeline or Zapier workflow that nobody knew was running shows up as an error when the renamed field doesn't match the expected API name.

If nothing surfaces in 30 days, proceed to deletion.

Delete via Setup

Navigate to: Setup → Object Manager → [Object] → Fields & Relationships → [Field] → Delete

Salesforce will show a final list of dependencies. If anything appears there that you didn't already clear, stop and investigate. If the list is empty, confirm the deletion.

Post-deletion: The field API name is now permanently reserved for 6 months — you cannot create a new field with the same name. This is intentional. Plan naming conventions accordingly.

Common Pitfalls: What Deletion Checks Miss

Even after checking Field Dependencies and doing the 30-day monitor, fields can still be referenced in ways that aren't surfaced by native tools:

Flows (Record-triggered and Scheduled): Field Dependencies shows fields referenced in active Flows, but may miss fields in inactive Flows that someone re-activates later. Audit inactive Flows separately.

Validation Rules: A validation rule that's been deactivated won't show up in Field Dependencies. If you have inactive validation rules, check them manually before deleting candidate fields.

Reports and Dashboards: This is the biggest blind spot. Native Field Dependencies does not show report column references or dashboard filter references. To catch these, run a Report Builder search: go to Reports → New Report → Add a field to the column list → search for the deprecated field. If it appears in existing reports, those reports will break on deletion.

Page Layouts (Lightning vs Classic): If your org has Classic page layouts alongside Lightning page layouts, check both. Field Dependencies may only show Lightning references if Classic pages are deprecated in your org.

Third-party integrations: Zapier, MuleSoft, custom Apex, and any external system that reads or writes this field via the API will not appear in Salesforce's dependency checker. Review your integration documentation and check API call logs for any reference to the field's API name.

Email templates: Fields used in email template merge fields are not tracked in standard Field Dependencies. Run a text search of your email templates for the field's API name.

The 30-day monitoring window catches most of these. The rename (not delete) approach is what makes it safe — you can rename back if something breaks.

Connect Luxera Cloud for Automatic Scanning

Running this process manually once clears the backlog. But fields accumulate faster than most teams realize — new implementation, new consultant, new campaign, new field. Without a policy for retirement, the org returns to its previous state within 12–18 months.

Luxera Cloud's full org scanner runs this analysis automatically on a schedule: field population rates, naming pattern detection, dependency mapping, and deletion risk scoring — updated monthly. When a field crosses the threshold for deletion candidacy, it surfaces in your dashboard with the full context needed to act.

The Founding Member tier includes automated field health monitoring as part of the core product. Early access pricing is locked for the first 50 seats.

If you're also dealing with validation rule conflicts alongside unused fields, see our guide: Salesforce Validation Rule Conflicts: How to Find and Fix Them.

This post is part of the Luxera Cloud guide to Salesforce admin debt — the accumulated weight of configuration decisions that make everything in your org harder over time.

Comparing your tooling options? See: Salesforce Optimizer alternatives: 5 tools compared — Sonar, Elements.cloud, Salto, and Luxera Cloud side by side.