Salesforce Flow Testing With AI Agents

What Is a Flow Test in Salesforce?

A flow test in Salesforce is a saved scenario that runs a flow against a chosen triggering record or set of input values and checks assertions about the result. Flow tests now live in Flow Test Mode, a beta view that Salesforce says replaces the Debug button for record-triggered and autolaunched flows.

Salesforce puts Flow at over 690 billion monthly executions and says the capabilities for testing flows "still have some gaps" in its Flow Test Mode announcement.

Which gap matters to you depends on the flow type:

Salesforce's own Summer '22 admin post introduced flow tests as record-triggered only and positive-testing only. Salesforce Help now documents automated scenarios for autolaunched and Data Cloud-triggered flows, plus negative assertions for testing error handling.

For where flows sit among Apex, Lightning Web Component and integration tests, see this Salesforce testing guide.

How Do You Test Salesforce Flows Before Deploying Them?

Test every path of the flow in Test Mode in a sandbox, with assertions on the expected result, before the flow reaches production. Salesforce's own Automated Flow Testing guidance recommends one test scenario for every path a flow can take.

• Turn on Test Mode - In Setup, open Process Automation Settings and select Enable Flow Test Mode (Beta). Any org you deploy those tests to needs the beta setting turned on as well.
• Save a scenario per path - Pick the path, set the triggering record or input values, and save the scenario so the next change to the flow reruns it in one click.
• Turn on Scenario Testing Automation - This lets you add assertions, and the run results gain an Expected Results tab with each assertion's status. A scenario passes only when every one of its assertions passes.
• Use isolated test data - Point the scenario at an Apex class with a @testSetup method. The records roll back after the run, like an Apex unit test, so live org data stays as it was.
• Mock actions and subflows - Give an HTTP callout, Apex action or subflow a fixed output. Set Path After Mock Output to the fault path to test the flow's error handling without breaking anything real.
• Use fixed values for test data - Formulas aren't accepted, so a date you set to today keeps that same date on every later run.

Salesforce caps a flow at 200 tests. Its flow testing limits page also lists what automated scenarios can't cover yet: Wait elements in autolaunched flows, paths that run asynchronously, and automatic evaluation for flows triggered by a record deletion.

When the logic depends on bulk inserts or related records built in code, an Apex test class gives you more control than a flow scenario. The Salesforce Apex trigger guide walks through writing one.

What Can Agentforce for Flow Test on Its Own?

Agentforce for Flow Headless drafts and runs Test Mode scenarios for you. In a terminal AI tool connected to your org, you ask the tool to find the flow, say you want to update it, and enter the prompt create flow tests.

It reads the flow's structure, decision outcomes and required fields, then proposes success, fault and edge-case scenarios for a record-triggered, autolaunched or Data Cloud-triggered flow, according to Salesforce's guide to generating test scenarios. Once you approve the list, it builds the scenarios, attaches them to the flow, validates them and runs them.

Check you have these in place first:

• License - the Agentforce Platform Developer and Admin permission set license, plus the Agentforce Developer and Admin Tools permission set, to use it in Agentforce Vibes.
• Flow permission - Manage Flow, which Salesforce lists for working with flows and Agentforce for Flow features in Flow Builder.
• Connection - a terminal AI tool already connected to the Salesforce org you want to test.

The output is ordinary Test Mode scenarios, so it carries Test Mode's scope. Screen flows and asynchronous paths stay outside it, and each check runs in a transaction that rolls back.

Review every drafted assertion against the requirement before you approve it. A scenario that asserts the wrong expected value still passes.

Which Flow Failures Do Native Tests Miss?

Native flow tests check one flow's logic inside a transaction that rolls back. They don't show what a user sees after the whole save commits, and the whole save runs a lot more than your flow.

Salesforce's order of execution runs before-save flows, before triggers, validation rules, after triggers, assignment rules, auto-response rules, workflow rules and escalation rules before it reaches after-save record-triggered flows. Emails and asynchronous flow paths run only after the commit.

