Agentforce Testing Center: What It Tests and What It Misses

Agentforce Testing Center is a Salesforce tool that tests an agent in bulk before launch. It checks which subagent (the new name for a topic) the agent picks, which actions it calls, and what it says. It does not check what your org does after the action runs.

Clientell AI, the AI Salesforce admin, scans your org for the Flows, triggers and validation rules an agent action will hit. Start with the free, read-only Agentforce readiness audit, then use this guide to plan the tests.

What does Agentforce Testing Center check?

Testing Center solves a hard problem well. An agent's output is not the same twice, so you cannot test it with an Apex-style equality check. Testing Center gives you a repeatable batch run instead.

Each test case holds an utterance (what a user types), the expected subagent, the expected actions and an expected outcome. The developer guide describes how the outcome check works: it compares meaning, so a differently worded answer can still pass (Run agent tests). The CLI test spec also adds quality metrics: completeness, coherence, conciseness and output latency (Generate a test spec).

Salesforce has extended the tool. Per its Testing Center update, Testing Center now sits in Agentforce Studio, and it adds three things:

• Conversation-level tests that use personas such as a "frustrated customer".
• Custom scorers, which are rules you write in plain language.
• Inline editing, so you fix test cases in the grid instead of re-uploading a CSV. Before, you had to download a CSV, edit it and upload it again.

These features suit the decision layer. Use them hard.

How do you run a test in Agentforce Testing Center?

Run tests in a sandbox. Salesforce says agent testing is available only in sandboxes, and that tests can change data (Testing API overview).

1. Publish an agent in a sandbox and make sure it is active.
2. Open Testing Center in Agentforce Studio. The older home is in Setup at /lightning/setup/TestingCenter/home.
3. Create a test suite and name it after the agent.
4. Add test data. Salesforce Help lists three ways. Generate tests from the agent's subagents and actions. Generate them from knowledge sources. Or upload your own cases (Considerations for Testing Center).
5. Choose the scorers. Add a custom scorer for any rule the built-in metrics do not cover.
6. Run the suite and read the grid. Each row shows pass or fail, the actual subagent and action, and the actual response. A healthy row lists the subagent and actions you expected. If the agent picked another one, the Actual column names it.
7. Edit failing rows inline, or fix the agent, and run again.

Write expected values with API names, not labels. A label such as "Update Opportunity" will not match the action UpdateOpportunityStage.

How do you run the same tests from the CLI?

The Salesforce CLI lets you keep tests in source control and run them in CI (continuous integration, an automatic check on each change). The developer guide describes this flow (Test an agent). It labels the guide as the legacy process while the Agentforce Studio version is documented.

1. Run sf agent generate test-spec and answer the prompts. It writes a YAML file with utterance, expectedTopic, expectedActions, expectedOutcome and metrics.
2. Edit the YAML to add cases, custom evaluations or conversation history.
3. Run sf agent test create --preview to see the AiEvaluationDefinition metadata, then run sf agent test create to deploy the test to the sandbox (Create the test).
4. Run sf agent test run --api-name <test name> --wait 20 to run the test and wait up to 20 minutes.
5. Use sf agent test resume or sf agent test results with the job ID to read results later. Add --result-format junit for CI reports.

What are the limits of Testing Center?

A sandbox has its own blind spot. It rarely holds production's record volume or odd data, so a green run proves less than it seems.

What does Testing Center not check?

A test case asserts the choice and the answer. It has no field for "the Opportunity ended in this state". Five areas fall outside it.

1. The automation behind the action. An action wraps a Flow, an Apex invocable method, a prompt template or an API call. Testing Center shows the agent called it. It does not show the Flow took the right branch, handled a null input or stayed inside Apex governor limits in bulk.
2. Who the action runs as. The run-as user sets the real blast radius. The test checks the decision, not that user's access.
3. Data after the write. Did a rollup break, a child record orphan, or a field combination appear that your reports do not expect?
4. Callouts. Actions that call an ERP, send email or fire a webhook have effects outside Salesforce. They do not roll back.
5. Regression in old automation. Record-triggered Flows and triggers built years ago were not written for an agent calling them at agent speed.

Put simply, Testing Center answers "did the agent choose right?". It does not answer "did the org survive the choice?".

What do those gaps look like in practice?

Each case below passes in Testing Center and still breaks a real org.

Correct action, blocked by a validation rule

The agent moves an Opportunity to Closed Won. It picks the right subagent and action, and the answer confirms the close. In production, a validation rule requires Contract_Signed_Date__c before StageName can be Closed Won. The DML (database write) fails.

What the user sees depends on error handling that nobody tested. In the worst case the agent says the deal is closed and it is not.

Correct action, Flow recursion

The agent updates a field on Account. A record-triggered Flow watches that field and updates related Contacts. A Contact trigger rolls a value back up to Account. At human speed this loop was harmless.

An agent can run the same action over hundreds of Accounts in an afternoon. That produces duplicate updates, drifting rollups and, in bad cases, governor limit errors mid-batch. See our guide to detecting Flow race conditions.

Correct action, wrong permissions

During a proof of concept, someone gives the run-as user a cloned admin profile to save time. Nobody revisits it. Months later, the agent edits a record the requesting user could not edit.

The decision matched the test, and the security boundary still failed. A cloned profile is hard to diff, which is why this drift goes unseen. Read the profiles vs permission sets guide, then run a permissions audit on the run-as user before launch.

How do you test what Testing Center leaves out?

Build four layers. This order is our opinion, not Salesforce guidance.

1. Testing Center for the decision layer. Cover happy paths, vague phrasing, hostile input and out-of-scope requests where the right move is to refuse. Add multi-turn tests for drift. Rerun on every prompt, subagent or action change.
2. Sandbox regression for the execution layer. For each action, run the underlying Flow or Apex against realistic data in a full sandbox and assert the final record state. Cover the normal path, each validation rule the write could trip, bulk volume, overlapping actions on related records, and a repeat run on the same record. After each run, open Setup, then Paused and Failed Flow Interviews, and check Debug Logs for the run-as user.
3. Permission tests. List the run-as user's effective access from the profile, permission sets, permission set groups and role hierarchy. Try actions on records the user should not reach and assert a refusal. Check that agent writes show in field history (for example OpportunityFieldHistory) and in the SetupAuditTrail object.
4. Callout tests. Hit a sandbox endpoint, not a mock, at least once per release. Test timeouts, partial failure and retries.

Use a full sandbox for layers 2 and 4. A developer sandbox lacks the data volume and relationships that cause these failures.

Before you start, list the automation on every object the agent writes to. Four record-triggered Flows with overlapping entry criteria are a bigger risk than another round of utterance tests. The free technical debt audit scores that overlap, and our readiness checklist covers the rest. If pilots stall after launch, read why Agentforce pilots fail.

Clientell AI follows a safe order for its own work: a read-only scan first, changes in a sandbox, and it asks before it changes anything in production. See how Clientell AI keeps your org safe.

Try it in Clientell AI: "Using the Clientell MCP, list every Flow and Apex trigger that runs when Opportunity.StageName changes. Stay read-only. Rank the ones an agent action could fire twice." Start the 14-day trial, no card.

Sources

Salesforce documentation

• Testing Center update: conversation-level testing, custom evaluations, inline editing
• Test Agents Using Testing API
• Considerations for the Testing API
• Test an Agent (Agentforce DX)
• Generate an Agent Test Spec
• Create an Agent Test
• Run Agent Tests
• Considerations for Testing Center
• Apex Governor Limits
• SetupAuditTrail object

Last reviewed October 2026

Last updated: October 22, 2026