TestingOps.ai

Low-code platforms · Native connection

Salesforce and TestingOps: test cases from your org's rules and flows

Much of a Salesforce org's behaviour is declared rather than coded: validation rules, required fields, picklists, record types and flows. TestingOps reads those declarations and gives its AI test agents the conditions and messages to test.

  • Native connection
  • Available
Request a demo
Connection
Native connection
Writes back
Nothing, it only reads
Last checked
7 Nov 2026

In short

Salesforce and TestingOps in short

The Salesforce connection reads an org's metadata through an External Client App that uses the OAuth 2.0 client credentials flow with a run-as integration user.

For each object it writes a knowledge-base section with record types, validation rules with their error condition formulas and messages, the Apex triggers and record-triggered flows that run on it, the new-record layout and field details; screen and autolaunched flows can be linked on their own.

Agents search those sections when they write test cases. TestingOps reads metadata only: it does not read Apex code and changes nothing in the org.

What it does

What it does for your testing

  1. 1

    Validation rules become negative cases

    Input
    Validation rules with error condition formula, error message and error field
    TestingOps
    Writes each rule with its formula (for up to 25 rules per object) and the field its message appears on
    Output
    Cases that meet the formula's condition and expect the exact message on the right field
  2. 2

    Record types and the layout become variants

    Input
    Record types and the new-record layout in Create mode
    TestingOps
    Lists the record types and the layout's sections and fields in order, with required marks
    Output
    Cases per record type that fill the form in the order users see it
  3. 3

    Flows become branch coverage

    Input
    Screen, autolaunched and record-triggered flows
    TestingOps
    Writes the start condition and the steps: decisions with their conditions, screens with fields, record operations, assignments, actions, subflows, loops and custom errors
    Output
    A candidate case per decision outcome, with the screen fields to fill
  4. 4

    Automation on save is visible

    Input
    Apex triggers and active record-triggered flows on an object
    TestingOps
    Lists trigger names, status and events, and the flows that run before or after save
    Output
    Agents know what else runs when a test saves a record

Step by step

How it works

  1. Create an External Client AppIn your org, create an External Client App with the client credentials flow, and pick a run-as integration user with API Enabled and View Setup and Configuration.
  2. Connect the orgUnder Integrations → Platforms → Low-code platforms → Salesforce, enter the My Domain address, the consumer key and the consumer secret. Test connection lists Lightning apps, objects and active flows.
  3. Link an app, an object or a flowIn the project's Knowledge tab, add a source under Low-code platforms: pick one, or paste a Lightning link or a key such as object:Account, app:Sales or flow:Leave_Approval.
  4. Objects and flows become sectionsSync writes one section per object and per related flow. Sections that did not change are not rewritten, and an object that cannot be read keeps its previous section.
  5. Agents write the casesAgents search the sections when they write test cases, which run as AI-executed steps in the running org on your execution provider.

An app link brings the objects on the app's tabs (up to 40); an object link also brings the active record-triggered flows on that object.

Connect

