How to create a Google Form from a Google Sheet

The spreadsheet already exists. Twenty-two columns, a header row that took three revisions to settle, and people filling it in by typing directly into rows, which is why there are now four different spellings of the same department and two dates stored as text. The obvious fix is a form in front of the sheet. The question is whether the form can be built from the columns that are already there, or whether all twenty-two questions have to be typed again.

Both routes exist. Google's own menu item creates a blank form attached to the spreadsheet, and it does not read the headers. Getting questions generated from existing columns means Apps Script or an add-on. Below is what each one does, what it costs, and how to choose.

The built-in route: Tools, then Create a new form

Google documents three ways to create a form, and one of them starts in the spreadsheet. From an open Google Sheet, click Tools and then Create a new form. Google's description of what happens next is precise: a new sheet appears in the spreadsheet, and the form opens.

Note that the menu is Tools, not Insert. Older instructions still circulating point at an Insert menu item, which is why people report that the option has disappeared when it has simply moved.

What this gives is a blank form already linked to the spreadsheet, with a new tab waiting to receive responses. What it does not give is any relationship between the existing columns and the form's questions. The form starts empty. The new response tab is separate from the sheet that already holds the data, and nothing is read from the header row.

That is worth stating clearly because it is the gap between what the phrase suggests and what the feature does. Creating a form from a sheet, in Google's built-in sense, means creating a form attached to a sheet. It does not mean generating a form out of a sheet.

For a spreadsheet with six columns, that distinction hardly matters: building the questions by hand takes ten minutes and produces a better form, because the question types and the help text get chosen deliberately. For twenty-two columns it matters a great deal.

Pointing a form at a spreadsheet that already exists

The reverse direction is often what people actually want: an existing form, or a new one, writing into a spreadsheet that already has other tabs in it.

From the form, go to Responses, then Summary, open More at the top right and choose Select destination for responses. Two options appear. Create a new spreadsheet makes a fresh one in Sheets. Select existing spreadsheet points the responses at a spreadsheet already in Drive. Google notes that responses stored in a spreadsheet are placed in a table, which gives the data structure and formatting rather than leaving it as a plain range.

Either way, responses land in their own new tab. They do not append to an existing tab of historical data, and there is no setting that makes them do so. Combining new form responses with existing rows is a formula problem in a third tab, not a linking option.

Generating questions from the header row with Apps Script

Where the column list is long and already agreed, a short script beats retyping. The Apps Script Forms service is documented for exactly this: create a form, add items to it, and set where responses go using setDestination(type, id), described as setting the destination where form responses are saved.

The shape of the script is straightforward. Read the header row of the source sheet. For each header, add an item to a new form, choosing the item type from a convention agreed in advance. Then bind the finished form to the spreadsheet.

The convention is the part worth thinking about, because a header row contains names, not types. A column called Department is a dropdown if the valid values are known and a text field if they are not, and nothing in the header says which. Three approaches work:

• A type column. Add a hidden row or a separate configuration tab listing each column name and the question type to build, then read that instead of guessing.
• Naming conventions. A suffix in the header, such as a marker for required fields or for choice questions, read and stripped by the script.
• Infer from existing data. Scan the values already in the column. A column with eleven rows and four distinct values is a choice question; one with eleven distinct values is free text.

The third is tempting and the least reliable, since a column that happens to hold few values today will hold a new one next month and the form will have no option for it.

Two details save time later. Build the choice options from a named range in the spreadsheet rather than hard-coding them in the script, so that changing the list does not mean editing code. And run the script as a one-off build rather than as a live sync, because a form that rewrites itself whenever the sheet changes is far harder to reason about than one that was generated once and then edited by hand.

Add-ons that build the form for you

The Google Workspace Marketplace carries add-ons whose stated purpose is building a form from a spreadsheet, and for a team without anyone comfortable in Apps Script they are the shortest path from a header row to a working form.

The trade-offs are the standard ones for add-ons and worth naming rather than assuming. The add-on asks for access to the spreadsheet and often to the forms in the account, which is a decision for whoever owns data governance rather than for the person building the form. The dependency is ongoing if the add-on is used for anything beyond a one-off generation. And the output still needs reviewing, because an automatically generated form tends to produce twenty-two plain text questions where a human would have produced twelve, with three dropdowns and two sections.

Which route fits

