Google Forms section navigation: which rule wins

Last updated September 2026 · ~8 minute read

Short answer: a Google Form has two navigation layers, and the per-answer one wins. Every section carries a default destination for everyone who reaches its end; a Multiple choice or Dropdown answer can carry its own. Where both are set, Google's Apps Script reference says the answer's destination “overrules” the section's. On the last page neither one does anything at all — and that sentence exists in exactly one place in Google's documentation.

This page is about how the two layers resolve against each other, and about what a “section” turns out to be once you look at the data model rather than the editor. If you want the click-path for setting a branch, that lives on conditional logic in Google Forms; if you want to know what a section is for, that is section headers. Everything below assumes you have already set one.

The two layers, and where Google documents each

They are not two views of one setting. They are stored in different places, written by different APIs, and documented on pages that never mention each other.

The section default applies to everyone who finishes that section without being routed elsewhere. Google's help centre gives it one sentence, on the Show questions based on answers page: “At the bottom of each section, you can choose which section people go to next.” That is the whole of the help centre's coverage — it does not name the available destinations, or say what happens when something else disagrees with it.

The destinations are named in the developer documentation instead, as the PageNavigationType enum. There are four, and the wording is Google's:

• CONTINUE — “Continue to the next page of the form after completing the current page.”
• GO_TO_PAGE — “Jump to a specified page of the form after completing the current page.”
• RESTART — “Restart the form from the beginning, without clearing answers entered so far, after completing the current page.”
• SUBMIT — “Submit the form response after completing the current page.”

The per-answer branch hangs off a single option of a single question. In the Forms REST API it is two mutually exclusive fields on Option — goToAction (“Section navigation type”) and goToSectionId (“Item ID of section header to go to”). Its enum, GoToAction, has three usable values — NEXT_SECTION, RESTART_FORM and SUBMIT_FORM — because the fourth case Apps Script names, a jump to a particular page, is carried by goToSectionId instead. Which question types can carry one is a fight between two Google help pages, and the multiple choice guide settles it rather than this one.

Three resolution rules, only one of which is well known

The first is the one everybody quotes. On PageBreakItem.setGoToPage(): “If the previous page contained a MultipleChoiceItem or ListItem with a navigation option, that navigation overrules this navigation.” The section default is the fallback for respondents whose answer did not route them. That is covered in depth on the conditional logic guide and there is nothing to add to it.

The other two are on the PageNavigationType page and are almost never repeated anywhere:

Several routing answers on one page: the last one wins. “If the respondent chose multiple options with page-navigation instructions on the same page, only the last navigation option has any effect.” Read that boundary carefully — Google says page, not question. Two different routing questions sitting in the same section fall under this rule just as much as two ticked boxes in one question do. Google does not define what “last” means in terms of item order versus selection order, so a section with two routing questions in it is a section whose behaviour you should test rather than reason about.

Within one question, it is all or nothing. “Choices that use page navigation cannot be combined in the same item with choices that do not use page navigation.” This is why turning branching on for a question appears to give every option a destination rather than just the one you wanted. It is not the editor being officious; a mixed question is not a legal state.

What happens on the last section

One sentence, in one place, on the PageNavigationType page: “Page navigation also has no effect on the last page of a form.” It appears nowhere in the help centre and nowhere in the REST reference.

So a destination set on the final section is inert. Setting the last section to Submit form does nothing the form was not already going to do, and — more usefully — a leftover Go to section 2 on what has since become the last section will not trap anyone in a loop. What the last section's button actually says is a separate question, handled on the submit button guide.

Can a respondent go backwards?

Google does not document a respondent-controlled Back. That is a claim worth being precise about, so here are the four places checked: the Docs Editors help centre, the Apps Script Forms reference, the Forms REST API reference, and the live REST discovery document (forms.googleapis.com/$discovery/rest?version=v1, revision 20260909). No back or previous navigation appears in any of them. Apps Script's PageBreakItem exposes getGoToPage() and setGoToPage() and nothing pointing the other way; the discovery document contains no navigation field other than the two on Option.

