Agentforce Testing Center: What It Does & Doesn't Test

There is a category error running through most Agentforce test plans, and it is easy to make because Salesforce's tooling is genuinely good at the part it covers.

Agentforce Testing Center tests the agent. Your org is a different system, and it needs its own tests.

That distinction sounds pedantic until the first production incident, when the postmortem shows the agent behaved exactly as designed and the org still ended up in a bad state. This piece is about that seam: what Testing Center covers well, where its scope ends, and what a full testing strategy has to add on the far side of the action call.

What Testing Center actually does, and does well

Per Salesforce's own Testing Center documentation, the tool evaluates an agent's selected topic, selected action, and generated response against ground truth and predefined metrics. You supply utterances and the expected topic, action, and response. It runs them in bulk and reports where the agent diverged.

Salesforce's April 2026 update extended this in three ways worth knowing about. Conversation-level testing moves evaluation beyond single utterances to multi-turn exchanges, which matters because the failure mode in real agents is rarely turn one. It is turn four, after context has accumulated and the agent has drifted from the topic it correctly selected at the start. Custom evaluations let you define your own pass criteria instead of relying only on built-in metrics. Inline editing removes the CSV round-trip that made iterating on test cases tedious.

Take the problem it solves seriously, because it is a hard one. LLM output is non-deterministic. The same utterance can produce different phrasing on consecutive runs, which means you cannot assert equality the way you would in an Apex test. Testing Center gives you a repeatable, bulk-executable harness for a system that does not produce identical output twice. That is real engineering, and before it existed, teams were testing agents by typing into a chat window and forming impressions.

For the decision layer, this is the right tool and you should use it. The question is what sits outside the frame.

The seam: choosing an action versus executing one

An Agentforce action is a wrapper. Underneath is a Flow, an Apex invocable method, a prompt template, or an API call. The agent's job ends at selection and invocation. Everything after that is your org running the way it always has.

Testing Center evaluates the selection. It confirms the agent picked UpdateOpportunityStage rather than CloseOpportunity, and that its response to the user was appropriate. That is a genuine and useful assertion.

What it does not assert is what happened when UpdateOpportunityStage ran against a real record, in a real org, with your validation rules, your record-triggered Flows, your Apex triggers, your sharing model, and your integrations all active.

Put as two questions:

• Did the agent choose the right action? Testing Center answers this.
• Did the org survive the agent taking that action, correctly, at volume, without breaking something adjacent? Nothing in Testing Center answers this.

This is not a criticism of the tool. It is scope, and Salesforce has been reasonably clear about that scope. The problem is that teams read "Testing Center" as "the place where Agentforce gets tested" and stop there. The name is doing more work than the product claims.

Five things nobody is testing

Here is the specific list of what falls through the gap.

1. The automation the action invokes. If your action calls a Flow, Testing Center confirms the agent called it. It does not confirm the Flow completed, took the expected branch, handled a null input, or stayed inside governor limits when called 200 times in an hour. The Flow's own test coverage, if any, was written for the trigger paths that existed before the agent did.

2. Permission-boundary correctness at execution time. The action runs as some user. Which one, and what that user can reach, determines the actual blast radius. Testing Center evaluates the agent's decision, not the effective access of the identity executing it. If the runtime user holds more than intended, every correctly chosen action executes with more reach than you designed for.

3. Data integrity after the write commits. Did the update leave records in a valid state? Did it break a rollup, orphan a child record, or set a field combination that your reporting logic does not expect? The agent chose correctly and the data is still wrong, because correctness at the decision layer is not correctness at the data layer.

4. Integration and callout behaviour. Actions that push to an ERP, fire a webhook, or send email have effects outside Salesforce. In a test context these are typically mocked or skipped. In production they are not, and they do not roll back.

5. Regression against existing declarative automation. Your org already has record-triggered Flows, process automation, validation rules, and triggers built over years. The agent's action is a new entry point into all of it. Nobody wrote those automations expecting to be invoked by a language model at agent cadence.

Three failure modes, concretely