The honest default for most cases is the second row. The reason is that a spreadsheet's columns are a record of what was stored, and a form's questions are a request made to a person, and those are rarely the same list. Columns holding values calculated after the fact, internal status fields and identifiers assigned on receipt all belong in the sheet and not in the form. A generated form includes them, and then somebody spends longer deleting questions than they would have spent adding the right ones.

What the linked sheet does once responses start arriving

The tab created by the link is not an ordinary sheet, and treating it as one causes most of the problems that show up a few weeks in.

Columns are positional. Each question writes to a fixed column, assigned when the link is made and when new questions are added. Inserting a column in the middle of the response range, deleting one, or dragging columns into a preferred order leaves later submissions writing where they always did, which is now the wrong place relative to everything built around them. Formulas belong to the right of the last response column, and any rearranging belongs in a separate tab that reads from this one.

Adding a question to the form appends a column to the right of the existing ones, not into the position where it sits on the form. After two or three rounds of edits the sheet column order no longer resembles the form, and anybody reading the sheet has to work from the header text rather than from position. That is survivable, and it is a reason to settle the question list before a form goes into heavy use rather than growing it a field at a time.

Rows are appended in submission order, and that order is the only reliable record of sequence. A sort applied to the sheet does not change where the next submission lands, so a sheet sorted by name will have new responses appear at the bottom out of order. Filter views avoid this, since they leave the underlying order alone and are per person rather than shared.

Deleting a response inside Forms does not remove the row from the spreadsheet, and deleting the row from the spreadsheet does not remove the response from Forms. Where a submission genuinely has to go, it has to go in both places, and whichever one is missed becomes the version that reappears in a later export.

Replacing direct spreadsheet entry with a form

The motivation behind this whole exercise is usually data quality: stop people typing into cells, make them answer questions instead. A form does deliver that, and it changes two other things at the same time.

It removes the ability to correct in place. Someone typing into a sheet fixes their own typo in two seconds. Someone submitting a form cannot, unless response editing is turned on before the submission, and even then only through a link they will probably have lost. Corrections now arrive as messages to whoever owns the form.

It creates a queue. Rows that used to appear complete because the person entering them also acted on them now arrive as submissions waiting for somebody. A spreadsheet has no concept of a submission being handled, so teams add a status column, then an owner column, then a date column, and maintain them by hand with the usual result.

That second point is the one that decides whether the switch improves anything. Where each entry needs an individual response, a form tool with response management is a better fit than a form plus a spreadsheet, because owner and status are properties of the record rather than columns somebody remembers to fill in. The intakes where the difference shows are those with a person waiting at the other end.

What to change first

If the spreadsheet has fewer than about fifteen columns, use Tools then Create a new form and write the questions deliberately rather than mirroring the headers. If it has many more, generate them from the header row with a script and a type map, then edit the result before publishing. Either way, decide before launch who owns the incoming submissions and where their status is recorded, which is the part a spreadsheet cannot hold and Halict keeps on the response itself.

Q1. Does creating a form from a Google Sheet turn the existing columns into questions?

No. The built-in route creates a blank form linked to the spreadsheet, adds a new tab for responses, and reads nothing from the header row. Generating questions from existing columns requires Apps Script or a Marketplace add-on. For a short column list, writing the questions by hand is usually faster than either.

Q2. Where is the menu item for creating a form from a spreadsheet?

In Google Sheets it is under Tools, then Create a new form. Instructions that point to the Insert menu describe an older version of the interface, which is why the option can appear to be missing. Google's own documentation lists this alongside creating a form at forms.google.com or from the New button in Drive.

Q3. Can form responses be added to an existing sheet of data?

Responses can be directed into an existing spreadsheet through Select destination for responses, but they always arrive in their own new tab rather than appending to a tab that already holds rows. Combining the two sets means a formula in a third tab. There is no setting that merges new responses into existing data.

Q4. What is the best way to handle dropdown options that live in the spreadsheet?

Keep the list in a named range and have the build script read it from there, so updating the options is a spreadsheet edit rather than a code change. Regenerating the questions on a live form is disruptive once responses exist, so treat the generated form as a starting point and maintain the options in the form after launch.

Q5. Should data entry move from a spreadsheet to a form at all?

It helps wherever the problem is inconsistent entry, since a form constrains the answers and validation catches the common mistakes. It costs the ability for people to fix their own typos, and it turns entries into a queue that somebody has to work through. Deciding who owns that queue before switching is more important than the choice of build method.