What Google does document is going backwards under the owner's control. Its respondent-facing page, Fix common errors while you respond to a Google Form, carries a heading for it — “If you click ‘Next’ and it loops back to previous sections” — and explains: “In some cases, a form returns to the same question or takes you back to a previous one when you click ‘Next.’ This behavior is often intentional, as form owners can set up forms to loop back to earlier sections based on your answers.” Google treats a backwards jump as a designed outcome, not a fault.

The one documented way to move a respondent backwards wholesale is RESTART, and Apps Script is the only place that says what it costs: it restarts “without clearing answers entered so far.” The REST reference's equivalent, RESTART_FORM, says only “Go back to the beginning of the form” and is silent on whether the answers survive. If you are working from the REST documentation alone, that detail is not there to find.

What a “section” is in the API

There is no section object. A form is a flat list — Form.items, “a list of the form's items, which can include section headers, questions, embedded media, etc.” A section is not a container holding its questions; it is a marker, and the questions after it belong to it by position alone.

The marker is PageBreakItem, and the REST reference's entry for it reads, in full: “This type has no fields. A page break. The title and description of this item are shown at the top of the new page.” Even the title and description are not its own — they live on the wrapping Item. A section's identity, for routing purposes, is the page break's itemId: that is exactly what goToSectionId stores.

Two consequences follow, and they explain things the editor makes look arbitrary.

The REST API cannot set a section's default destination. PageBreakItem has no fields, and the rest of the discovery document has no navigation field anywhere else — only goToAction and goToSectionId on Option. Apps Script does have one, setGoToPage(). The two Google APIs for the same product are not equivalent here, and no Google page says so; you find it by reading both.

Section 1 has no page break. The first page starts because the form starts, so there is no item to point goToSectionId at — which is, by inference rather than by Google's statement, why RESTART_FORM exists as a separate action instead of being a jump like any other.

And the default destination is attached where you would not expect. Apps Script's setGoToPage() sets what happens “after completing the page before this page break (that is, upon reaching this page break by normal linear progression through the form).” The editor shows the control at the foot of section 1; the API stores it on the page break that starts section 2. Same setting, opposite end.

How this looks in Forms+

Forms+ is a native iPhone and iPad editor for real Google Forms, and it has to live with the same split. The section default appears as a row reading After section 1 · Continue to next section, and its choices are the four the API allows: Continue to next section, Go to section 1 with your form's title beside it, Go to section N for each later section with that section's title, and Submit form. Because the REST API has no field for it, Forms+ reads that value with Apps Script's getGoToPage() and writes it with setGoToPage() — the workaround the data model forces on any client.

The all-or-nothing rule shows up too: switching Go to section based on answer on for a question sets every option on it to CONTINUE in the same motion, because a question with some routing options and some plain ones is not a state the API accepts.

Frequently asked questions

Does a per-answer branch override the section's own destination?

Yes. Google's Apps Script reference for PageBreakItem.setGoToPage() states that if the previous page contained a MultipleChoiceItem or ListItem with a navigation option, “that navigation overrules this navigation.” The section default is the fallback for everyone whose answer did not route them somewhere else.

What happens to section navigation on the last section of a form?

Nothing. Google's PageNavigationType page says plainly that “page navigation also has no effect on the last page of a form.” A destination left on the final section is inert, which is why an out-of-date setting there cannot loop anyone.

Can respondents go back to a previous section in Google Forms?

Google documents no respondent-controlled Back — not in the help centre, the Apps Script reference, the REST reference, or the REST discovery document. It documents only owner-driven backwards movement: its respondent troubleshooting page says a form “returns to the same question or takes you back to a previous one when you click ‘Next’” and calls that “often intentional.” The RESTART action sends someone back to the beginning “without clearing answers entered so far.”

What if two answers on the same page point at different sections?

Google's rule is that “only the last navigation option has any effect.” Note that it is scoped to the page, not the question, so two routing questions in one section are covered by it as well. Google does not define what “last” means, so test it on a copy of your form.

Can the Google Forms API set what happens after a section?

Not the REST API. Its PageBreakItem entry reads “This type has no fields,” and the discovery document carries no navigation field outside goToAction and goToSectionId on Option. Apps Script can, through PageBreakItem.setGoToPage(). The two APIs are not interchangeable for this.