Troubleshoot a flow that takes the wrong path
If visitors reach the wrong branch or get stuck in your flow, use the debugger to find the decision that sent them there and fix its settings.
The debugger can show you where a visitor's path first differs from the one you planned. Compare their actual data with the rule at that step, then change only the setting that's wrong.
Before changing the flow, record the page, visitor state, and where you expected them to go. Check whether you're testing the draft or published setup.
I can't tell where the flow went wrong
Open the debugger, choose Flows, and select the relevant entry under Running on this page or Not running here. Compare the first unexpected decision in the path with that node's settings.
The panel shows Status, Time in flow, Started, and Shown in, along with the current path and a summary of why the flow is or isn't running. A flow under Not running here may be waiting for targeting, a trigger, or a dismissal to clear rather than taking the wrong branch.
Choose Open flow to open its dashboard settings. The locate control appears when the current step has a visible widget element.
For testing, Clear dismissed clears a dismissal, and Restart flows for this session restarts the flows in your debug session. Neither changes published flow settings. See returning-visitor test controls for what each reset clears.
If an A/B test applies, you can force a variant for this session. Return to Automatic assignment before checking the visitor's normal route. Other A/B tests lists session-only assignments for offers and questions not reached on this page.
A forced widget preview can show content that normal targeting would exclude. Recheck an ordinary page visit when you're done.
A Condition takes No instead of Yes
Check the rule's operator, value, group combination, and timing against the visitor's data. Change only the incorrect rule, then try both a matching and nonmatching visitor. See the Condition reference.
The visitor may not match the saved rule, or the rule may read a different source than you intended. For example:
- A domain isn't a path.
- A query value on the current page isn't remembered query history.
- An unidentified browser doesn't automatically have the connected contact's fields.
- An empty OR group matches no visitors.
A Router takes Default
Inspect the visitor's answer and identity, then check that the Router uses the intended group. Add a useful default path for visitors whose answers you don't know.
A Router takes its default path when there's no matching stored answer or segment. Returning visitors aren't necessarily known. See routing by existing answers.
High Score picks the wrong winner
Check the values immediately before High Score:
- Inspect every candidate's value.
- Check Lowest score wins, or Lowest value wins in Variables mode.
- Check the visual row order, which breaks ties.
- Check whether a stored variable shares a score's name.
- In Variables mode, check that values are numbers or numeric strings that haven't expired.
Score names, values, ordering, and comparison mode all affect the winner. Missing candidates aren't initialized zero scores. If no candidate has a value, or a participating value is nonnumeric, the first configured route can win.
Repeat your checks for ties and unanswered questions. See the High Score reference.
A score adjustment is missing
Inspect the path before High Score and put each required score adjustment in a separate Set Data node. Only the first Update Score action in a single Set Data node is retained. Compare the totals again after separating the actions.
An adjustment can also be missing because the score action or its question wasn't reached. A variable with the same name as a score can override its total when High Score picks a winner.
Random Split keeps choosing the same group
Use separate fresh visitor states to check the other groups. Refreshing the same browser won't choose again because Random Split remembers that visitor's assignment.
Changing the number of groups can move existing visitors between groups.
Nothing happens after a form or message
Configure the form's Post-Submit Actions For This Form. If you want immediate navigation, replace a terminal thank-you message with the redirect.
A terminal step ends the ordinary path. An action placed beneath an unreachable step in the parent flow won't run. See form completion and redirects.
The path is right, but my contact data is wrong
Inspect the destination contact, field mapping, permissions, or webhook delivery details. Check the receiving endpoint too. A fetch failure can leave the webhook log empty. Follow integration verification.
Reaching the action and completing an external update are separate events. The flow may reach the right step even when the destination rejects the update.
The visitor's data matches, but the flow still takes the wrong path
Send support the page, flow, node, browser state, configuration version, and observed path. Name the first node where the path differs from what you expected.
Include the expected branch, actual branch, value being compared, and whether the visitor is fresh, remembered, or overridden in the debugger. These details help explain the decision:
| If the problem is with… | Include these details |
|---|---|
| Condition | The group operator, data source, and comparison value, not just its Note |
| High Score | Every candidate's value, the comparison mode, and the row order |
| Form completion | Whether the node is in the parent path or Post-Submit Actions For This Form |
Leave out credentials and private visitor data. Once you've made a fix, try the ordinary visitor path again without forcing the branch.