In short
- The agent compares the change in the sandbox with the acceptance criteria in the ticket, item by item.
- It reports pass or fail for each item, with what it found, so the reviewer starts from a list instead of a blank page.
- It works in a sandbox, through an integration user with read access to what it needs.
- A person reviews the report, tests the change and signs off. The agent does not deploy.
- Patient data goes to Claude only on a plan covered by a BAA with Anthropic.
Why use an AI agent for Salesforce QA
QA is where small misses get caught: a picklist value spelled two ways, a field left off a layout, a flow that fires on create but not on edit. Checking each item by hand is slow, and the misses are the items nobody thought to check.
An AI agent reads every line of the ticket and checks each one. It does not get tired on the twentieth field. That gives the person doing QA a head start, not a replacement.
We use AI agents built on Claude in our Salesforce development work, inside the same workflow we use across the 15 Salesforce orgs we manage.
1. Write acceptance criteria the agent can check
The agent can only check what the ticket says. Clear criteria make a clear report.
- Name the object, field label, API name, type and picklist values.
- Name the layouts, record types and profiles the change applies to.
- For a flow, say when it runs and what it should change.
- For Apex, say what it should do and which tests should cover it.
2. Let the agent read the sandbox
The agent connects to the sandbox through the Salesforce API or MCP (Model Context Protocol), using a dedicated integration user. That user can read metadata and test records, and nothing in production.
Fields and layouts
Does the field exist with the right type, label, API name and values? Is it on the layouts and visible to the profiles named in the ticket?
Validation rules
Is the rule active, and does its formula match the condition in the ticket?
Flows
Is the right version active? Does the entry condition match? Do the elements set the fields the ticket asks for?
Apex
Does the code do what the ticket describes? Do the test classes pass, and do they cover the new code?
3. Get a pass or fail report on the ticket
The agent writes back a list: each acceptance criterion, pass or fail, and what it found. A fail says what is different, like "picklist has Pending Admit, ticket says Pending Admission".
The report goes on the ticket, so the developer can fix the fails before the ticket moves to Ready for QA.
Talk through your project
A free call about your integration, your CRM or whatever you are stuck on. Honest advice, even if you never hire us. No obligation.
4. A person reviews, tests and signs off
- The reviewer reads the report and checks the fails and anything marked unclear.
- They run the test scenarios as a user would, in the sandbox, against the QA sheet.
- The client reviews the change before it goes to production.
- A person deploys. The agent has no deploy access.
Guardrails for an AI agent in Salesforce QA
- Sandbox only. The integration user has no production login.
- Read access by default. Any write, like creating test records, is limited to the objects the test needs.
- Every run is logged on the ticket, so you can see what the agent checked.
- No patient data unless the setup is covered. Claude can only be used with patient data under a BAA with Anthropic, on an eligible plan. We use HIPAA-compliant Claude Enterprise licenses and can help you set one up.
Where to start with AI QA in your org
Start with field and layout checks. They are easy to define and easy to verify. Add flows and Apex once the reports match what your reviewers find.
Want an agent set up for your team, or connected to your org? See how we build AI agents for Salesforce and connect Claude to Salesforce, or book a free call.
Want help with this?
Book a free call about your CRM, integrations or reporting, or map your systems first with our free tech stack diagram builder.