← Back to blog Guides

How Conditional Logic in Forms Actually Works

Every form builder claims to have conditional logic. Almost none of them mean the same thing by it. Before you pick a tool on the strength of that bullet point, it is worth knowing what the four different things behind it are.

The four things people call “conditional logic”

Page jumps. The form is a sequence of pages, and at the end of a page you can send someone to a different page based on one answer. This is what Google Forms does with section jumps. It works, but the unit of movement is coarse: one decision per page, evaluated at the boundary.

Show/hide fields. A question appears or disappears based on a previous answer. Useful for small stuff (“if other, show a text box”) and awkward for anything structural, because a form with twenty conditional fields becomes impossible to reason about.

Per-answer branching. Each individual answer choice carries its own destination. A five-option question can lead to five different sections. This is the version that lets one form behave like several, and it is what Questionful does.

Calculated logic. Conditions built from expressions: scores, arithmetic on previous answers, combinations of several fields. Powerful, and the fastest route to a form nobody but its author can maintain. Questionful does not have this, deliberately.

Knowing which one a tool means saves you the disappointment of discovering it after you have rebuilt your form in it.

What per-answer branching gets you

A demo request form has one obvious problem: the questions worth asking a fifty-person company are not the questions worth asking a solo freelancer, and asking both sets to both audiences loses you the freelancer and annoys the enterprise.

With per-answer branching:

  • “How big is your team?”: a five-option choice question
  • “Just me” routes to a two-question section pointing at the free plan
  • “2–10” routes to a short self-serve section
  • “11–50” and “51+” route to the qualification section with a scheduling link

One URL. Four experiences. Nobody sees a question that does not apply to them, and the completion rate reflects it.

That is the pattern behind our lead qualification form, and the same shape works for event registration by ticket type and job applications across several roles.

The constraint everyone hits: only choice questions can route

This is the thing to internalise before you design the flow. In Questionful, branching is available on three question types:

  • Multiple choice
  • Checkboxes
  • Dropdown

That is because branching attaches a destination to an option, and only these types have a fixed list of options to attach one to.

Which means a linear scale cannot branch. Neither can a range slider, a date, or a text box. This surprises people building satisfaction surveys, because “branch on the rating” is the obvious thing to want.

The workaround is a one-line pattern, and it is honestly better survey design anyway:

Q1. How would you rate your experience? (linear scale, 1–5) Q2. Overall, would you say that was… (multiple choice: Great / Fine / Not good) ← branch on this

You get the number for your trend line and the band for your routing. Two taps instead of one, and the follow-up question is finally the right one.

Designing a branching form without dead ends

Branching introduces exactly one class of bug: a path that goes somewhere it should not, or nowhere at all. Four habits prevent nearly all of it.

Draw it before you build it. Three boxes and some arrows on paper. If you cannot draw the flow, you cannot debug the form.

Give every branch an exit. Each path needs to reach a genuine end. The classic failure is a “no thanks” option that routes to a section that then continues into questions meant for the yes path.

Keep the branching question early. Branch on the second question, not the eighth. A respondent who answers seven irrelevant questions before the form decides who they are has already lost patience with it.

Walk every path on the live form. Not the editor preview, the actual published link, on a phone. Ten minutes of clicking finds the thing an hour of staring at the editor does not.

When not to branch

Branching costs you comparability. Two respondents who took different paths did not answer the same questions, so you cannot put their answers side by side.

For a satisfaction survey where the entire point is a comparable trend line, keep the core questions on the main path and branch only the follow-up. For an assessment, branching means two candidates sat different exams, occasionally what you want, usually not.

And if a form has fewer than five questions, skip branching entirely. The complexity is not worth the two questions you would have saved someone.

What Questionful does not do

Worth stating plainly, so you can decide before you build:

  • No show/hide on individual questions. Branching moves between sections. In practice a one-question section covers the same ground.
  • No calculated conditions. No expressions, no arithmetic across answers, no compound rules.
  • No answer piping. You cannot inject a previous answer into a later question’s text.
  • No hidden fields or UTM capture. Nothing is populated from the URL.
  • No quotas. A branch cannot close itself once it has filled up.

What you get in exchange is a logic model you can hold in your head, and a form your colleague can still edit next year. The full detail is on the conditional logic feature page.

The short version

  • “Conditional logic” means four different things; check which one you are buying.
  • Per-answer branching lets one form behave like several.
  • Only multiple choice, checkboxes, and dropdown can route.
  • To branch on a rating, add a band question next to the scale.
  • Draw the flow, branch early, give every path an exit, and test on the live link.