> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getflowpilot.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Navigation and branching

> How users move through a flow, and the honest options for showing different content or sending users down different paths.

A flow is an ordered list of screens. Users move forward and back through that list with [actions](/editor/interactions-and-actions). This page covers linear navigation, then the realistic options for making a flow respond to state: conditional content (well supported) versus conditional paths (limited in the editor today).

## How the editor builds a flow

The editor has no node-graph canvas. You build a flow as an ordered list of screens in the [Layers panel](/editor/multi-step-flows) (Advanced) or the [Screens panel](/editor/screens-panel) (Simple), and the connections between screens are maintained automatically to match that order. Navigation is driven by actions, not by drawing arrows.

<Note>
  If a flow does contain branching [logic nodes](#conditional-paths-today) (created by a template or imported schema), [Simple mode](/editor/editing-modes) shows them as read-only **"Logic step"** dividers in the Screens panel and cannot edit them. Switch to Advanced to inspect them. There is still no editor UI to create logic nodes in either mode (see below).
</Note>

## Linear navigation

Four actions move the user around:

| Action                              | What it does                                                               |
| ----------------------------------- | -------------------------------------------------------------------------- |
| **Go to Next Screen** (`goNext`)    | Advance to the next screen in order. Stays correct as you reorder screens. |
| **Go Back** (`goBack`)              | Return to the previous screen.                                             |
| **Navigate to Screen** (`navigate`) | Jump to one specific screen you pick.                                      |
| **Close Flow** (`closeFlow`)        | End and dismiss the flow.                                                  |

For a straightforward onboarding, you mostly use **Go to Next Screen** on each screen's primary button and **Close Flow** on the last one. See [Building multi-step flows](/editor/multi-step-flows).

## Conditional content vs conditional paths

There are two different things people mean by "branching":

* **Show different content** on the same screen depending on state. This is fully supported with [dynamic values](/editor/dynamic-values) and is the recommended approach.
* **Send the user to a different screen** depending on state. This is limited in the editor today. Read the next section before you design around it.

When you can express a difference as "different text, color, or visibility," prefer a single screen with dynamic values. It is simpler to build, simpler to preview, and avoids duplicate screens.

## Conditional paths today

A **Navigate to Screen** action picks one fixed screen from a dropdown. Its target is not a [dynamic value](/editor/dynamic-values), so you cannot make a single navigate action point at different screens based on a variable.

The flow schema does define branching node kinds (`condition`, `assign`, `abTest`) that the SDK evaluates at runtime, but **the editor has no UI to create them**. There is no palette that places a condition or A/B node onto the flow; the only node you can add is a screen.

So, in practice:

* For **A/B testing** different flows, use a placement-level [experiment](/dashboard/experiments). That is the supported way to split traffic between variants. Do not try to build A/B logic inside a flow.
* For **in-flow conditionals**, use [dynamic values](/editor/dynamic-values) to change what a screen shows.
* The `api`, `event`, and `subflow` node kinds are **not supported** by the SDK at all (they are dropped). Do not build with them. They appear only in advanced schema discussions; see the [flow schema reference](/reference/flow-schema).

## Example

**A quiz result on one screen.** Suppose a quiz sets a `score` Number variable. Instead of routing to three different result screens, use a single results screen and make its properties dynamic:

* Heading text, driven by `score`:
  * when `score` **at least** `80` -> `Great job!`
  * when `score` **at least** `50` -> `Nice work`
  * else -> `Keep practicing`
* Heading **Color**, with the same thresholds (green / amber / red).

Because the [first matching rule wins](/editor/dynamic-values), the `80` rule comes before the `50` rule. The screen now "branches" its content from one place, and a single **Close Flow** (or **Go to Next Screen**) button ends the quiz.

If you truly need to send users to genuinely different next steps, model that as separate flows behind an [experiment](/dashboard/experiments) rather than an in-flow branch.

## Common mistakes

* **Trying to A/B test inside a flow.** In-flow A/B branching is not the right tool. Use a placement [experiment](/dashboard/experiments).
* **Leaving a screen with no way forward.** Every screen except the last needs a forward action (**Go to Next Screen** or **Navigate to Screen**), and the flow needs a **Close Flow** somewhere to end.
* **Building with unsupported nodes.** `api`, `event`, and `subflow` are dropped by the SDK. Do not rely on them.
* **Expecting a conditional navigate target.** A navigate action points at one fixed screen. Use dynamic values for conditional content, or experiments for variant flows.

## Related pages

* [Building multi-step flows](/editor/multi-step-flows)
* [Dynamic values](/editor/dynamic-values)
* [Interactions and actions](/editor/interactions-and-actions)
* [Experiments (dashboard)](/dashboard/experiments)
* [Flow schema reference](/reference/flow-schema)