Branching

Branching jumps respondents to a specific question (or skips ahead) based on what they've answered so far.

Rules live under settings.survey.branching as an ordered list:

json

[
  {
    "from": "q1",
    "when": [{ "field": "role", "op": "equals", "value": "engineer" }],
    "jump_to": "q5"
  }
]

The first matching rule from the current screen wins. Operators are the same set used by visibility rules: equals, not_equals, contains, not_contains, gt, lt, is_empty, is_not_empty.

If the jump_to target can't be resolved we fall through to the next sequential question. We never trap a respondent on a dead-end screen.

Rule order

Branching rules are evaluated in order for the current screen. Put the most specific routes first, then broader fallback routes. If no rule matches, the respondent continues to the next sequential question.

Use the from key to keep a rule scoped to one screen. Without it, a broad condition can match later in the survey and send respondents somewhere unexpected.

Good branching patterns

Role-based paths:

json

{
  "from": "role",
  "when": [{ "field": "role", "op": "equals", "value": "engineer" }],
  "jump_to": "developer-tools"
}

Skip irrelevant follow-ups:

json

{
  "from": "uses_product",
  "when": [{ "field": "uses_product", "op": "equals", "value": "no" }],
  "jump_to": "final-feedback"
}

Escalate high scores:

json

{
  "from": "urgency",
  "when": [{ "field": "urgency", "op": "gt", "value": 8 }],
  "jump_to": "contact-details"
}

Validation checklist

Before publishing, preview each branch path with realistic answers. Confirm every jump_to target exists, every branch eventually reaches a thank-you screen, and skipped questions are not required later by scoring or outcome logic.