Field Cleanup

SALESFORCE EXTERNAL FIELD DEPENDENCIES.

Salesforce metadata can surface many internal field references. External systems, forms, APIs, BI tools, and integrations may still depend on fields that look unused inside the org.

Read-only diagnostics · Review-ready workbooks · No package install · No Connected App

Salesforce external field dependencies are references to Salesforce fields that exist outside Salesforce metadata — in integrations, marketing automation platforms, middleware, BI tools, web forms, portals, and external applications that call the Salesforce API.

When admins review a field for cleanup, they typically look at fill rate, layout presence, FLS visibility, and automation references. Those signals come from Salesforce metadata. External dependencies are not in that metadata. A field can pass every internal metadata check and still be actively used by a system that Salesforce cannot see.

The Metadata Boundary

WHY SALESFORCE METADATA MAY NOT SHOW EVERY FIELD CONSUMER.

Salesforce metadata is the org's description of itself. It describes fields, their types, their references within the org, and how they are configured. It does not describe what external parties do with those fields.

An external system that reads a field via the Salesforce API does not create a metadata entry that says "this integration uses this field." A web form that writes to a field during submission does not appear in the field's metadata references. A data warehouse that exports records and stores field values has no representation in the org's configuration metadata.

This is not a flaw in Salesforce or in diagnostic tools — it is a boundary condition. Any tool that reads Salesforce metadata operates within this boundary.

Common Consumers

COMMON EXTERNAL SYSTEMS THAT DEPEND ON SALESFORCE FIELDS.

Before proceeding with field cleanup, validate with owners of the following systems — any of which may depend on specific field API names:

  • Marketing automation platforms (Pardot, Marketo, HubSpot) — sync field mappings, form field mappings, and lead scoring logic use specific Salesforce field API names
  • Middleware and iPaaS platforms (MuleSoft, Boomi, Workato, Zapier, Make) — integration flows that read or write Salesforce fields use field API names in their configuration
  • Data warehouses and analytics pipelines — scheduled extracts and connector syncs reference field API names directly
  • BI tools (Tableau, Looker, Power BI, Einstein Analytics/CRM Analytics) — datasets built from Salesforce connections reference field API names in queries and dimensions
  • Web-to-lead and web-to-case forms — hidden form fields pass values directly to specific Salesforce field API names on record creation
  • Customer portals and Experience Cloud pages — fields exposed in community pages may reference custom fields by API name in page layouts or components
  • Custom external applications — any application that calls the Salesforce REST or SOAP API with specific field names in queries, creates, or updates
  • Data migration and import tools — scheduled imports that match source data to Salesforce fields by API name
Empty Does Not Mean Unused

WHY EMPTY FIELDS MAY STILL MATTER.

A field may be empty in Salesforce records for reasons other than true non-use:

  • The field is populated by an integration only during specific events — a deal closing, a form submission, a webhook trigger — and may be empty between events
  • The field was used historically and is empty on current records but still referenced by reports that include historical records
  • The field is part of a staging or intermediate-state pattern — populated by one system, read by another, then cleared or overwritten
  • The field is expected to be populated in a future process and its absence is intentional — removing it would break the expected future state

See Salesforce field cleanup review candidates for the broader case on why low usage alone is not sufficient for cleanup decisions.

Review Process

HOW TO REVIEW FIELDS BEFORE CLEANUP.

Field review checklist

  • Start with internal signals: fill rate, layout, FLS, formula, validation rule, Flow, and Apex references
  • Flag candidates based on internal signals — do not move directly to cleanup action
  • Identify which integration, marketing automation, and data platform owners to consult
  • Send the candidate list to integration owners with a clear question: does any external system use this field?
  • Confirm with data warehouse and BI owners whether the field is included in any dataset or dimension
  • Check whether the field API name appears in any external configuration, mapping, or documentation
  • Get written confirmation from owners before proceeding — and document the confirmation in the review workbook

Relevant Workbook

Field & Object Audit

Field & Object Audit surfaces fill rates, layout coverage, FLS visibility, and multi-signal review candidates for selected objects — producing a review-ready XLSX workbook that supports external validation conversations.

Learn more →Run diagnostic →View sample workbook →
Limitations

WHAT KEELCADENCE CAN AND CANNOT DETECT.

KeelCadence reads available Salesforce metadata for selected objects. It can surface:

  • Fill rates, distinct value counts, and layout coverage where metadata is available
  • FLS visibility across profiles and permission sets
  • Formula, validation rule, Flow, and available Apex references
  • Hidden populated fields — fields with data but no layout presence

KeelCadence cannot detect external system dependencies — integrations, forms, APIs, BI connections, or data pipeline references that exist outside the Salesforce metadata boundary. These require cross-functional validation with the teams who own those systems.

See the security page and IT review page for the full data access and boundary model.

FAQ

FREQUENTLY ASKED QUESTIONS.

Can Salesforce show all external field dependencies?

No. Salesforce metadata shows internal references — formula fields, validation rules, Flows, Apex, layouts. It does not show which external systems, integrations, forms, portals, BI tools, or data exports use specific field API names. Those dependencies exist outside the Salesforce metadata boundary.

What external systems can depend on Salesforce fields?

Marketing automation platforms, middleware integrations, data warehouses, BI tools, web-to-lead forms, portals, customer-facing Experience Cloud pages, email platforms, and custom external applications that call the Salesforce API using specific field names can all depend on Salesforce fields without those dependencies appearing in Salesforce metadata.

Can an unused Salesforce field still be important?

Yes. A field with a 0% fill rate and no Salesforce metadata references can still be read by an external system, used in a data pipeline, mapped in an integration, or depended on by a form or portal. Unused in Salesforce metadata is not the same as unused by every system that interacts with the org.

What should admins check before deleting fields?

Check internal Salesforce signals first — fill rate, layout, FLS, formula, validation rule, Flow, and Apex references. Then validate externally with integration owners, marketing automation owners, BI owners, and data warehouse owners. Document what was checked and who confirmed the field is safe to proceed.

How should teams document external field dependencies?

Create a field dependency map that includes integration owners, the systems or tools that use each field, the access pattern (read, write, or both), and who confirmed the dependency status. This documentation supports future cleanup work and helps new team members understand the field's true scope.

Review Before Change

CREATE A REVIEW-READY WORKBOOK BEFORE MAKING SALESFORCE CHANGES.

Run a read-only KeelCadence diagnostic to surface metadata, access, automation, field, and readiness signals before cleanup, UAT, imports, handoff, or change work.

Run Field & Object Audit →View Sample Workbook

Read-only · No package install · No Connected App setup · No Salesforce writes

Home/Resources/Salesforce External Field Dependencies

Trust & Security

KeelCadence uses session cookies and Google Analytics 4 for site usage insights. GA4 does not receive Salesforce credentials, Org IDs, Report IDs, or payment data. You can opt out for this browser.