Test an AI Agent in Agentforce Testing Center: Require Outcome Receipts

If you need to test an AI agent in Agentforce Testing Center , use its subagent, action, and response evaluations as three separate pieces of evidence—not as one release verdict. The reasonable default is: run positive and negative cases in a sandbox, require fresh passes for the expected route and actions, and then verify the business effect independently before promotion. That last receipt matters. An agent can choose the expected subagent, call the expected action, and produce an acceptable response while the intended record change is absent, duplicated, applied to the wrong scope, or still waiting for approval. A green test row proves what that row evaluates. It does not automatically prove the destination outcome. This guide turns one Agentforce test run into an eight state promotion gate. The fixture stores no utterances, responses, customer records, or secrets; it keeps only pass/fail states, freshness, approval state, and an outcome receipt verdict. The Testing Center result is evidence, not the release verdict Salesforce’s current testing setup unit describes test cases with an utterance, expected subagent, expected actions, and an expected response. Its results unit then exposes the actual subagent and actions plus separate subagent, action, and response evaluations. That separation is useful because each failure points to a different repair: Subagent failure: routing selected the wrong responsibility boundary. Action failure: the route was plausible, but the required operation was missing or different. Response failure: the route and calls may be right, but the answer did not satisfy the expected semantic result. Do not collapse those fields into a single percentage. Suppose a contact update case passes response evaluation because the agent says the address was updated. If action evaluation fails, the sentence is not evidence that the write occurred. Even when all three evaluations pass, a destination read back is still the stronger proof for a side effect. The same caution applies to freshness. A passing run for agent version 12, test suite revision 4, and yesterday’s action metadata cannot certify version 13 after an instruction or permission change. Bind every promotion decision to at least: Keep the receipt content free. Store opaque identifiers, versions, timestamps, booleans, and hashes. Do not copy prompts, customer data, credentials, or full model responses into a monitoring record. There is also a safety boundary before any score matters. Salesforce’s current testing tools and considerations unit warns that agent tests can modify CRM data and tells operators to test in a sandbox. Treat that as a hard precondition, not a footnote. Use dedicated fixtures, reversible records, least privilege test identities, and cleanup verification. A successful test that touched production by mistake is not a healthy test. Turn one test run into an eight state promotion gate The inspectable artifact accompanying this article evaluates eight content free cases in a strict order. That order prevents a downstream green field from hiding an earlier failure: State Evidence Operator decision RUN INCOMPLETE Test job has not completed Wait; do not infer failure or success STALE RESULT Result exceeds the accepted evidence age Rerun against the intended versions SUBAGENT MISMATCH Subagent evaluation failed Repair routing, scope, or test expectation ACTION MISMATCH Action evaluation failed Inspect permissions, instructions, and action plan RESPONSE MISMATCH Response evaluation failed Repair answer criteria or response behavior WAITING A legitimate approval is outstanding Notify the owner; preserve the resume context OUTCOME UNVERIFIED Testing Center fields pass, destination proof is absent Read back the effect before promotion HEALTHY Fresh route, action, response, and outcome evidence agree Permit the bounded promotion decision Run the artifact with Node.js: The expected summary is: The important experiment is the last pair of cases. Both have a completed, fresh run and pass the subagent, action, and response evaluations. effect unverified has no destination receipt and resolves to OUTCOME UNVERIFIED ; healthy adds a verified read back and resolves to HEALTHY . One field changes the release verdict. That read back should match the promised outcome: For a CRM update, query the intended record with an isolated test identity and compare only the expected fields. For an email or notification, verify the sandbox outbox or provider receipt and assert exactly one accepted effect. For a knowledge answer, validate the required citations or source identifiers rather than matching prose word for word. For a workflow handoff, verify the durable handoff record, owner, deadline, and resume token. For a request requiring authority, record WAITING ; do not mark the agent stuck just because it correctly paused. This is intentionally not a universal evaluator. The classifier assumes you have mapped Agentforce’s current result fields into your own stable receipt contract. It does not judge factual quality, simulate every user phrasing, or prove that a sandbox mirrors production permissions. It also cannot decide your acceptable pass rate baseline. Salesforce’s documentation notes that generative behavior is probabilistic and that each organization must define its own production readiness threshold. Run the drill, then set the production boundary Start with one high value task whose outcome is deterministically inspectable. Do not begin with a thousand generated prompts. A smaller suite with trustworthy expectations will reveal more than a large suite whose expected actions were copied from one incidental run. 1. Freeze the test identity. Record the agent version, suite revision, action metadata revision, permission set revision, and sandbox identifier. 2. Define positive and negative cases. Salesforce’s setup guidance recommends both. Include a valid request, an invalid request, a disallowed request, a missing permission case, and an approval required case. 3. Run in a sandbox. Seed reversible records and prove cleanup. Abort if the environment or identity is ambiguous. 4. Inspect the three evaluations separately. Repair the earliest failed boundary. A response rewrite must not hide a missing action. 5. Read back the outcome. Use a destination specific assertion with an idempotency key or stable test record. 6. Repeat the healthy cases. A single pass does not expose probabilistic flakiness. Keep the run count and confidence interval visible rather than declaring certainty. 7. Promote only the pinned artifact. If instructions, actions, permissions, model configuration, or test expectations change, expire the old receipt. 8. Monitor the live outcome separately. Pre production evaluation reduces risk; it does not replace reachability, schedule, waiting state, permission, cost, or deliverable health after launch. That final boundary is where agent testing and agent health diverge. Testing asks whether selected scenarios behave acceptably before a change is promoted. Operational health asks whether the running agent remains reachable, makes useful progress, reaches its tools, respects approval boundaries, and produces the expected result now. You need both, but one cannot stand in for the other. Sidewisp is designed around that operational health layer: evidence freshness, useful progress, tool access, waiting versus stuck, and verified outcomes. Sidewisp is currently in private preview. The public site and interactive demonstration are live; a production Agentforce adapter, live monitoring engine, and automated recovery executor are not shipped. The practical step today is to keep the content free receipt beside your Agentforce test run and refuse promotion when the destination outcome is still unknown.