Abstractions do not persuade anyone to write more tests. Here are three specific ways this breaks.

Failure mode 1: correct action, blocked by a validation rule

The agent handles an inbound request to move an Opportunity to Closed Won. It selects the right topic, invokes the right action, and generates a confirming response. Testing Center marks it green on all three.

In production, a validation rule requires a populated Contract Signed Date before Stage can equal Closed Won. It was added two years ago by a finance-driven change request. The DML fails.

What happens next depends on how the action handles errors, and that is the part nobody tested. The good outcome is a clean failure surfaced to the user. Common outcomes are worse: the agent reports success because it received an invocation result rather than a commit result, or the error surfaces as an unhandled fault message that means nothing to the person reading it. Either way the user believes the deal is closed and it is not.

Testing Center could not have caught this. It evaluated the agent's choice, and the choice was right.

Failure mode 2: correct action, Flow recursion

The agent updates a field on Account. That field is watched by a record-triggered Flow, which updates related Contacts. A Contact trigger rolls a value back up to Account. Under normal human usage this cycle is slow and low volume, so it settled into an equilibrium nobody investigated.

The agent runs the same action across 400 Accounts in an afternoon. The recursion depth that was harmless at human pace now produces duplicate updates, inconsistent rollups, and in the worst case governor limit failures partway through a batch, leaving records in mixed states.

Every individual action was correct. The aggregate behaviour was not, and the failure is a function of volume and ordering rather than of the agent's decision. Our guide on detecting Salesforce Flow race conditions covers this class of problem in depth. Agent-driven volume makes latent race conditions surface much faster than manual usage ever did.

Failure mode 3: correct action, wrong effective permissions

The agent is provisioned during a proof of concept. Somebody assigns the runtime user a cloned admin profile because scoping properly would have delayed the demo. The clone is never revisited.

Six months on, the agent handles a request that involves updating a record the requesting user could not have edited themselves. The agent's action executes because the runtime user can do it. The correct behaviour was to refuse.

Testing Center evaluated the agent's decision against ground truth, and the decision matched. The security boundary was violated at the execution layer, not the decision layer. This is why the profile-versus-permission-set question is a testing question and not just a hygiene one. The profiles vs permission sets migration guide covers why a cloned profile is nearly impossible to diff, which is exactly the property that lets this drift go unnoticed. Running a permissions audit against the agent's runtime user before launch catches it in minutes.

What a complete testing strategy adds

Four layers, in the order I would build them.

Layer 1: Testing Center for the decision layer

Use it as designed and push it hard. Build utterance sets that cover happy paths, ambiguous phrasing, adversarial input, and out-of-scope requests where the correct behaviour is refusal. Use conversation-level testing for multi-turn drift, because that is where the interesting failures live. Use custom evaluations to encode criteria your business cares about that the built-in metrics do not express.

Treat this as unit testing. Fast, high volume, run on every prompt or topic change.

Layer 2: sandbox regression for the execution layer

For each action the agent can invoke, you need a test that executes the underlying automation against realistic data in a full sandbox and asserts the resulting state.

Cover at minimum:

• Positive path. Action fires, correct records change, correct final values.
• Validation rule collisions. Deliberately construct records that violate each rule the action's writes could trip. Assert the failure is caught and surfaced cleanly rather than swallowed.
• Bulk behaviour. Execute at the volume the agent will realistically reach. 200 records is the standard Apex bulk floor and it is not enough here. Test at your actual expected daily volume.
• Concurrency and recursion. Fire overlapping actions on related records. Watch for double-fires, rollup drift, and depth errors.
• Idempotency. Run the same action twice on the same record. Assert the second run is either a clean no-op or correctly rejected, because retries happen.

A full sandbox matters here specifically because a developer sandbox lacks the data volume and record relationships that produce these failures.

Layer 3: permission and security testing

Test the agent's runtime identity as a first-class subject, not as configuration.

