Send people down different paths

A split is a fork. It tests something you already know about this visitor and sends them down one of two paths. The visitor never sees it — they just find themselves on a screen that suits their answers.

Splits are the reason a conversational form can be shorter than a form. Instead of asking everyone everything, you ask each person only what applies to them.

#Add one

Drag Split from the palette onto a + button, after the question you want to branch on.
Select the split to open Split Decision.
Build the condition.
Save.
Add steps under both the True and the False outputs.

#Building the condition

There are two ways to write it, and a button to switch between them.

#Visual mode

Three fields per condition:

Field	What you pick
Identifier	What to test. The list is grouped into Flow Inputs — the answers this flow collects — and System Variables.
Comparison	Equal to, Not equal to, Greater than, Less than, Greater or equal, Less or equal, Contains, Not contains.
Value	What to compare against.

Add Condition adds another row when one test is not enough. Underneath, a Generated Expression line shows you what you have built, which is the easiest way to check you have said what you meant.

#Code mode

Switch to code when the condition needs brackets or a mix of AND and OR.

$AGE > 18 AND $COUNTRY = 'US'

Syntax	Meaning
`$IDENTIFIER`	The value collected under that name.
`=` `<>` `>` `<` `>=` `<=`	The usual comparisons.
`%`	Contains.
`!%`	Does not contain.
`AND` `OR`	Combine tests.
`( )`	Group them: `(A AND B) OR C`.

Comparisons on numbers are done as numbers, and comparisons on text ignore capitalisation — US and us match.

#What you can test

Beyond the answers this flow collected, splits can read System Variables, including:

Flow Points — the running score from options the visitor picked
UTM Source, Medium, Campaign, Content, Term — where the visitor came from
Lead Name, Email, Phone, Stage, Quality, Tags and the rest of the CRM fields, when the visitor is a contact you already know
Account and Assigned member details

That makes some useful patterns easy:

Test	What it does
`$FLOWPOINTS >= 50`	Scores a quiz and gives a different result screen.
`$UTM_SOURCE = 'facebook'`	Says something different to people who arrived from an ad.
`$BUDGET > 5000`	Routes bigger opportunities to a booking screen instead of a brochure.

#Both branches need somewhere to go

Every split has two outputs, labelled True and False on the canvas.

If you genuinely do not need two paths, the False branch can be a single thank-you screen. It still has to exist.

#Chaining splits for more than two outcomes

A split gives you two outcomes. For three or more, put a split on a branch of another split.

Score >= 80 ?
  True  -> "Excellent" screen
  False -> Score >= 50 ?
             True  -> "Good" screen
             False -> "Needs work" screen

Order matters: test the highest threshold first. If you test >= 50 before >= 80, everybody scoring 90 takes the first branch and the second is never reached.

#When a condition seems to be ignored

Work through these:

Is the identifier spelled exactly right? $BUDGET and $Budget are the same, but $BUDGET and $BUGET are not, and a name that matches nothing is treated as empty.
Does the split come after the question? A split placed before the question it tests has nothing to read.
Are you comparing a number as text? If the question is a Text type, 10 may sort as text rather than as a number. Ask numeric questions with A Number.
Are you comparing against the label or the value? If your options have a Value set, that is what gets stored, not the label the visitor saw.