Branching

Branching lets you send users down different paths in a flow based on what they select on a screen. Instead of building separate flows for each audience segment, a single flow can adapt in real time using Branch nodes.

How branching works

A screen presents a component with selectable options (e.g., a radio group asking "What is your role?").
The user selects an option.
The flow reaches a Branch node. Its source can be the screen right before it or any earlier screen in the flow.
The Branch node looks up the user's answer on its source screen and routes them to the matching path.

Each option maps to an outgoing edge on the Branch node. If a user selects "Product Manager", they follow the edge labeled "Product Manager". If they select "Engineer", they follow a different edge.

Branchable components

Not every component supports branching. The following component types produce a response that a Branch node can evaluate:

Component	Response value
RadioGroup	The selected option's value.
NPS	The numeric score (0--10).
Rating	The numeric rating value.
Dropdown	The selected option's value.
Checkbox	The set of checked values.
Button	The button's action value.
Quiz	The selected option's value.
Chip	The selected chip's value (single select).
Segmented	The selected segment's value.

The Branch node's source screen has to contain a branchable component. By default the source is the screen right before the split; you can pick any earlier screen instead.

Setting up a Branch node

Open your flow in the flow builder.
Click the + Add Node button on the canvas and select Add Branch.
Connect the flow to the Branch node. The screen right before it is preselected as the source.
To branch on an answer given earlier, pick that screen in the source dropdown. Only screens the user passes before reaching the split are listed.
Choose the component, and the Branch node reads its options.
For each option, draw an edge from the Branch node to the screen you want the user to see next.

Branch edges are labeled with the option value they correspond to. These labels update automatically if you rename options in the component.

Branching on an answer from an earlier screen requires iOS SDK 1.3.0 or Android SDK 1.3.0. Older SDK versions take the split's default path for such splits. Older SDK versions also keep only the last input on a screen, so when the user leaves the answer screen by tapping a button, such as Continue, that tap replaces the answer and the split takes its default path. A Button split still routes on those versions, because the tapped button is the answer. Quiz, Chip and Segmented Control splits need Android SDK 1.3.0 even when they read the screen right before them, and older Android SDKs take the default path for them.

Example: role-based onboarding

Suppose your onboarding flow asks users to choose their role with a RadioGroup that has three options: Designer, Developer, and Product Manager.

Start → Welcome Screen → Role Selection Screen → Branch
                                                    ├── "Designer"        → Design Tips Screen → End
                                                    ├── "Developer"       → API Intro Screen   → End
                                                    └── "Product Manager" → Dashboard Tour      → End

Each role sees a tailored follow-up screen. The rest of the flow (welcome screen, final screen) remains shared.

Saving responses as user attributes

When a user responds to a branchable component, you can save that response as a user attribute for future targeting and personalization. This is handled through the response save feature:

The SDK captures the user's selection on the branchable component.
The response is saved to the user's profile as an attribute (e.g., role = "Designer").
Future flows can use this attribute in trigger conditions to target or exclude specific segments.

This creates a feedback loop -- responses from one flow inform the targeting of subsequent flows.

Saved response attributes overwrite any previous value for the same key. If a user completes the same flow twice and picks a different option, the attribute updates to the latest selection.

A Condition node can't read an answer saved earlier in the same flow. Condition nodes are decided when the flow is delivered, so they see the attribute's value from before the flow started. To route on an answer given earlier in the same flow, use a Branch node and pick that screen as its source.

Branching vs. condition nodes

Both Branch nodes and Condition nodes create diverging paths, but they serve different purposes:

	Branch node	Condition node
Input	User's response on the source screen (the previous screen or any earlier one).	User attributes and segments.
Timing	Evaluated after the user interacts.	Decided on Setgreet's servers when the flow is delivered.
Paths	One per option value (many).	Two: Yes or No.
Use case	Personalize the flow based on what the user answered.	Skip or show screens based on existing user data.

A Condition node is decided once, before the flow reaches the device, from the attributes and segments stored for the user at that moment. Identify the user before the flow is shown so those attributes are current (see User Identification). Condition nodes don't read event properties, even when an event opened the flow, so an Event condition left on an older Condition node is never met. If the Yes or No path isn't connected, users who take it leave the flow at that point.

You can combine both in the same flow. For example, use a Condition node early in the flow to check if the user is on a paid plan, and later use a Branch node to split based on a survey response.

Tips

Keep branches shallow -- deeply nested branches are harder to maintain. If you have more than two or three levels of branching, consider splitting into separate flows.
Preview each path -- use the preview feature to walk through every branch and verify the experience before publishing. Pick a different answer for each Branch node path. For Condition nodes, enter the attributes each path needs under User Attributes in the Mock User Data panel.

Branching

On this page