• Enumerate the runtime user's effective access, object by object and field by field, from every source: profile, permission sets, permission set groups, role hierarchy.
• Attempt actions on records the runtime user should not reach. Assert refusal.
• Confirm field-level security blocks the agent from reading sensitive fields it does not need.
• Verify agent writes are attributable in field history and SetupAuditTrail.
• Re-run all of the above after any permission change, on a fixed cadence.

The failure signature here is silent. Nothing errors when an agent has too much access. It just quietly does more than you intended, and you find out during an access review or an incident.

Layer 4: integration and callout testing

For any action that reaches outside Salesforce:

• Test the callout against a sandbox endpoint, not a mock, at least once per release.
• Test timeout and failure handling. What is the record state when the callout fails halfway?
• Test the rollback story explicitly. Most callouts have none, which is a design constraint you should surface rather than discover.
• Test rate limits and retry behaviour, since agent-driven volume differs from user-driven volume in shape as well as size.

The checklist: Testing Center plus X

Run through this before an Agentforce deployment goes to production.

Testing Center (decision layer)

• Utterance coverage for every topic, including ambiguous and out-of-scope phrasing
• Multi-turn conversation tests for context drift
• Custom evaluations for business-specific pass criteria
• Negative tests where correct behaviour is refusal or escalation
• Test suite re-run on every prompt, topic, or action change

Sandbox regression (execution layer)

• One executable test per action against realistic data in a full sandbox
• Validation rule collision test per rule the action's writes could trip
• Bulk execution at realistic production volume
• Recursion and concurrency test for related-object automation
• Idempotency test for repeat execution
• Post-execution data integrity assertions, including rollups and required-field combinations

Permission and security

• Effective-access enumeration for the agent runtime user, with source attribution
• Negative access tests asserting refusal on out-of-scope records
• Field-level security verification on sensitive fields
• Audit attribution confirmed in field history and SetupAuditTrail
• Re-run scheduled after every permission change

Integration

• Live sandbox endpoint test per callout action
• Timeout and partial-failure state assertions
• Documented rollback story, including where none exists
• Rate limit and retry behaviour under agent-cadence volume

Org readiness

• Existing automation inventoried per object the agent writes to
• Technical debt in those automations assessed before the agent is pointed at them
• Rollback and kill-switch procedure documented and rehearsed

That last group is the one teams skip. If an object already carries four record-triggered Flows with overlapping entry criteria, adding an agent as a fifth caller does not create the problem. It just makes the problem run more often. The technical debt audit scores exactly this surface, and it is a more useful pre-deployment signal than another round of utterance tests.

Common questions

Does Testing Center run the actual action, or simulate it?

Its evaluation is scoped to the agent's selection and response against ground truth and predefined metrics. Treat downstream execution as something you verify separately in a sandbox regardless, because that is where your validation rules, triggers, and integrations live.

Is this a reason not to deploy Agentforce?

No. It is a reason to budget for a testing layer that most Agentforce project plans currently omit. The tool covers a hard problem well. The gap is in what teams assume it covers.

How much of this can be automated?

The sandbox regression layer maps well onto Apex test classes and whatever CI you already run for deployments. Permission testing automates cleanly through metadata queries. Integration testing is the layer that stays partly manual, because live endpoint behaviour resists full automation.

Who owns this work?

In practice it lands on whoever owns the org rather than whoever built the agent, and that split is the root cause of it going undone. The agent team declares success on Testing Center metrics. The admin team finds out later. Assign execution-layer testing explicitly at project kickoff.

What is the minimum viable version if we are short on time?

Three things. One executable sandbox test per action asserting final record state. An effective-access review of the agent's runtime user. A documented kill switch. That is a weekend of work and it catches the majority of what actually goes wrong.

The honest summary

Salesforce built a good tool for a hard problem. Testing non-deterministic agent output at scale was not solvable with existing Salesforce test tooling, and Testing Center solves it. The April 2026 additions of conversation-level testing, custom evaluations, and inline editing make it meaningfully better than the first release.

It is also scoped to one layer. It evaluates whether the agent chose the right topic, action, and response. Your org has to survive that action executing, at volume, alongside years of automation that predates the agent entirely.

Both questions need answers. Right now most teams are only asking the first one.