Where Is This Salesforce Field Used? Prompts for Coding Agents

You are about to rename, retype or delete a field in a client org. Before you do, you need one answer: what touches it?

This page gives you eight prompts for that question. You paste them into Claude Code, Cursor, Codex or VS Code, fill in the bracketed parts, and read what comes back. Every prompt asks for evidence, because a confident list with no source is the dangerous kind.

Use a sandbox. Do not point these at a production org until the client has signed off.

What Salesforce's own "Where is this used?" covers, and what it misses

Salesforce has a Where is this used? button on a field's detail page in Setup (Object Manager, then the object, then Fields & Relationships, then the field). It lists the metadata that references the field, so it is the right first stop. Run it before any prompt below.

What it is good for: custom fields, and a quick list of the places Salesforce itself tracks, such as Flows, validation rules, formula fields, page layouts and Apex.

Where it stops, so you know what to check by other means:

• Standard fields. Salesforce Ideas has an open request to extend it to them, which describes the button as working on custom fields only (Expand "Where is this used" functionality to standard fields).
• Dynamic Apex. A field name built as a string at run time, such as record.get('Status__c') or a dynamic SOQL string, is text to the platform, not a reference it can track.
• Anything outside the org. Integrations, ETL jobs, BI tools and scripts that read or write the field through the API leave no mark in the org's metadata.
• Names stored as data. A field API name held in a custom setting, custom metadata record or custom label is just a value.
• Order and effect. The list says a Flow mentions the field. It does not say whether that Flow reads it, writes it, or runs before another automation that does.

Salesforce also exposes dependency data through the Tooling API object MetadataComponentDependency (reference). It is useful, and it has its own gaps. See the query and its limits below.

None of this is a reason to skip the button. It is a reason to treat its list as the floor, not the full answer.

Before you paste a prompt

1. Work in a sandbox that is a recent copy of the client org. Retrieve the project with the Salesforce CLI so the agent can read the files.
2. Write down the exact API name, with the object, such as Opportunity.Renewal_Status__c.
3. Tell the agent it may read and query, and that it may not deploy, edit or delete anything in this task.
4. Ask for evidence on every row: a file path, a query, or the words "not found, searched in X".

The prompts

Each prompt ends the same way. It is a test, and it is the point of the page: run it twice, once with the agent reading only your project files and the CLI, and once with an org map connected, then keep the better answer. An org map is a graph of the org's metadata that the agent can query, so it can see Flows, Process Builder, Workflow Rules and permissions that are not in your repo. Clientell's is the Clientell MCP, and the same test works with any map you trust.

1. List every direct reference

Find every place in this Salesforce org that references the field [OBJECT.FIELD__c].

Cover: Flows, Process Builder processes, Workflow Rules, Apex classes and triggers, validation rules, formula fields, roll-up summaries, page layouts, Lightning pages, Lightning Web Components and Aura components, reports, email templates, permission sets and profiles.

Return a table with columns: component type, component name, how it uses the field (reads, writes, filters, displays), and the evidence (file path or the query you ran).

End with a section called "Not checked" that lists any component type you could not search and why.

Run it with and without an org map and keep the better answer.

2. Find what writes to it, and in what order

Which automations write to [OBJECT.FIELD__c]? For each one give: the component, the trigger event (before save, after save, scheduled, API), and the condition that makes it write.

Then put them in the order Salesforce runs them on a record save and flag any pair where one overwrites the other's value.

Do not guess the order. If you cannot tell from the metadata, say "order unknown" and say what you would need.

Run it with and without an org map and keep the better answer.

3. Catch the references a search will not find

Search the Apex in this project for dynamic uses of [OBJECT.FIELD__c] that a plain text search for the field name could miss:
- get('...') and put('...') calls on SObjects
- dynamic SOQL and SOSL strings
- Schema.describe calls and field-set lookups
- the API name split across string concatenation
- the API name stored in a custom label, custom setting or custom metadata record

For each hit, show the line and say how sure you are that it refers to this field.

Run it with and without an org map and keep the better answer.

4. Is it safe to delete or rename?

I plan to [delete | rename to NEW_NAME__c] the field [OBJECT.FIELD__c] in the sandbox [SANDBOX_ALIAS].

List every change that must happen first, in order. Split the list into: blockers (the deploy will fail or behaviour will break), warnings (still works, but gives a different result), and clean-up (references that become dead).

Include test classes that set the field. Do not run any deploy. Show me the plan and wait.

Run it with and without an org map and keep the better answer.

5. Who can see or edit it

For [OBJECT.FIELD__c], list every profile and permission set that grants read or edit access, and the number of active users who hold each one.