• Screen flows - Test Mode doesn't support them yet. The screens, conditional visibility and reactive components a user clicks through get checked by hand or in a browser.
• Other automation on the same record - On a case, assignment and escalation rules run in the same save as the flow. The owner a support agent sees is the combined result, and a flow-only test sees just its own update.
• Committed side effects - The escalation email goes out after the commit. A scenario that rolls back never sends it.
• Permissions and page setup - A field the flow sets doesn't help if the agent's page layout hides it, or if their profile can't open the queue's list view.

The Flow Builder debugger can run a flow as another user, but only in a sandbox. Unless you select Run flow in rollback mode, it also performs real DML and Apex, and closing the run doesn't undo them.

Every gap above shows up in the browser, which is also where Salesforce UI tests have been expensive to keep alive. The Salesforce test maintenance cost breakdown shows where that cost comes from.

Note: TestMu AI's Kane CLI checks the record page, list views and tasks after a flow runs, from a plain-English objective, and returns an exit code your CI job can gate on. Try TestMu AI free

How Do AI Testing Agents Test a Flow Through the Lightning UI?

An AI testing agent reads a plain-English objective, opens your sandbox in a real browser, makes the same save a user makes and asserts on what the page shows afterwards. It tests the flow through its result, so the check also covers the automation, layouts and permissions around the flow.

Lightning pages are hard on selector-based scripts. Salesforce's LWC shadow DOM guide explains that Lightning Web Components encapsulate their markup in a shadow tree, with a synthetic shadow polyfill in Lightning Experience and Experience Cloud. Locators have to reach inside each component, and they break when a component changes.

Kane CLI works from the rendered viewport instead. It waits until the Lightning page is visually ready rather than relying on DOM or network signals, and its autoheal re-resolves a moved button by what the button does. Low-confidence matches are rejected instead of healed into a pass.

For sign-in, complete an SSO or MFA login once in a Chrome profile and point Kane CLI at that profile for later runs.

kane-cli generate "Test a Salesforce record-triggered Flow on Case, as a support agent sees it in the Lightning UI. The flow runs after save on create or update when Priority changes to High. If Origin is Phone and Status is New, it sets the Escalated checkbox, assigns the Case to the Tier 2 Support queue, and emails the queue. If that update fails, a fault path creates a Task named 'Case escalation failed' on the Case. Cases that are not Phone or not New are left unchanged. Two hours after creation, if the Case is still New, the flow creates a Task 'Follow up: High priority case still New after 2 hours' for the owner. Cover the Case record page fields, the owner, Activity timeline tasks, and the Tier 2 Support queue list view." --name salesforce-flow-case-escalation

---
mode: testing
max_steps: 30
timeout: 300
variables: {}
---

# Create a new high-priority phone case and verify successful escalation

## Step 1
Create a new high-priority phone case and verify successful escalation.

Verifies that a new Case with Origin 'Phone', Status 'New', and Priority 'High' is automatically escalated and reassigned to the Tier 2 Support queue upon creation.

Navigate to the 'Cases' tab from the navigation bar. Create a new case with:
Case Origin: Phone
Status: New
Priority: High
Subject: Customer reports critical system outage
Save the new case.

On the Case record page, locate the 'Details' tab and find the 'Escalated' checkbox. Verify the 'Case Owner' field.

Navigate to the 'Cases' tab and select the 'Tier 2 Support' queue list view. Verify that the case with the subject 'Customer reports critical system outage' appears in the list view.

---
mode: testing
max_steps: 40
tags: [salesforce, case-escalation-flow]
variables:
  case_subject:
    value: "Flow check: phone case escalation"
---

# High priority phone case escalates to Tier 2 Support

## Create the case
Open the Cases tab and click New. Create a case with Case Origin "Phone", Status "New", Priority "High" and Subject "{{case_subject}}", then save it.
Verify the case record page shows the subject "{{case_subject}}".

## Check the record page
On the case record page, verify the Escalated checkbox is checked and Case Owner shows "Tier 2 Support".

## Check the queue list view
Open the Cases tab, switch the list view to "Tier 2 Support", and verify a case with subject "{{case_subject}}" is listed.

