2026-10-30 | FieldRat

Agentforce metadata readiness: a field review before launch

An agent can select a field that looks sensible and still make the wrong decision. A label does not explain whether the value is current, who maintains it, or whether another automation will overwrite it. Before a pilot, review the few fields that decide its outcome. You do not need to clean the entire org first.

Salesforce’s September 2026 guidance on metadata gaps makes metadata context a practical admin concern. The checklist below is our own review workflow. It is not an Agentforce certification or a claim that a metadata scan predicts agent accuracy.

1. Draw a boundary around one decision

For a fictional returns assistant, the decision is whether to offer a return label for a Case. List the fields needed to establish purchase date, eligibility and any existing approval. Leave unrelated objects out of the first pass. Name the person who can explain the policy and the person who maintains the automation.

2. Write down the meaning before improving the description

Suppose the Case has Return_Approved__c, Refund_Status__c and Legacy_Return_OK__c. These names suggest overlap, but a refund status might be an accounting outcome while an approval flag records a service decision. Do not merge or retire them from names alone. Ask which value is authoritative at the moment the agent acts.

Capture the answer in the field description and your data dictionary. Include the business meaning, owner, source of updates, valid states and freshness expectation. Avoid filling descriptions with synonyms for search. The test is whether a reviewer can distinguish the fields without asking the original developer.

3. Follow the readers and writers

Check Flows, formulas, validation rules, Apex and integrations around the decision. An apparently unused field may be written only during a seasonal process. A highly populated field may contain a stale value copied years ago. Record what the scan actually covers and ask the integration owner about consumers outside that boundary.

FieldRat QuickScan covers 11 metadata types natively; DeepScan reviews 23 types from a metadata ZIP. These are different evidence sources. Neither establishes that an external consumer does not exist. Use population together with dependencies and owner confirmation; do not turn a zero into a deletion instruction. Follow the field retirement checklist when retirement is the actual goal.

4. Check access in the context that will act

Ask which user or execution context runs each action, which records it can read, and which fields it can change. Test the configured agent and action with deliberately restricted access. A successful admin test proves very little about a service user. Do not grant broad access just to make a failing test turn green; decide whether the action should be available at all.

Keep sensitive fields outside the required scope unless the business decision needs them. Separate permission failures from missing data and ambiguous policy. Those three failures need different handling, and an agent should not invent a value to move past any of them.

Salesforce documents agent context and user context separately. Review the actual action configuration and execution mode when testing access.

5. Test disagreement and stop conditions

For the fictional Case, include: eligible purchase with no approval; approval present but refund already complete; missing purchase date; an old flag contradicting the current policy; and a user unable to see the approval field. Write the expected result before running the test. Some cases should escalate to a person rather than produce a return label.

For each run, retain the relevant field values, actual action, expected result and reviewer decision. If you change a definition or an automation, repeat the affected cases. A nice description helps explain intent; a passing behaviour check is the evidence that the implemented process follows it.

Leave with a small evidence pack

Your first review can finish with five things: the decision boundary, a short dictionary of authoritative fields, a readers-and-writers list with known gaps, the permission checks, and the test results with unresolved cases assigned to an owner. This is a more useful launch discussion than a single readiness percentage.

If Vibes is helping with the implementation, keep the metadata diff and review it like any other change. TechParrot’s Vibes budgeting guide explains why reviewed changes are a better pilot measure than generated lines. For FieldRat scan scope and handling of metadata, see the product documentation.

Common questions