Then list any Flow, Apex class or integration user that depends on edit access to the field to do its job.

Say which result came from a query and which came from reading files.

Run it with and without an org map and keep the better answer.

6. How is it populated, and is it used at all?

Using SOQL, tell me for [OBJECT.FIELD__c]: how many records exist, how many have a value, and the most recent LastModifiedDate of a record where the field has a value.

Then compare that with the list of components that write to it. If records have values but nothing in the org writes to it, say so, because the writer may be an integration.

Give me the queries you ran.

Run it with and without an org map and keep the better answer.

7. What breaks if the type or the picklist changes?

I want to change [OBJECT.FIELD__c] from [CURRENT TYPE] to [NEW TYPE] / change the picklist values [OLD] to [NEW].

Find every component whose logic depends on the current values or type: Flow decisions, validation rules, formula fields, Apex comparisons against string literals, report filters, and any record-type or dependent-picklist setting.

For each, give the exact condition that would stop matching, and the fix.

Run it with and without an org map and keep the better answer.

8. What happens outside the org

Metadata cannot tell me everything about [OBJECT.FIELD__c]. List what in this org suggests an outside system uses it: connected apps and external client apps, named credentials, API-only users, outbound messages, platform events and change data capture subscriptions, and external ID flags on the field.

For each one, name who in the client team should be asked, and write the question in one sentence.

Do not claim the field is unused outside the org. You can only say what you found.

Run it with and without an org map and keep the better answer.

How to judge the two answers

Put the two answers side by side and check three things.

• Coverage. Which one found components the other missed? Count the misses, not the length.
• Evidence. Pick three rows from each and confirm them in the sandbox. A row with no source does not count.
• Honesty. The better answer says what it did not search. Distrust an answer that says "nothing else uses this field" without saying where it looked.

Keep the better answer, and write down which tools produced it. After a few fields you will know which questions your tools can and cannot answer on their own.

Run the dependency query yourself

This uses the Tooling API through the Salesforce CLI, in two steps. Validate both in a sandbox before you rely on them. The first step resolves which field you mean, because the same field name can exist on several objects. The second lists what Salesforce records as depending on that exact field.

Step 1: find the field's ID.

sf data query --use-tooling-api --target-org [SANDBOX_ALIAS] \
  --query "SELECT Id FROM CustomField WHERE TableEnumOrId = '[OBJECT_API_NAME_OR_ID]' AND DeveloperName = '[FIELD_WITHOUT__c]'"

For a custom object, TableEnumOrId may need the object's ID rather than its API name. If you get no rows, query CustomObject for the ID and try again. This step covers custom fields. Standard fields need a different lookup, so check them by hand.

Step 2: list the components that depend on it.

sf data query --use-tooling-api --target-org [SANDBOX_ALIAS] \
  --query "SELECT MetadataComponentId, MetadataComponentName, MetadataComponentType, RefMetadataComponentId FROM MetadataComponentDependency WHERE RefMetadataComponentId = '[FIELD_ID_FROM_STEP_1]'"

Read the result with these limits in mind:

• It needs the Tooling API. A plain sf data query without --use-tooling-api will not find the object.
• It does not cover every reference type, and results can be capped, so a short list is not proof of a short list of dependents. Check the object's reference page for what it supports.
• It shows that a dependency exists, not whether the component reads or writes the field.
• It does not see dynamic strings, outside systems or names stored as data.
• Compare its output with the Where is this used? button. When they disagree, believe neither until you open the component.

Where an org map helps

The prompts above work on whatever the agent can see. If it sees only your project folder, it sees only what you retrieved. An org map connects the agent to the org's structure, including Flows, Process Builder, Workflow Rules, Apex triggers, validation rules and permissions, so the first prompt can return components that were never in your repo.

On a benchmark of metadata questions, the same model's graded score was 86.5% with Clientell's Context Graph against 44.2% without it: 110 questions × 3 runs, graded by Claude Opus. See the method and data. It measures metadata questions, so test it on your own field before you rely on it.

Clientell MCP works in Claude Code, Cursor, Codex and VS Code. It reads records live under the user's own Salesforce permissions and does not store record data. The graph holds structure, not contents. Nothing changes in the org without your approval.

Start the 14-day trial (no card) and connect a client sandbox

Setup steps are on the install page.

Keep going

• CLAUDE.md template for a Salesforce project: put the sandbox-first and evidence rules from this page into the project file so every session starts with them.
• Salesforce Org Discovery Kit: a first-hour checklist, queries and a skill file for an org you did not build.
• Salesforce org documentation: if the real problem is that nobody wrote the org down.