Test a screen flow that branches on an answer

The flow under test

The branch assertion is the one that matters, and it works by checking what is on screen and what deliberately is not.

• The flow starts - screen 1 of 3, so the position in the flow is known.
• The branch is taken - a company name field appears and a support priority field does not.
• The branch completes - company and budget captured on the sales path.
• A record is created - with an id, a record type and a summary of what was captured.

Asserting the absence of the support field is what proves the branch rather than the form. A flow that renders every field from both paths would satisfy a presence-only check completely.

The test file

The screen position is asserted at the start, so a flow that skips a screen or starts in the wrong place fails immediately rather than producing a confusing record at the end.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/salesforce-clone-app/flow?reset=true
max_steps: 45
tags: [salesforce, crm, automation]
---

# Salesfource 28.5: Screen flow with branching

Catalog objective: complete an intake screen flow with branching.
Key assertion: the flow finishes with a success screen and a record is created.

## Start the flow
Verify the page title reads "Customer intake" on "Screen 1 of 3", choose the sales enquiry option, type "Sam Rivera" into "Your name", and click "Next".

## Verify the branch taken
Verify the flow took the sales branch by showing a "Company name" field rather than a support "Priority" field.

## Complete the branch
Type "Riverfield FC" into "Company name", type "50000" into "Approximate budget", and click "Finish".

## Verify the success screen and the created record
Verify a banner titled "Thanks - you're all set" appears naming a created record with its id, and the success screen shows a "Record type" and a "Summary" of what was captured.

The final assertion checks the record type as well as the id, because a record created on the right path with the wrong type lands in the wrong report.

Step by step coverage

A start, a branch, a completion and the record.

Each branch needs its own file. Two paths through one test file makes a failure ambiguous about which branch broke.

Running it

kane-cli testmd run tests/salesforce/screen-flow_test.md

Add the support branch as a sibling file, since the whole point of a branching flow is that both paths work.

Declarative automation is edited by admins rather than engineers, which makes a readable test valuable to both. Generating the sibling branch covers producing the pair, and Kane CLI as a QA agent covers the wider suite.