Skip Logic and Branching in Questionnaire Design

Skip logic — also called branching logic, contingency questions, or display logic — is the set of rules that route a respondent past questions that do not apply to them, based on answers already given earlier in the instrument. Handled well, it shortens the instrument, keeps every item relevant to the person answering it, and reduces the “not applicable” clutter that makes a completed dataset harder to analyze. Handled carelessly, it produces two failure modes that are easy to ship and hard to catch after the fact: orphaned items (a question a respondent should have seen, but a routing condition silently skipped) and a denominator that no longer means what the report claims it means (a percentage calculated over “all respondents” when the true eligible base was a filtered subset).

This guide covers the design and documentation side of skip logic — the decisions a researcher makes before a single line of platform-specific syntax gets written. For how one specific tool implements branching, see REDCap Branching Logic: Syntax, Testing, and Common Errors, which covers REDCap’s field-reference syntax and its specific silent-failure modes in depth. This page is the general methodology those platform mechanics sit on top of.

What Counts as Skip Logic

Three related but distinct mechanisms get grouped under “skip logic” in practice:

• Filter questions (gate questions). A single question determines whether a respondent proceeds into a whole block — e.g., “Are you currently employed?” gates an entire employment-detail section.
• Branching within a block. A respondent’s answer to one item routes them to a different follow-up item within the same section, rather than skipping the section entirely — e.g., a respondent who selects “Other” on a multi-select item is routed to a free-text follow-up that respondents who did not select “Other” never see.
• Display logic. A question or answer option is shown or hidden based on a prior response, without necessarily changing the respondent’s position in the instrument’s overall flow — commonly used to pipe an earlier free-text or single-choice answer into the wording of a later question.

The distinction matters for documentation more than for respondent experience: a codebook that only records “skipped if Q4 = No” for a filter question, but doesn’t record the finer-grained branching inside the block that filter gates, will not let a second analyst reconstruct who actually saw each item.

Designing Branch Conditions

Three design decisions determine whether skip logic behaves predictably:

1. Base every condition on a single, already-validated answer

A branch condition that depends on more than one prior answer (e.g., “show Q12 only if Q4 = Yes AND Q7 > 2”) is harder to test exhaustively and harder for a second person to audit later. Where the underlying logic genuinely requires more than one input, document the full truth table in the questionnaire’s routing map rather than relying on the platform’s own logic-builder UI as the only record of what the rule does.

2. Route on the answer, not on the question’s position

Skip logic defined by absolute question number (“skip to Q15”) breaks the moment an earlier question is inserted, removed, or reordered during piloting — a routing rule tied to a stable field/variable identifier survives instrument revisions; one tied to a question’s on-screen position does not. This is the single most common source of the “REDCap gives no indication anything is wrong” class of failure documented in the platform-specific guide above: the branching condition still evaluates, it just now references the wrong field.

3. Decide explicitly what happens to “don’t know” and refused answers

A branch condition written as “if Q4 = Yes, show Q5” leaves undefined behavior for a respondent who selected “Don’t know” or skipped Q4 entirely on a paper or non-forced-response instrument. Decide, and document, whether an ambiguous prior answer routes toward or away from the dependent block — the decision itself is a substantive methodological choice, not a technical default to leave to whichever branch the platform falls into by omission.

Avoiding Orphaned Items

An orphaned item is a question that a routing error causes some respondents to skip when the questionnaire design intended them to see it — or, less often, causes them to see when they should have been routed past it. Because skip logic fails silently in most survey platforms (a hidden field does not throw an error; it is simply absent from that respondent’s record, indistinguishable at analysis time from genuine non-response), orphaning is typically caught only through deliberate testing, not through respondent complaints or fielding-stage monitoring. Standard mitigations, consistent with the survey-methodology literature on pretesting:

• Path-based pilot testing. Test every distinct routing path through the instrument, not just the default “answer everything straightforwardly” path — each branch point at minimum doubles the number of paths that need a dedicated test pass.
• A routing map independent of the platform’s logic builder. A separate document (flowchart or table: field ID, condition, destination field ID) that a second person can audit against the live instrument, rather than trusting that the platform’s own visual logic editor is self-documenting.
• Post-fielding orphan checks. After data collection, cross-tabulate each gated item’s response count against its gate question’s expected qualifying count. A gap between the two is either a routing bug or a genuine drop-off, and the two need to be distinguished before analysis, not assumed away.

