Salesforce publishes a refresh interval for every sandbox type: once a day for a Developer or Developer Pro sandbox, once every five days for a Partial Copy, and once every twenty nine days for a Full sandbox, the only kind that carries all of production's data (Sandbox types and limits). Data storage is capped too, at 200 MB, 1 GB and 5 GB for the smaller three. And Salesforce's own setup guidance says plainly that changes in production are not reflected in your sandboxes. So the sandbox an agent is tested in is up to a month stale, can be reset at most once in that month, and is shared by everyone who needs one. The Salesforce world is a stateful Salesforce mock built for testing agents: the same URLs, the same errors and the same validation rules as the real API, on your machine, fresh for every run, verified against the real system.
Salesforce sandbox refresh limits
A refresh is the reset button, and it can be pressed once a month. An agent test suite needs it pressed before every run, because an agent that converted a lead or closed an opportunity has changed the fixture for the run after it. Teams answer by writing cleanup scripts that never quite catch everything, or by testing against a Developer sandbox with no data and hand built records. A world is a pseudonymized copy of your own org, taken when you ask for it: the same accounts, contacts, leads and opportunities in the same stages, under new names. Every run starts from those bytes, in milliseconds, and ends by throwing the world away.
A stateful Salesforce mock: leads, opportunities, stages, validation rules
The world keeps leads, accounts, contacts and opportunities with their stages, amounts, close dates and owners; tasks and notes; the validation rules and required fields your org enforces. It keeps Salesforce's rules with them. A lead converts into an account, a contact and an opportunity in one step, and a converted lead cannot be edited. An opportunity moves through its stages, and a stage that a validation rule refuses gets the real error with the rule's own message. A record another process holds is locked, and the agent that runs into it sees the row lock error Salesforce would return. Everything the agent creates or changes stays in the world, so the second request sees what the first one did.
Test your AI agent against Salesforce
Point the agent's Salesforce client at the world. Nothing in the agent changes. The path is three commands: the first copies the org and writes the worlds folder, the second turns your own queue export into tasks, one per row, with the expected outcome on the rows where you know it, and the third runs the agent three times on fresh copies and writes the report. The three steps take about ten minutes; the GET ACCESS form on this page is where the Salesforce world starts.
Grade what the agent did, not what it said
A run starts from a mark and ends with a diff: every stage moved, every amount changed, every owner reassigned, every lead converted, every task created. The transcript says the opportunity was moved to negotiation; the diff shows the stage unchanged and a note added. The transcript says the duplicate lead was merged; the diff shows the wrong one gone. Where the org carries money, a discount past the approval threshold or a close date pulled into the wrong quarter, the diff says so in the numbers the org keeps. The report gives every task a verdict and a reason, and replays the worst run to the byte.
Break it on purpose
Salesforce meters API requests over twenty four hours and locks rows under contention, and an agent working a queue will meet both at the worst moment. In the world that moment is on your schedule: a request limit error on every third call, a row lock in the middle of a conversion, an outage, a slow API, an expired session. Does the retry logic create the task twice? Does the agent report the lead converted when the call never went through? Then move the clock, so the close dates pass and the quarter rolls, and read the diff again.
Salesforce test environment for agents, in CI
The same command that runs on a laptop is the CI step the first command wrote. No sandbox to book, no refresh to wait for: the world starts fresh inside the job, the agent runs every task, the report is the artifact, and nothing leaves the machine. Every world in the catalog takes the same path; HubSpot, Zendesk and Stripe are three more of them, and the docs are the path in full.