Create a Google Doc form: what people mean and what to use instead

Nobody searches for how to create a Google Doc form by mistake. The phrase sits on a real ambiguity, and the three things it can mean have almost nothing in common. One of them collects structured answers you can compare. One of them produces a pile of separate documents. One of them is a workaround that stopped being necessary years ago.

There is also a reason the wording feels right even when it is imprecise. A Google Form's editing address is on the same domain as a Google Doc: the Forms API documentation gives the canonical edit URL as docs.google.com/forms/d/FORM_ID/edit. The form genuinely is a docs.google.com file.

The three things the phrase can mean

A form built in Google Forms. This is what most people want. Google lists Forms as its own product in the Workspace lineup, separate from Docs, Sheets and Slides. Questions, one answer set per respondent, results aggregated automatically.

A fillable document in Google Docs. A document with blank lines, a table to complete, or dropdown chips inside a table, which somebody copies, types into, and sends back. It is a document first and a form second.

A form assembled from a document. Marketplace add-ons exist that read a document and build a form from it. These matter when the questions already exist as a long written brief somebody else wrote, and retyping forty of them by hand is the actual problem.

The choice between the first two is not a matter of taste. It is a question of whether the answers need to line up.

Route one: the form is a Drive file with a schema

It helps to know what a Google Form is underneath, because it explains most of its behaviour.

The Forms API documentation describes a form as a document created and stored in Google Drive, identified by a unique formId that appears in its URL. Everything inside it is an Item, and an item can be a section, a question group, a single question, text, an image or a video. A section corresponds to a PageBreakItem, and the documentation is explicit that sections are how a form is split across pages and how conditional logic is added, meaning only certain questions appear based on earlier answers. A quiz is not a different product; it is the same form with isQuiz turned on, which enables per question point values, answer keys and feedback.

Two practical consequences follow. Branching is organised around sections rather than individual questions, so a form that needs to branch has to be structured into sections that match the branches. And because a form is a Drive file, everything about who can open it is a Drive permission, not a form setting.

That second point is where the 2026 change bites.

Building the form in the order that avoids rework

The sequence matters more than any individual setting, because two of these steps are expensive to change later.

Decide the unit of a response first. One row per person, one row per application, one row per shipment. This sounds obvious and it is the thing most often got wrong, usually by building a form that collects three items in one submission and then discovering they need separate statuses.

Put the questions that decide eligibility at the top, before anything that takes effort to answer. Somebody who does not qualify should find that out before writing three paragraphs, and the intake side should not be storing detail it will never use.

Lay out sections before writing questions. Since sections are the unit that branching operates on, deciding them afterwards means moving questions between pages, which in turn means rebuilding the branch destinations.

Name the file deliberately. A form is a Drive file, and in a year the folder will hold several with similar names. Include the intake it belongs to and the year.

Leave publishing and permissions until last, and test with an account that is not the owner's. A form that works perfectly for the person who built it and rejects everybody else is the most common launch failure, and it is always a permission, not a question.

Route two: a fillable document, and when it is right

Sometimes the document is the point. A consent sheet that has to be printed and signed, an agreement whose layout is part of what was agreed, a brief that a client will annotate in the margins. In those cases a form is the wrong shape, because a form throws away the layout and keeps only the values.

What the document route costs is comparability. Ten returned documents are ten files. To answer a question like "which of these applicants listed a driving licence", somebody opens ten files. At thirty, that stops happening and the information effectively disappears even though it was collected. Dropdown chips inside a Docs table help with consistency inside one document, but they do not put the twelfth respondent's answer next to the eleventh.

A reasonable rule: if the same question will be answered by more than about five people and the answers will ever be compared, sorted or counted, the answers belong in a form. If the artefact itself matters more than the data in it, keep the document.

Route three: turning an existing document into a form

The add-on route deserves its own note, because the situation that produces it is specific and common. Somebody in the organisation has already written the questions. They exist as a numbered list in a document, forty of them, approved by a committee, with wording that cannot be casually changed. Retyping them into a form builder is an hour of clerical work with a real error rate, and the person doing it is not allowed to improve the phrasing along the way.

Marketplace add-ons that read a document and generate a form from it solve exactly that, and nothing else. Three things are worth checking before relying on one. Whether it maps question types, or whether everything arrives as a short answer box that then has to be converted by hand anyway. Whether it handles sections, since a form that needs branching needs those breaks in the right places and an add-on that produces one flat list has only moved the work. And whether the mapping runs again, because approved question sets get revised, and a tool that can only do the first import means the second version is typed out after all.