Setup

  1. In Salesforce Setup, open External Client App Manager, create an External Client App with the client credentials flow, and select a run-as integration user with API Enabled and View Setup and Configuration.
  2. Copy the consumer key and consumer secret, and note your My Domain address (https://company.my.salesforce.com).
  3. In TestingOps, open Integrations → Platforms → Low-code platforms → Salesforce, enter the My Domain address, the consumer key and the consumer secret, then select Test connection and Save.
  4. In the project's Knowledge tab, select Add source under Low-code platforms, pick an app, an object or a flow (or paste object:Account, app:Sales or flow:Leave_Approval) and select Sync now.
Where you connect it in TestingOps: Integrations → Platforms → Low-code platforms → Salesforce

Use cases

Use cases

Test validation rules before a release

Trigger
A team links the objects a release changes
Uses
Validation rules with formulas, messages and error fields, plus required and restricted picklist fields
Agent activity
Writes a negative case per rule and a positive case that satisfies all of them
Result
Cases that name the rule they check
Condition
Formulas are read for up to 25 rules per object

Cover a screen flow's decisions

Trigger
A screen flow is linked by its API name
Uses
The flow's screens with fields, decisions with conditions, record operations and custom error messages
Agent activity
Plans one path per decision outcome and fills each screen's fields
Result
Cases for the flow's branches
Condition
Flows from managed packages return no metadata, so their steps cannot be read

Plan record type variants

Trigger
An object with several record types
Uses
The record types, field details such as dependent picklists, and the new-record layout
Agent activity
Writes cases that create a record of each type and check the dependent picklist values
Result
Variant cases per record type
Condition
One new-record layout is read per object, as the integration user sees it; Lightning record pages are not read

Capabilities

Capabilities and limits

What is read

  • Objects (custom __c objects and common standard objects), Lightning apps (the objects on their tabs, up to 40) or single flows
  • Per object: record types; validation rules with name, active state, error message, error field and description, and the error condition formula for up to 25 rules; Apex trigger names, status and events; active record-triggered flows
  • One new-record layout per object (Create mode, as the integration user sees it) with section and field order and required marks
  • Fields: type, required, length or precision, unique, external ID, lookup targets, dependent picklist controller, restricted picklists, read-only, formula, help text and active picklist values
  • Flows: the start condition (object, create, update or delete, before or after save, scheduled or platform event, entry filters) and the steps from the flow metadata: decisions, screens with fields, record operations, assignments, actions, subflows, loops and custom errors

What is produced

  • One knowledge-base section per object and per related flow in the linked project
  • Context that agents and AI case generation search when they write test cases

Where it can write

Nothing in your org. TestingOps only reads metadata through Salesforce's REST, Tooling and User Interface APIs.

How it connects

Salesforce REST, Tooling and User Interface APIs through your My Domain, with short-lived access tokens from the OAuth 2.0 client credentials flow (no refresh token)

Account and permissions

  • An External Client App in your org with the client credentials flow, and its consumer key and consumer secret
  • A run-as integration user with API Enabled and View Setup and Configuration

Limits

  • Not read: Apex class and trigger code, Lightning Web Components and Aura components, Lightning record pages, profiles, permission sets, sharing and approval processes
  • Flows in managed packages return no metadata, so their steps cannot be read
  • Up to 40 objects per app, 25 validation rule formulas per object, 30 flows per sync and 120 lines per flow; 200 sections and 12,000 characters per section
  • Each sync reads the linked objects again and uses the org's shared daily API request limit; one object takes roughly 10 to 35 requests
  • Lightning link recognition is best effort; keys such as object:Account are the reliable form
  • Agents search the org's metadata as text; structured model facts and a model-coverage list exist only for Mendix

Example

Example: how a team uses it

Illustrative scenario, not a customer story.

A sales operations team links the Opportunity object. Its section shows a validation rule, Close_Date_Required_When_Won, whose formula rejects the Closed Won stage without a close date and shows its message on the Close Date field, and a record-triggered flow that runs after save when the amount is above a threshold.

An agent drafts a negative case for the missing close date, a positive case that closes the opportunity correctly and a case for the flow's high-amount branch, each naming the rule or flow it checks.

Frequently asked questions

Which Salesforce sources can be linked?

A Lightning app, which brings the objects on its tabs; an object, which also brings its active record-triggered flows; or a single flow by its API name. Pick them from the list, or paste a Lightning link or a key such as object:Account.

Does TestingOps read Apex code?

No. Apex triggers appear with their name, status and the events they run on, so agents know that code runs on save, but trigger code, Apex classes and Lightning components are not read.

Why an External Client App and a run-as user?

The connection signs in with the OAuth 2.0 client credentials flow of an External Client App you create in your org. Calls run as the run-as user you choose, who needs API Enabled and View Setup and Configuration to read metadata.

Will reading the org use our API limits?

Yes. Each sync, including the automatic ones, reads the linked objects again and counts against the org's shared daily API request limit; one object takes roughly 10 to 35 requests. Sections that did not change are not rewritten.

Can agents see the formula behind a validation rule?

Yes, for up to 25 validation rules per object. The section shows the error condition formula next to the rule's message and error field, so agents can work out which values the org should reject.

Does TestingOps write Apex tests or deploy anything?

No. Agents write TestingOps test cases whose steps are executed by AI in the running org on your execution provider. Nothing is deployed to Salesforce.

Next step

See how your org's rules turn into test context: request a demo and bring a sandbox with the objects of your next release.

Request a demoMore low-code integrations