Google Forms logic: branching that keeps the form short

Google Forms has branching, and it is better than its reputation suggests once the shape of it is clear. The confusion comes from expecting it to work the way logic works in dedicated form builders, where a rule hides an individual question. Google Forms does not do that. It routes between sections, from a small set of question types, and every design decision follows from those two facts. A form built with that in mind stays short and maintainable. A form built by fighting it ends up as forty sections nobody will edit.

The two rules that define what is possible

Google's documentation on showing questions based on answers sets out the mechanism in a few lines. On a question, the More menu offers "Go to section based on answer", and the same menu allows an answer to end the form by choosing "Submit form". Then comes the constraint that decides everything else: "Go to section based on answer is only available for Multiple choice and Dropdown question types."

The second mechanism is separate and often overlooked. The documentation describes it under skipping sections: "At the bottom of each section, you can choose which section people go to next." That is a default route attached to the section itself, independent of any answer.

Those two together are the whole system. An answer on a multiple choice or dropdown question can send somebody to a named section or end the form. A section can declare where everybody goes next by default. There is no rule that hides a single question, no rule based on a text answer, no rule that combines two answers.

Google's question types page adds one detail worth noting: it lists checkboxes alongside multiple choice and dropdown as being able to "send them to a certain section of the form", which is the one place the two pages read differently. For anything being built now, the safe assumption is the narrower one, and a design that routes only from multiple choice and dropdown will work regardless.

What this rules out, stated plainly

It is quicker to list the patterns that are not available than to discover them one at a time.

A follow up question cannot appear underneath the question that triggered it. The follow up has to live in its own section, which means a page turn. For a single conditional question this feels heavy, and there is no way around it.

A text answer cannot drive a route. If the question asks which department somebody works in and the answer is typed, nothing can branch on it. Converting that question to a dropdown is the fix, and it is usually an improvement anyway, since a typed department name arrives spelled eleven different ways.

Two answers cannot be combined. There is no way to express a route that depends on being both a returning customer and outside the country. Expressing that needs an extra question that asks the combined thing directly, which is worse for the visitor but the only available route.

A required field cannot be made conditional. A question is either required or not, for everybody who reaches the section it sits in. The way to approximate this is to put the question in a section that only the relevant path reaches, and mark it required there.

Designing sections so the routes stay readable

Because routing happens at the section level, the section layout is the logic. Getting it right at the start is much cheaper than rearranging it later, since moving a section can silently change where routes point.

Put everything shared first. Name, contact address and anything asked of every respondent belongs in the opening section, before any branch. Duplicating shared questions inside each branch is the most common mistake in a branched Google Form, and it produces a response sheet with three columns that all mean the same thing.

Use one question to branch. A single multiple choice question asking which kind of request this is, at the end of the shared section, is easier to read in the editor and easier to fix than branching decisions scattered across four questions.

Name sections after the path, not by number. "Section 4" tells the next person nothing. "Existing customer, hardware fault" tells them whether the section is still needed when the process changes.

Terminate every path explicitly. This is where branched forms leak. Each branch section needs a destination at the bottom, either a shared closing section or Submit form. A branch left on the default "Continue to next section" quietly walks the respondent into the following branch's questions, and the symptom is a submission with fields filled in that should have been unreachable. Checking the bottom of every section is the single highest value review pass on a branched form.

Keep the depth to one level where possible. One branch point with three destinations is easy to hold in the head. A branch inside a branch inside a branch is a program, and the editor gives no view of it as a whole.

A worked layout for a three way intake

Concrete beats abstract here, so consider a support form that has to handle a hardware fault, a billing question and everything else.

Section 1 holds the shared questions: name, contact address, and the organisation. Its last question is a multiple choice asking what the request is about, with three options, and each option carries a route. There is no need to set a next section at the bottom of section 1, because every answer routes explicitly.

Section 2 is named for the hardware path and asks the three things a hardware fault needs, including a required serial number. At its bottom, the destination is section 5.

Section 3 is the billing path, asking for the invoice reference and the nature of the query. At its bottom, the destination is section 5.

Section 4 is the catch all, with one long text question. At its bottom, the destination is section 5.