None of this changes what happens after submission. An imported form behaves exactly like one built by hand, which is the point: the add-on saves the transcription, not the decisions.

The publishing change that catches people out in 2026

Google has introduced granular controls over who can respond to a form, and the documentation states the consequence plainly: forms created through the API after June 30, 2026 are created in an unpublished state by default and will not receive responses until they are published. Forms created by the API up to that date were published by default, so scripts written earlier and left alone will quietly stop collecting anything.

The mechanics are worth knowing even if no API is involved, because the same two switches sit behind the interface. Publishing is controlled by isPublished, and whether the form takes answers is controlled separately by isAcceptingResponses. Unpublishing a form makes it unavailable and automatically stops it accepting responses. Closing a form without unpublishing it leaves the form reachable and shows respondents the closed message instead.

Responder access is Drive machinery. A responder holds the PUBLISHED_READER role, and adding one is a Drive permissions.create call with the view set to published. An "anyone with the link can respond" form is, underneath, a Drive permission whose type is anyone, whose view is published and whose role is reader. Removing a responder revokes their ability to view and submit the form unless they have access by some other route, such as domain sharing or a shared drive.

One more term to recognise: forms that do not return publishSettings are described as legacy forms, and all newly created forms support publish settings. If a script checks whether a form supports publishing and gets back no, that form predates this model.

Which route for which job

The middle column is not a lesser option. It is a different job. The mistake is choosing it because a form felt like more setup, and then discovering at submission forty that the answers cannot be read together.

What the form does not decide for you

Getting the form built is the part that feels like the work, and it is the part that finishes. What continues after that is handling what arrives, and the form's structure has very little to do with how well that goes.

Google's own description of Forms focuses on the collection and the summary: responses visualised as charts that appear automatically, and results analysed collaboratively. That is genuinely useful for a survey, where the answer is a distribution. It is not the shape of the problem when each response is a person who needs a reply.

Three questions decide whether intake works, and none of them are form building questions. Can a response be assigned to a named person, so two colleagues do not both answer it. Does a response carry a status everybody can see, so an unanswered one is visible rather than remembered. Is the reply that was sent stored on the response itself, so the next person to open it can see what was already said. A spreadsheet of responses can be made to carry all three by hand, with a column for owner and a column for status, and it works until somebody forgets to update a cell. What a response record holds by default is the difference between that discipline being optional and being automatic, and it is worth comparing against the use cases where intake continues after submission before settling on a setup.

What to change first

Decide whether the answers will ever need to line up, because that single question picks the route and nothing else really does. Then, before building anything, check what happens to a response after it arrives: who owns it, what status it carries, and where the reply gets stored. That part is easiest to see running, which is what Halict is there for.

Q1. Can a form be built inside Google Docs itself?

Google's published documentation presents Forms as its own product, separate from Docs, and Docs documentation describes document features such as tables and dropdown chips rather than a response collecting form. The practical routes are a Google Form, a document people fill in and return, or a Marketplace add-on that builds a form from a document's contents.

Q2. Why does a Google Form have a docs.google.com address?

Because it is a Drive file in the same family. The Forms API documentation gives the editing URL as docs.google.com/forms/d/FORM_ID/edit, and the respondent link is a docs.google.com address as well. That shared domain is most of the reason the phrase "Google Doc form" exists at all.

Q3. My form stopped receiving responses. What changed?

If the form is created by a script or an integration, check the publishing state. Forms created through the API after June 30, 2026 are created unpublished by default and do not accept responses until they are published explicitly. Publishing and accepting responses are separate settings, so a form can be published and still be closed.

Q4. How do I let only certain people respond?

Responder access is a Drive permission with the published view, so it is granted per person rather than as a form option. An open form is the same mechanism with the permission type set to anyone. Removing somebody's responder permission stops them submitting unless they still have access through domain sharing or a shared drive.

Q5. Should responses go to a spreadsheet or stay in the form?

For a survey, either is fine, because the answer you want is a summary. For intake where each response needs a reply, a spreadsheet only works if somebody maintains an owner column and a status column by hand. Check whether the tool assigns those automatically before committing to the spreadsheet route.