Conditional logic: showing only the questions that apply

The form has twenty eight questions. A given person needs to answer nine of them. The other nineteen exist because some other kind of applicant needs them, so everybody scrolls past questions about equipment they do not own and dates that do not apply to them, guessing whether leaving something blank will get the submission rejected.

Conditional logic is the mechanism for showing each person only the questions that apply to them. It is straightforward in principle and it goes wrong in predictable ways: branches that never end, required questions hidden behind a condition so that submission fails with no visible reason, and exports where a blank cell could mean either a refusal to answer or a question that was never asked. What follows is the mechanism, the two ways it is built, and how to design a branch that somebody else can maintain.

What the term covers

Several features travel under the same name, and knowing which one a tool offers avoids designing around something that is not there.

Show and hide on a question. The commonest form. A question appears only when an earlier answer matches a condition. Everything stays on one page and the page changes as answers are given.

Jumping to a section. Page based rather than question based. An answer sends the respondent to a particular section and skips the ones in between. This is what most tools mean by branching, and it is often the only kind available.

Carrying an answer forward into later text. Sometimes called piping. A later question repeats something already answered, so the wording reads as though it were written for this person.

Conditional requirement. A question that is optional in general but mandatory once a particular answer has been given. This is the most useful of the group and the one that causes the most trouble, for reasons covered below.

Calculation and scoring. Adding up answers, then branching on the total rather than on any single answer.

Routing after submission. The condition acts on what happens next rather than on what is shown: who the submission goes to, which notification fires, what state it starts in. Most tools stop at display logic and leave this part to be done by hand, which is where the time actually goes.

The first two are what people mean by conditional logic. The last one is what decides whether the branch saves any work after the form is submitted.

Three things it buys

Fewer questions per person. A respondent who can see that a form is long slows down before starting it, and one who hits an irrelevant question in the middle loses confidence that the form was made for them. Showing nine questions rather than twenty eight is a different experience even though the total number of questions is unchanged.

Data that means something. Without logic, an inapplicable question has to be answered somehow, so the field fills up with "n/a", "none", a dash, or a guess. Every one of those has to be cleaned out later, and a guess cannot be distinguished from a real answer. A question that was never shown produces an empty field, which is unambiguous.

Contradictions become impossible. A form that asks for a driving licence number and also asks whether the person drives can collect a licence number from somebody who has just said they do not. Making the second question depend on the first removes the contradiction at the point of entry, which is the only place it can be removed cheaply.

There is a fourth benefit that matters for anybody handling the submissions rather than making the form. When irrelevant questions are not asked, the answers that do arrive are all meaningful, so reading a submission takes less time. That saving is per submission and it compounds.

Two implementations, and why the difference shows

The row that causes real bugs is the third. In a show and hide implementation, a question answered and then hidden by a later change of mind has already stored a value in some tools. The submission then contains an answer to a question the respondent cannot see, and whoever reads it acts on information the person believes they retracted. Where a tool documents clearing hidden values, that is worth knowing; where it does not, the safe design puts the routing question before anything that depends on it, so nothing is filled in before the branch is decided.

The fifth row is the other frequent failure. Somebody who goes back and changes the answer that drove the branch may leave answers behind in a section that is no longer part of their path. Those answers still arrive.

Designing a branch backwards

The instinct is to start from the questions and add conditions to them. That produces a web of conditions nobody can follow six months later. Starting from the outcomes produces something maintainable.

List the distinct ways a submission gets handled. Not the kinds of person, the kinds of handling: this goes to the programmes team and needs two documents, this one is a straightforward booking and needs a date, this one is a complaint and needs a reference. Three or four outcomes is normal. If the list has nine, the form is doing the work of three forms.

Then find the single question that separates them. There is almost always one, and it is usually a choice from a short list. That question goes first, before anything else, because everything after it depends on it.

Then, for each outcome, write only the questions that outcome needs. Questions common to all outcomes go before the router question, not repeated inside each branch.

The result is a form with one condition per question and a shape that can be drawn on paper. The alternative, conditions that combine two or three earlier answers, is occasionally necessary and always the part that breaks when somebody edits an option label.

One rule about the router question: it has to be something the respondent can answer with certainty at the start. Asking somebody to classify their own enquiry into internal categories fails, because they pick wrongly and then answer a whole branch of questions meant for somebody else. Asking what they are trying to do works, because they know.

The rules that keep it maintainable

Every path has to reach the end. A branch that sends somebody to a section with no way onward is a dead end, and the respondent's only options are abandoning the form or going back and lying. Walking each path once, to the confirmation screen, is the only way to find these.

