Conditional logic forms: branching that doesn't fall apart
Conditional logic means a form changes what it asks based on what someone has already answered — hiding irrelevant questions, revealing follow-ups, or jumping past whole sections. It is the single biggest lever on completion rate, because the fastest way to shorten a form is to stop showing people questions that don't apply to them. Here is how it works, where the common tools differ, and how to design branches that survive contact with real respondents.
Three different things called conditional logic
The term covers three mechanisms that behave differently, and confusing them is why people buy a tool that can't do the thing they meant.
Show and hide logic operates on individual questions. A question is invisible until a condition is met, then it appears in place. This is the finest-grained kind and the one people usually mean: answer "yes" to "do you have dietary requirements?" and a text field appears underneath.
Jump or skip logic operates on the order of the form. Based on an answer, the respondent is sent forward to a different question or section, skipping everything in between. Google Forms implements only this variety, and only from multiple-choice and dropdown questions, at section granularity — which means every branch you want has to be modelled as a separate section.
Calculation and tagging logic doesn't change what's displayed at all; it changes what's recorded. Points accumulate against answers, tags get applied when conditions match, and the result is stored on the response. This is what turns a form into a triage or scoring mechanism rather than a questionnaire.
Which mechanism you need
Match the job to the mechanism before you pick a tool, because not every tool has all three.
Show / hide, per question
Best when the form is mostly the same for everyone with a handful of conditional follow-ups. Cheap to build, easy to reason about, and it keeps the form as one linear thing rather than a tree. Use this by default. On Zunoform it is free, and any question can be conditioned on any earlier answer.
Jump / skip
Best when respondents fall into genuinely different populations that need different question sets — a form serving both new and existing customers, say. The cost is that the form becomes a graph, and graphs need testing along every path. Reach for this when show/hide would mean conditioning thirty questions individually.
Score and tag
Best when what you want from the branching is classification rather than a shorter form. Assign points per option, apply tags when conditions match, and let the response sort itself. Here that evaluation happens server-side at submission, so the recorded score reflects your live form definition and isn't something a respondent can rewrite in their browser.
Building a branch, concretely
The mechanics take about a minute once you've decided what the branch is for.
Ask the qualifying question first
Logic can only reference answers that come earlier in the form, so the question that drives the branch has to precede everything it controls. Multiple choice, dropdown, and yes/no questions make the cleanest conditions because their answers are a fixed set rather than free text.
Attach the condition to the follow-up question
On the question you want to make conditional, set the rule: show this when the earlier question equals, contains, is greater than, or is not a given value. The question then stays hidden until the condition matches, and a hidden question is not asked and not required.
Walk every path before you publish
Preview the form once per branch, answering as each type of respondent. This is where you catch the two classic errors: a required question stranded on a path nobody reaches, and a follow-up whose condition references a question you later reordered above it.
Three worked examples
Support intake. Question one asks what the issue relates to: billing, a bug, or account access. Choosing billing reveals an invoice number field and a dropdown of charge types. Choosing a bug reveals a browser field and a file upload for a screenshot. Choosing account access reveals nothing extra but tags the response as urgent. Every respondent sees three or four fields; the form as a whole contains eleven. Without logic you would either ask everyone all eleven or lose the detail entirely.
Event registration. "Will you attend the workshop day?" — yes reveals a workshop track picker and, if the workshop is paid, a payment question whose amount is driven by the track chosen. "Do you have dietary requirements?" — yes reveals a text field, no keeps the form short. "Are you bringing a guest?" — yes reveals a second name and email pair. The base form is four questions. A respondent who says yes to everything answers nine, and only the ones that apply to them.
Quoting. A moving or service quote form asks property size, then floors, then access constraints — each question narrowing what the next one needs to ask. Options carry point values, so the total accumulates as the respondent answers, and because the score is interpolatable anywhere in the form, the estimate can be shown back to them on the ending page. If the quote becomes a deposit, the payment amount can be driven per-option by an earlier answer, and the total is recomputed server-side at checkout and re-verified again at submission — so the price is decided by your form definition, not by whatever the browser sent.
Screening. The inverse use of logic: instead of revealing questions, use the qualifying answer to end the form early. Someone who answers that they're outside your service area doesn't need to fill in eight more fields, and you don't need the record. A short honest disqualification reads better than a wasted five minutes.
Rules for branches that don't break
Branched forms fail in specific, repeatable ways. These are the ones worth designing against.
- Keep the branch depth shallow — conditions that depend on conditions that depend on conditions are where bugs live
- Never mark a question required if it can be hidden on the path the respondent takes
- Reordering questions can orphan a condition; re-check logic after any reshuffle
- Free-text answers make brittle conditions — branch off choice questions wherever you can
- Give every path an ending, including the disqualifying ones
- Test on a phone, where a revealed question can appear below the fold and go unnoticed
- Write down what each branch is for; six months later the condition will not explain itself
- Prefer one form with logic over three near-identical forms — three forms means three places to fix a typo
Conditional logic across the main tools
What each builder supports, and on which plan. Verified August 2026.
| Capability | Elsewhere | Zunoform |
|---|---|---|
| Show or hide a single question | Not possible in Google Forms on any plan — its branching is section-level only | Free |
| Jump past a section | Google Forms supports this from multiple-choice and dropdown questions | Free |
| Condition on a numeric comparison | Varies by tool and tier | Free — equals, contains, greater than and more |
| Accumulate a score across answers | Often browser-side, and editable by anyone who opens devtools | Free, evaluated server-side at ingest |
| Tag a response automatically | Usually a manual pass over the export, or a Zap | Free, with a fallback tag when nothing matches |
| Drive a payment amount from an earlier answer | Typeform puts payments on a $91/mo tier; Google Forms has no native payments | Pro, recomputed server-side at checkout and re-verified at submission |
Templates that already use logic
Open one and look at how the conditions are wired before building your own.
Priority triage with file attachment — crisp and utilitarian.
Contact details, visit reason, and insurance — done before you arrive.
Project scope, quantities, timeline, and an optional budget branch.
Contact details, role, experience, skills, and a resume upload.
Questions people ask
Does Google Forms have conditional logic?
Partly. Google Forms supports section-level jumps — a multiple-choice or dropdown answer can send someone to a different section — but it cannot show or hide an individual question, on any plan. If you want a single follow-up field to appear under a specific answer, you have to model it as a whole separate section, or use a different tool.
What's the difference between skip logic and branching?
In practice they describe the same family of behaviour: skip logic usually means jumping forward past questions that don't apply, while branching means sending respondents down genuinely different paths. Both change the route through the form. Show/hide logic is different again — it changes which questions are visible without changing the order.
Does conditional logic actually improve completion rates?
It improves them by removing questions, which is the mechanism that reliably works. A respondent who sees four relevant questions finishes more often than one who sees eleven, four of which don't apply to them. Logic that adds questions rather than removing them has the opposite effect, so branch to shorten rather than to gather more.
Is conditional logic free on Zunoform?
Yes. Per-question show and hide logic, numeric and text conditions, scoring, and tag rules are all on the free plan, alongside 500 responses a month and unlimited forms. The only question types that need a paid plan to publish are NPS, e-signature, and payment.
Can hidden questions still be required?
A question that is hidden isn't asked, so it can't block submission. The failure to watch for is the reverse: a required question sitting on a path that a given respondent never reaches, which is fine, versus a required question that becomes visible unexpectedly late in a long form. Walk each path in preview and the problem surfaces immediately.
Keep reading
Better forms.
Better data.
Build your first form in under 60 seconds. Free forever for personal use, no credit card required.