Find where a Salesforce field is used—and what your search cannot establish.
A blank dependency result is easy to misread as permission to delete a field. A useful investigation instead identifies the proposed change, collects several kinds of evidence and assigns an owner to the gaps.
8 min readBy aprity editorial · Updated
Start with the field's qualified API identity and the exact change being considered. Combine Salesforce reference discovery, source inspection and confirmation from integration and reporting owners. Record how each search was performed and what it could not see.
The example uses an invented Account.Billing_Tier__c field. It illustrates an investigation method, not a dependency inventory recovered from a real org.
Define the change before collecting references
The same dependency can matter differently depending on what you change. Avoid issuing a generic ‘safe to change’ verdict.
| Proposed change | Likely review focus | Useful acceptance evidence |
|---|---|---|
| Change the label | User instructions, report interpretation, translated labels | Business users can still identify the intended concept |
| Change allowed values | Branch comparisons, mappings, historical records | Each consumer handles old and new values deliberately |
| Change type or precision | Comparisons, calculations, serialisation, data conversion | Boundary cases and consumer contracts are qualified |
| Remove the field | Reads, writes, reporting, integrations and retained data | Every identified consumer is migrated or explicitly retired |
Use Where Is This Used as the first pass
Salesforce exposes Where Is This Used on custom-field detail pages. Its help reference documents gaps including managed-package references in subscriber orgs, joined reports, some relationship-based reports and reports the querying user cannot access. The displayed list is limited to 2,000 references. Preserve the caller's access context with the result.
For Account.Billing_Tier__c, capture the API name, namespace where relevant, field type and the proposed change in a review record. Save the returned references with an observation date. Open each relevant component and establish the actual relationship: reading a value for a decision, writing it, displaying it, or including it in a filter are different dependencies.
Do not substitute a screenshot of the list for this interpretation. A formula reference might affect an executive metric; a layout reference might affect only a screen. The component name alone does not tell you the business consequence.
Search retrieved source with a reproducible boundary
After an authorised retrieval into a Salesforce project, run a literal search locally. This command only searches the files present in the named directory; it does not query the org or establish complete coverage.
rg -n --fixed-strings 'Billing_Tier__c' force-app/main/defaultReview the matching object context, namespace and source revision. The same unqualified field name may exist on several objects. Also inspect relevant mappings and configuration where strings can be assembled dynamically; an exact-name search will miss those constructions.
Read dependency edges in the right direction
Salesforce's MetadataComponentDependency object can supplement the investigation. In a returned edge, MetadataComponent identifies the referencing component and RefMetadataComponent identifies the referenced component. To investigate consumers of a field, identify that field on the referenced side. Reversing the direction answers a different question.
Use the API's current usage documentation for supported component types, filters and result limits. Record the query and whether its result could have been truncated. An API response, a local source search and Where Is This Used are overlapping observations, not three independent confirmations of completeness.
Maintain a separate coverage list: what the retrieval included, what the user could access, which packages were opaque and which external repositories were inspected. If a report folder was unavailable, write ‘not inspected’ rather than leaving the reports row empty.
Build a consumer ledger, not just a count
Illustrative review for retiring Billing_Tier__c. These rows show the evidence to collect; they are not findings about your org.
| Candidate consumer | How to establish the dependency | Disposition before removal |
|---|---|---|
| Account routing Flow | Read the decision and field mapping in the retrieved active definition | Replace comparison; test each affected route |
| Revenue report | Inspect the actual columns and filters with an authorised report owner | Agree replacement metric; compare sample outputs |
| ERP export mapping | Obtain the deployed mapping from its external owner | Version the consumer contract and migration date |
| Dynamic Apex access | Trace how the field-name string is constructed | Review reachable values; add a targeted acceptance case |
| Managed-package implementation | Consult publisher documentation or support where internals are inaccessible | Record unresolved compatibility and decision owner |
Treat external consumers as contracts
An integration can query a field without leaving a readable reference in the Salesforce metadata you retrieved. Ask the integration owner for the deployed mapping, the purpose of the value and the change window. ‘We think the old export is gone’ is a lead to investigate, not retirement evidence.
For the example field, define how a missing or unknown billing tier is interpreted. A consumer that silently defaults to a standard tariff may appear healthy after a breaking change. A successful HTTP response is weaker evidence than a reconciled output with the expected business value.
Agree a bounded observation period appropriate to the business schedule: a month-end consumer may never run during a two-day check. Document that choice and the unobserved cycles. No universal number of quiet days proves that a field is unused.
Make the release decision reviewable
Reconcile the lists
Deduplicate candidate references by qualified component identity. Retain the discovery method for each edge. Resolve contradictory observations instead of simply adding the counts together.
Attach targeted acceptance cases
For each material consumer, name the input, expected effect and owner. Include negative cases, historical values and a missing-value case where relevant. Distinguish proposed checks from executed results.
Recheck the release baseline
Compare the reviewed snapshot with the candidate to be deployed. Reopen the investigation if consumers or field semantics changed. Preserve the unresolved gaps in the approval record.
Record a bounded conclusion
Say ‘reviewed these consumers against this candidate; these gaps remain’. Avoid ‘no impact’ unless the scope of that statement is explicitly constrained and evidenced.
Key terms in this guide: Salesforce Dependency API.
Use dependency views to organise the investigation
aprity computes dependency relationships from supported metadata and presents them alongside documentation. Treat that view as evidence within the retrieved scope. It cannot establish that every external consumer has been discovered or that an untested change is safe.
- Inspect the source behind material relationships.
- Add external owners and coverage gaps to the review.
- Keep the final release decision tied to tested scenarios.
Frequently asked questions
Does an empty Where Is This Used result mean a field is unused?
No. Salesforce documents coverage and access limitations, and external consumers may not be represented. An empty result means that this particular discovery method returned no references in its observed context.
Is a dependency count a measure of change risk?
Not by itself. One billing integration can matter more than many display references. Assess the behaviour, business consequence, evidence quality and proposed change for each material consumer.
Related guides
Audit whether your Salesforce documentation can support a real decision.
A documentation audit should uncover where a reader would make the wrong change, misunderstand a process or be unable to investigate a failure. Counting documented components is only the beginning.
Read the guide Org takeoverInherited a Salesforce org? Find what could stop the business first.
The first week is usually too short to understand an established org. It is enough to discover which services depend on it, who can recover them and which assumptions need urgent investigation.
Read the guideSee it on your own org, not on a slide.
A free 14-day trial documents your org from a computed dependency graph — read-only, no credit card, and you review the output before deciding anything.