Section 5 is shared again: preferred contact method, and a required question recording the path, which exists purely so the response sheet has a column naming the route. At its bottom, Submit form.

That is five sections, one branch point, three paths, and every section terminated deliberately. It produces a response sheet in which the shared columns are always populated, exactly one path's columns are populated per row, and one column states which path it was.

The temptation is to add a second branch inside the hardware path, because hardware faults really do divide further. Resisting that once is usually correct: a second level doubles the number of walks needed to test the form, and the extra questions can be asked in the reply instead, by the person who reads the submission.

Testing a branched form before the link goes out

Preview is not a test. It confirms that the questions look right; it does not confirm where the routes go, because the interesting behaviour only appears when answers are actually submitted.

Walk every path as a real submission, choosing a different answer each time. Count the paths first: a single branch question with four options and one shared closing section is four walks. If the number is large enough to be tedious, that is information about the form rather than about the testing.

Then read the response sheet rather than the form. A correctly branched form produces rows where each path's columns are filled and the others are blank, in a consistent pattern. If a row has values in two branches' columns, a section is missing its route at the bottom. This check catches the leak described above in seconds, and it catches nothing else, which is why it is worth doing every time the sections change.

One structural note from Google's documentation on editing a form: a form can hold up to 300 pieces of content and up to 75 sections. Neither is a real constraint for most branched forms, and if a design is approaching 75 sections, the branching is no longer the problem to solve.

The part branching does not touch

Logic decides what the respondent sees. It has no effect on what happens to the submission, and that gap is where the actual daily cost of a branched form usually sits.

Every path lands in the same response sheet. A form with four branches produces one wide sheet in which each row uses a different quarter of the columns, and separating the four kinds of request means filtering by which columns are populated. Nothing in the form marks a row as belonging to path two.

Nothing in the sheet records who is dealing with a row, or whether it has been dealt with. A branched intake form that successfully routes four kinds of request still delivers all four into one list where a person reads each one to work out which kind it is and whether somebody already replied.

There is a cheap partial fix worth knowing. Each branch can end in its own section whose only content is a description naming the path, and a short required question there records the path as a value in a column of its own. The sheet then has one column saying which route was taken, which makes filtering and counting possible without inference.

Beyond that, the work moves outside the form. Giving each response an owner and a status, seeing which stage it has reached, and replying on the same screen as the answers are what the tools that operate on a response after it arrives exist for. The intake processes where branching and handling collide are the familiar ones: applications, recruitment and enquiries that split by team. Worth checking alongside that is how a tool prices the traffic a working form generates, since plans that charge by people rather than by responses behave very differently when a form suddenly gets popular.

What to change first

Open the form and check the bottom of every section for an explicit destination, since a missing one is the defect that produces impossible submissions. Then add a question at the end of each branch that records which path was taken, so the response sheet can be filtered. If the remaining cost is sorting and answering rather than collecting, that is the part to move, and it is worth seeing as a working example in Halict.

Q1. Can a single question be hidden in Google Forms based on an answer?

No. Routing works at the section level, so a conditional question has to live in its own section that only one path reaches. The respondent sees a page turn where a dedicated form builder would simply reveal the question in place.

Q2. Which question types can branch?

Google's documentation states that "Go to section based on answer" is only available for Multiple choice and Dropdown question types. A typed answer cannot drive a route, so any question intended to branch has to be converted to one of those two.

Q3. Why is a submission showing answers from a branch the respondent should not have reached?

Almost always because a section is missing an explicit destination at the bottom and falls through to the next section in the editor's order. Setting the next section, or Submit form, at the bottom of every branch section fixes it.

Q4. Can a form end early for some answers?

Yes. On the answer itself, choosing Submit form ends the form rather than continuing to a section, which is the right pattern for a screening question that disqualifies some respondents before they answer anything else.

Q5. How can the response sheet show which path each respondent took?

Add a short question in a section that only that path reaches, and record the path name as its answer. That produces a single column naming the branch, instead of leaving somebody to infer the path from which columns are blank.

Q6. Is a branched form better than several separate forms?

One form is better when the branches differ by a few follow up questions and end in the same outcome. Separate forms are better when the branches go to different teams and end in different outcomes, because a branched form delivers all of them into one response sheet with no marker saying which is which.