## Check the scheduled path is queued
Open Setup, enter "Time-Based Automations" in Quick Find and open that page.
Verify a pending entry for the Case High Priority Escalation flow is listed.

# One time: use a Chrome profile that has already signed in to the sandbox
kane-cli config chrome-profile ./profiles/sf-sandbox

# Each run
kane-cli testmd run ./tests/escalate-phone-case_test.md --url "$SF_SANDBOX_URL" --agent --headless

How Do I Check Test Coverage of a Flow in Salesforce?

Salesforce measures flow test coverage when you deploy flows as active in production. Turn on Deploy processes and flows as active in Process Automation Settings and enter the coverage percentage your org requires. The requirement covers processes and autolaunched flows, and it doesn't apply to flows that have screens.

Coverage is read from the Tooling API FlowTestCoverage object. This query from Salesforce Help lists the active autolaunched flows and processes that have no coverage:

SELECT Definition.DeveloperName FROM Flow
WHERE Status = 'Active'
AND (ProcessType = 'AutolaunchedFlow' OR ProcessType = 'Workflow' OR ProcessType = 'CustomEvent' OR ProcessType = 'InvocableProcess')
AND Id NOT IN (SELECT FlowVersionId FROM FlowTestCoverage)

• The calculation - covered latest flow versions, divided by all active versions plus the latest inactive versions that have coverage. Salesforce's worked example of 10 flows comes out at 90%.
• Which tests count - Salesforce's own pages disagree. The deploy page says at least one Apex test must cover the percentage, while the flow testing limits page says automated Test Mode scenarios count, manual scenarios don't, and Apex tests aren't included. Run the query in your org after a full test run before relying on either.
• Path coverage on the canvas - From Winter '27, Test Mode highlights the paths that automated tests cover, according to Salesforce's Test Mode announcement.

Browser runs from an AI testing agent don't add to either number. They answer a different question: whether the behavior a user depends on still works once the flow, layouts and permissions ship together.

How Do I Test a Scheduled Flow in Salesforce?

Test the logic and the scheduling separately. Automated Test Mode scenarios don't support asynchronous paths, so you test a scheduled path's elements in the debugger and check its scheduling in Setup.

Salesforce's scheduled paths documentation says pending paths appear on the Time-Based Automations Setup page, and the debug log records a FLOW_SCHEDULED_PATH_QUEUED event when a path is queued. It also defines the behavior worth testing:

• Scheduled on entry - A record that newly meets the conditions queues the path.
• Not queued twice - Updating an unrelated field on a record that already met the conditions doesn't queue the path again, and the existing schedule stays.
• Canceled on exit - An update that makes the record stop meeting the conditions cancels the pending path.
• Rescheduled on a new date - Changing the time-source field to a future date schedules the path for the new time.
• Retries - A failed scheduled path interview sends an error email and retries up to five times, after 15, 30, 60, 120 and 240 minutes.
• Volume - An org gets 250,000 scheduled path interviews per 24 hours, or 200 per user license if that's higher. Interviews over the limit wait for the reset.

Schedule-triggered flows, which run on a set date and frequency instead of a record change, still use the debugger until Test Mode adds them.

An AI testing agent covers the scheduling half in the browser. Create the case, open Time-Based Automations and verify the pending entry, then change the case Status to Working and verify the entry is gone. That replaces the two-hour wait in the generated cases.

How Should You Split Flow Testing Between Salesforce and an AI Agent?

Give each layer the question it answers best, and run the browser layer after every deployment to a sandbox.

Salesforce ships three seasonal releases a year, usually Spring in February, Summer in June and Winter in October, according to its Spring '26 release page. Each one is a reason to rerun the browser layer against a preview sandbox.

Turn the user-visible checks into named Salesforce test cases and add them to your regression testing suite, so no release goes out without them.

Next Steps for Salesforce Flow Testing

Pick the flow with the most branches, turn on Test Mode in a sandbox, and have Agentforce for Flow draft its scenarios. Then describe the same flow to Kane CLI, tighten the generated tests and run them against the sandbox record page before the next release.

The Kane CLI introduction covers installation and sign-in.