Test conditional requirements from the respondent's side. A question that becomes mandatory when hidden is the classic invisible failure: the submit button does nothing, no error is visible because the error is attached to a field that is not on screen, and the person gives up. Every conditionally required question needs one test where the condition is false.

Treat an "other" option as a branch. Free text after "other" is where the answers that break routing arrive, because somebody will write something belonging in one of the listed categories. If "other" is being chosen often, the list of options is wrong.

Do not rename an option without checking what depends on it. Conditions frequently reference the label rather than a stable identifier, so editing "Yes, currently employed" to "Employed" can silently disconnect a branch. Renaming is the most common cause of a form that worked last month and does not now.

Keep a note of the intended paths. A short list of the outcomes and the answer that leads to each, kept with the form, is what makes it possible for somebody else to change it. Without that, every edit is archaeology.

What the respondent experiences

Two details decide whether logic feels helpful or unsettling.

A question that appears where the person is already looking is fine. A page that reflows above the current position while somebody is reading is not, because their place moves under them. Adding revealed questions below the current one, rather than inserting them into the middle of a filled section, avoids it.

The progress indicator becomes a promise that logic can break. A bar showing position by page number tells somebody on a two page path that they are halfway through when they are nearly finished, or the reverse. Where paths differ substantially in length, an honest indicator counts the steps on this path, and where that is not possible, no indicator is better than a misleading one.

For anybody using a screen reader, a question that appears without announcement is simply missing. This is one reason page based branching is often the safer choice: moving to a new page is an event every assistive technology already handles, while a field quietly added to the middle of a page may not be announced at all.

What it does to the data

Conditional logic changes the shape of the export, and the change surprises people the first time.

Every question that exists on any path becomes a column. A respondent who saw nine questions produces a row that is mostly empty. That is correct, and it is also awkward for anybody expecting a dense table, so a wide export with many blanks is a sign the logic is working rather than a fault.

The distinction that has to be preserved is between not asked and not answered. Both look like an empty cell. Anybody analysing the responses needs to know which is which, and the reliable way to get it is to record the path itself as a value, either by asking the router question in a form that survives into the export or by tagging the submission with the path it took. With the path recorded, counting how many people took each route takes a filter rather than a reconstruction.

This is also the point where display logic stops being enough. The branch already knows something useful about the submission: which team it belongs to, what it needs next, whether it is a complaint or a booking. If that knowledge is not carried into the handling, somebody reads each submission and sorts it by hand, which is the same work the form just did.

Where logic ends and handling begins

A form that branches well and then drops everything into one undifferentiated list has solved the respondent's problem and left the reader's problem alone. The useful continuation is that the answer which chose the branch also chooses what happens next: which person owns the submission, what state it starts in, and which saved reply is the right one to send.

That is worth checking before choosing a tool, because it is the part most form builders leave out. The situations where it matters are the ones where several kinds of request arrive through one form and are handled by different people. The features that carry a branch through to the reply are an owner on each response, a state it moves through, and saved wording that can differ by kind of request.

What to change first

Count the questions on the busiest form that a typical respondent has to skip, then find the single answer that would have told the form which ones to show. That question belongs first, and moving it is usually an afternoon's work. After that, check what happens to the answer once it arrives, because a branch that sorts the questions and leaves the handling unsorted has only moved the work: Halict gives every response its own owner and stage once it arrives before adding a second condition.

Q1. What is the difference between conditional logic and skip logic?

The terms are used interchangeably by most tools. Where a distinction is drawn, skip logic usually means jumping past a whole section, while conditional logic means showing or hiding an individual question on the page in front of the respondent. It is worth checking which one a given tool provides, because they behave differently when somebody goes back and changes an answer.

Q2. Are answers to hidden questions still submitted?

It depends on the tool, and this is worth testing rather than assuming. In a show and hide implementation, a question answered before it was hidden may still carry its value into the submission. Placing the question that drives the branch before anything that depends on it avoids the problem entirely.

Q3. Why does the form refuse to submit with no visible error?

Most often a required question is hidden by a condition. The validation fails on a field that is not on screen, so no error is visible and the submit button appears to do nothing. Every conditionally required question needs one test run where the condition is false.

Q4. How many branches should one form have?

Few enough to draw on paper. Three or four distinct paths, chosen by one early question, stays maintainable. When the list of outcomes reaches nine, the form is doing the work of several forms and splitting it is cheaper than maintaining the conditions.

Q5. How should responses from a branching form be analysed?

Record which path each submission took as a value, not just as the pattern of empty cells. A blank cell cannot otherwise be distinguished from a question that was never asked, and counting how many people took each route becomes a reconstruction rather than a filter.