Most forms ask the wrong people the wrong questions.
A lead capture form asks “How many employees?” to a solo founder.
An event registration form asks about dietary restrictions when the attendee is only joining online.
A customer support form asks which plan you’re on — and then asks again, two questions later, in a slightly different way.
The fix is simple in concept: show questions only to the people they apply to, and hide them from everyone else.
That’s what show/hide logic (also called conditional logic, branching logic, or skip logic) does.
Done well, it cuts form length in half without losing any data, and it consistently lifts completion rates by 20–40% in our own testing and in published research on form design.
This guide walks through exactly how to build show/hide logic into an online form, the patterns that work best, and the cases where conditional logic actively hurts.
What show/hide logic actually means
In a standard form, every respondent sees every question.
In a form with show/hide logic, the questions a respondent sees depend on how they answered earlier questions.
A simple example: if someone selects “I’m a solo founder” on question 1, the form skips past questions about team size and company structure and jumps straight to product interest.
If they select “I work at a company,” the form shows those team questions and skips the solo-specific ones.
The underlying mechanic is an if/then rule attached to a field:
- If question 1 answer = “Solo founder”
- Then skip questions 2, 3, 4 (and show questions 5, 6)
You can chain these rules.
A first answer opens up a branch, a second answer within that branch opens up a sub-branch, and so on.
But chains get brittle fast — more on that at the end.
Step-by-step: building a show/hide form
The exact interface will vary depending on your form builder, but the underlying workflow is the same everywhere. Here’s how it works in Rowform:
1. Map the logic before you build
Before opening any form builder, sketch the flow on paper or in a simple diagram tool. For every question, ask: who should see this, and who shouldn’t? Group your respondents into two or three personas and trace what a clean path looks like for each one.
This step saves hours. Most broken conditional forms break because the builder tried to design and plan simultaneously.
2. Build the form linearly first
Create every question you might ever show — in the order a maximally curious respondent would see them. Don’t add any logic yet. Just get all the fields into the form.
In Rowform, you can do this quickly by describing the form to the AI builder (“a B2B lead qualification form with role, company size, current tools, budget, and timeline”) and editing the generated output. Or build it block by block in the Notion-style editor.
3. Add the branching question
The branching question is the one whose answer changes the rest of the form. It’s almost always a single-choice or multiple-choice field, because show/hide logic needs discrete answers to trigger against.
For a lead form, the branching question is usually role or company size. For a customer feedback form, it’s satisfaction rating. For event registration, it’s attendance type (in-person vs. online).
4. Attach show/hide rules to the dependent questions
Select each question that should only appear for certain respondents. In the field settings, add a rule:
Show this question if [branching question] is [specific answer(s)]
Or, equivalently:
Hide this question if [branching question] is [specific answer(s)]
The “show if” framing is usually cleaner because it’s additive — you’re explicitly listing who should see the question. “Hide if” rules accumulate invisibly and get tangled.
5. Test every branch
This is the step most people skip. Walk through your form as each persona. Does the solo founder see only the four questions they should? Does the enterprise prospect see the full compliance section? Does anyone hit a dead end or a contradictory question?
In Rowform’s preview mode, you can step through the form as a respondent without submitting data, which makes this quick. Regardless of your builder, don’t publish until you’ve manually tested each branch.
Common patterns that work
A handful of conditional logic patterns show up again and again because they solve real problems. If you’re not sure where to start, one of these probably fits your form.
Pattern 1: Qualifying gate
The first question determines whether the respondent is a good fit at all. Unqualified respondents get a short polite closer; qualified ones proceed to the full form.
Use case: Lead capture, B2B sales inquiries, partnership applications. Example trigger: “What’s your budget range?” → if “Less than $X” → show a thank-you screen with a link to self-serve docs. Otherwise → continue to full qualification.
Pattern 2: Segmented path
The respondent selects a category, and the form shows questions specific to that category.
Use case: Support triage, feedback forms, multi-product companies. Example trigger: “What are you contacting us about?” → Billing shows account questions, Technical shows product/error questions, Feedback shows NPS + open text.
Pattern 3: Progressive disclosure
Optional or advanced questions only appear if the respondent opts in or indicates they want to go deeper.
Use case: Onboarding forms, account setup, detailed surveys. Example trigger: “Want to set up advanced integrations now?” → Yes shows Slack, Zapier, and webhook fields. No skips them entirely (and the respondent can come back later).
Pattern 4: Rating-driven follow-up
A satisfaction or rating question branches into different follow-ups depending on the score.
Use case: NPS surveys, post-purchase feedback, support CSAT. Example trigger: “How would you rate your experience? (1–5)” → 1–2 shows “What went wrong?” (open text, high-priority alert), 3 shows “What would make this better?”, 4–5 shows “What did you love most?” and a request for a review.
Pattern 5: Relevance filter
Questions that only apply to a subset of respondents are hidden from everyone else.
Use case: Event registration, job applications, healthcare intake. Example trigger: “Will you attend in person or online?” → In person shows dietary and accessibility fields; Online shows time zone and platform preferences.
When NOT to use conditional logic
Conditional logic is a tool, not a virtue. There are forms where adding it makes things worse.
Skip it when the form is already short. If you have five questions total and all five apply to everyone, don’t invent branches. The cognitive cost of a “will this question appear next?” guessing game is higher than the cost of answering one extra question.
Skip it when the branches aren’t meaningfully different. If Branch A and Branch B end up asking 80% of the same questions, just ask those questions to everyone and skip the branching.
Skip it when you’re using it to hide long forms. Some teams add conditional logic to make a 40-question form feel shorter. It doesn’t — respondents still spend the same time — and it often makes the form feel inconsistent and confusing across sessions. If your form is too long, cut questions. Don’t hide them.
Be careful with deep chains. Logic that depends on logic that depends on logic becomes impossible to test and maintain. If you find yourself building a tree four levels deep, it’s usually a sign the form is trying to do too much and should be split into two forms or a multi-step workflow.
For a broader look at how conditional logic works across different form types and use cases, see our complete guide to conditional logic in forms.
A quick note on mobile
Show/hide logic is especially valuable on mobile, where every extra question on a small screen is a visible commitment that increases drop-off. A form that looks reasonable on desktop often looks overwhelming on a phone. Conditional logic, combined with a one-question-per-screen layout, is the combination that tends to convert best on mobile — respondents never see what doesn’t apply to them, and each question feels small and answerable.
This is one of the reasons Rowform defaults to one question per screen with conditional logic built in from the start, rather than bolted on later. The mobile experience is the default experience, not an afterthought.
Start simple, then layer
The biggest mistake people make with conditional logic is building the full decision tree on day one. Start with a single branch: one qualifying question that splits respondents into two paths. Ship it. Watch how respondents actually move through the form. Then add a second branch based on what you learn.
Forms that evolve in response to real data outperform forms that were designed to handle every edge case from the start. Conditional logic rewards iteration more than it rewards planning.