How Skip Logic Changes Your Denominator

The most consequential effect of skip logic is on which base a later statistic is actually calculated over — and it is the effect most likely to go unreported. If a filter question routes only 40% of respondents into a follow-up block, then any percentage reported for an item in that block has a true denominator of that 40% subgroup, not the full respondent count. Reporting it against the full sample size without noting the filter silently changes what the statistic means: “62% of respondents rated the service positively” reads very differently once a reader learns it was calculated over only the subset who were routed into the satisfaction block at all.

This is the same base-size discipline survey methodologists apply to response-rate reporting more broadly. AAPOR’s Standard Definitions (10th edition, 2023) exists specifically because response-rate calculations depend on exactly which cases go into the denominator and which are excluded or treated as ineligible — the RR1 through RR6 formulas differ from each other almost entirely on how the denominator is constructed, not on how the numerator is counted. The same discipline applies inside a single questionnaire: every table or chart built from a gated block should state its actual base (“n = 412, respondents who answered Yes to Q4”), not inherit the full-sample n by default. Two concrete conventions that prevent the ambiguity:

• Report a base size on every table, not just once at the top of the results section — a reader working through individual tables should never have to hunt for which filter applies to the one they’re looking at.
• In the codebook, record each gated variable’s valid base explicitly (e.g., “asked only of respondents who answered Q4 = Yes; n not applicable coded as system-missing, not as a valid response category”) — conflating “skipped by design” with “declined to answer” in the coded data makes it impossible to reconstruct the true denominator later from the dataset alone.

Documenting Skip Logic for a Codebook

A complete routing record for each conditional item includes, at minimum: the field ID of the gating question, the exact condition (including how ambiguous/missing prior answers are handled, per above), the field ID(s) routed to on each branch, and how the platform codes the resulting missingness (system-missing vs. a distinct “not applicable” category). Dillman, Smyth, and Christian’s Internet, Phone, Mail, and Mixed-Mode Surveys: The Tailored Design Method (4th ed., Wiley) treats branching as a core instrument-design decision made during questionnaire construction, not an afterthought applied during programming — the routing map should exist before the instrument is built in whatever platform will field it, so platform-specific syntax is implementing an already-decided design rather than improvising one.

Related CASRAI Resources

For question-type mechanics (including the multi-select and matrix items skip logic most often gates), see Survey Question Types. For the broader instrument-design process this fits into, see Questionnaire Design: Writing Survey Questions That Work. For wording pitfalls that compound with routing errors, see Leading Questions in Surveys. For sampling-frame and coverage implications when a filter question effectively excludes part of the intended population, see Sampling Frame: Coverage Error, Frame Construction, and What to Report. For REDCap-specific implementation, see REDCap Branching Logic. See also the Research Methods pillar for the full cluster.

Frequently Asked Questions

Is skip logic the same thing as branching logic?

Yes — they describe the same underlying mechanism (routing respondents based on prior answers). “Skip logic” and “display logic” are the terms most survey-methodology literature and general-purpose platforms use; “branching logic” is the term REDCap specifically uses for its own implementation. The concepts are interchangeable; the syntax that implements them is not.

Should skip logic ever route someone past a question they might actually be eligible for?

Only when the gate condition is genuinely unambiguous. Where eligibility is close to the boundary (e.g., a partial “Yes” or a “Don’t know”), the safer default is to route toward showing the dependent question rather than away from it — an unnecessary question costs a respondent a few seconds; an orphaned item costs the analyst a missing data point with no way to recover it after fielding closes.

How do I report results when a large share of the sample was routed past a question?

State the actual base explicitly on the table or chart itself (“n = X, asked only of respondents who indicated Y”), not just in a methods appendix. If the filtered subgroup is small enough that the resulting estimate is imprecise, say so rather than reporting a percentage without a confidence interval or a base-size caveat.