Is your Salesforce ready for Agentforce? A pre-flight health check

The eight pre-flight checks

Check 1 - Record quality on the objects the agent will touch

Start narrow. Write down the objects the first subagent reads and writes: for a service agent, typically Case, Contact, Account and Entitlement; for a sales agent, Lead, Opportunity and Account. Then produce three numbers per object. Duplicate rate: run your matching rules over the existing records, not only on create, and count matches on Contact and Account by email and by name plus domain. Completeness: the fill rate on the fields the agent instructions will reference, such as Case Reason, Product and Contact Email, measured per queue rather than org-wide. Age: the distribution of LastModifiedDate on open Cases and open Opportunities.

The thresholds are blunt. A duplicate rate above a few percent on Contact means the agent attaches a comment to the wrong person within the first week. A field the instructions depend on with a fill rate under 80% will be treated as absent, and the agent will do whatever its instructions say to do when the field is empty, which is usually nothing you planned. An open Case last modified fourteen months ago is an archive candidate, and an agent reading it will act on it with complete confidence.

Check 2 - Object-model sanity

An agent reads metadata as well as data. Every custom object, field label and picklist value is a word in the vocabulary it uses to interpret an instruction like “update the case with the product affected.” If Product__c exists twice, once as a lookup and once as free text a consultant added in 2021, the agent will pick one. Elements.cloud’s research puts the scale at half of all custom objects never used and 40% of custom fields never populated. Salesforce Ben’s 2026 survey adds that more than 60% of orgs are five or more years old and 31% of admins rate their technical debt as high or very high.

Measure four things: custom objects with zero records or no reads in ninety days; custom fields with zero populated values on the Check 1 objects; picklists where one value appears in several spellings (“Enterprise”, “enterprise”, “Ent.”) or inactive values sit on live records; record types that map to no process anyone runs. Salesforce Optimizer, which used to produce part of this list, was retired in Winter ’26; the community-built Org Check covers some of the ground, and the rest is a report and a conversation. Retire before you automate. The Well-Architected framework calls this property Intentional, and it is the cheapest check to fix.

Check 3 - Knowledge and content

If the agent answers from Knowledge, the knowledge base is the product. Pull every published article with its last-published date, owner and data category. Count the articles untouched for two years, the ones whose owner has left, and the ones sharing a title with another article. Then open the Files the agent can reach. Somewhere in there is the 2023 pricing PDF, and it is now an authoritative source.

The output is a scope decision. Either the agent’s data categories are restricted to the articles that survive review, or the review finishes before go-live. Doing neither is how an agent quotes a retired SKU. This is also where Data 360 becomes a real question: if the content is large, unstructured and outside Salesforce, price it in; if it is two hundred Knowledge articles, do not.

Check 4 - Permissions and identity

The agent runs as a dedicated user. Open that user, list its profile and permission sets, and export its object and field-level permissions for every Check 1 object. Do the same for a human in the role the agent is standing in, a Tier-1 rep or an SDR, and compare. Anything the human cannot delete, the agent cannot delete. Anything the human cannot see, the agent cannot see. Where the agent user was cloned from an admin profile to make the demo work, and it often was, the fix is a day of permission-set work before anything else proceeds.

Separately, list who holds Manage AI Agents. Testing Center requires it together with System Administrator, so the people who can change agent behavior in production are exactly those holding both, and that list should be short and named. Confirm in the Trust Layer settings which external model the agent uses and that zero-data-retention applies. If legal has not seen that page, show it to them now rather than in go-live week.

Check 5 - The process, written as test cases

Agent instructions are a compressed process document. If the document does not exist, the instructions get written from memory by whoever configures the agent, and they encode that person’s habits. For each subagent, have the people who do the job today write the decision rules: when a case escalates, what the agent may never promise (refunds, dates, legal positions), which fields it updates and when, and what it says when it does not know.

Then convert the rules into the format Testing Center accepts, a CSV with an utterance, the expected subagent, the expected actions and the expected response. A fair test of readiness is whether the team can produce thirty rows per subagent in an afternoon, including negative cases: the refund request that must route to a human, the question about a discontinued product, the customer who writes in Spanish. If they cannot, the process is not documented, and the agent will infer its own rules from examples. Nobody will be able to say whether they are the rules you wanted.

Check 6 - The integration surface

List every system the workflow crosses: billing, the ticketing tool that was never fully migrated, marketing automation, e-signature. Each action that crosses a boundary needs a Flow or Apex action behind a named credential, with an owner who is paged when it fails. Where the boundary is crossed today by a weekly export and a person, the agent will do its part, say “done,” and nothing will happen downstream. That is the quietest failure on this list, because the transcript looks perfect. The output is a table of system, direction, mechanism and owner; any row whose mechanism is “manual” is out of scope for the first agent or is the first engineering task.

Check 7 - The outcome metric and its baseline

Write the one number the agent is supposed to move, in the words the business uses: case deflection rate, first-response time, share of Opportunities updated within 24 hours of a meeting. Record it for the ninety days before go-live from the same report that will judge the agent afterwards. If that report does not exist, build it first, or you will be arguing about the baseline in month two.

Add a second baseline most teams skip: expected actions per outcome. Walk the happy path for one resolved conversation and count the actions. Three is common for a well-scoped service subagent. If the design implies ten, that is the cost per resolution for as long as the agent runs, and it is cheaper to fix in the design than in the credit pack.

Check 8 - Rollback and review

Name the person who can deactivate the agent, and confirm they can do it from Setup without a change window. Name the person who reads transcripts and set the cadence: daily for two weeks, weekly for the first quarter. Decide who receives the credit-consumption alert and at what threshold. Turn on field history tracking on the fields the agent writes, so a wrong update can be traced and reversed. Governance is a launch requirement. Teams that schedule it as phase two spend phase two reconstructing what the agent did in phase one.