A Google spreadsheet form usually means one of two things. Either a form that writes each submission into a spreadsheet, so nobody has to be trusted with edit access to the sheet itself, or a data entry screen for a sheet that already exists, so the people adding rows do not have to scroll sideways through forty columns to find the right one.
Both end up in the same place: a form at the front, a spreadsheet behind it, and a set of behaviours that are documented but easy to discover at the wrong moment. The mechanics take a few minutes. What takes longer is working out where the arrangement stops holding up, because the sheet keeps accepting rows long after it has stopped being a workable way to handle what is in them.
Where the link is actually made
The connection between a form and a spreadsheet is created and managed from the form, in the Responses tab. Under Select destination for responses there are two options: "Create a new spreadsheet", which produces a fresh file, or "Select existing spreadsheet", which points the form at one already in Drive.
That is worth knowing because it also tells you what the relationship is. The form owns the responses. The spreadsheet is a destination that receives them. Google's documentation makes this concrete through the reverse operation: choosing Unlink form stops new responses from being sent to the spreadsheet while preserving the data already there.
Read that carefully and the shape of the arrangement becomes clear. An unlinked sheet does not break, warn anybody, or empty itself. It simply stops receiving, and it looks exactly the same as a sheet that is still connected. A tab holding last quarter's submissions and a tab holding a link that silently went away are indistinguishable at a glance, which is why the habit of checking the response count in the form against the row count in the sheet is worth more than it sounds.
The direction of travel matters in the same way. Rows arriving in the sheet are copies of responses held in the form. Editing a cell in the sheet is a change to the copy. Anything built downstream of the sheet, including a second sheet that imports from it, is therefore working from a copy of a copy, and each layer adds a place where a value can be stale without being wrong.
One row per submission, and what that does to the columns
The sheet grows downward, one row per submission, with a timestamp column and a column per question. The structure is decided by the form, and it is decided once. Adding a question later appends a column, which means the older rows carry an empty cell where the new question would have been, and any formula written against a fixed column letter now points somewhere else.
This is the first place a spreadsheet form starts absorbing maintenance. The usual response is to add columns that the form never writes to: a status column, an owner column, a notes column, a date replied column. These are reasonable additions and they work, at first.
They work because a single person maintaining a sheet has perfect knowledge of it. They stop working at the point a second person is added, and they stop for a reason that has nothing to do with the sheet's features. Two people editing the same cell do not get a conflict to resolve. The later write wins, quietly. A status of "replied" can be overwritten by a status of "in progress" entered thirty seconds earlier by somebody reading a stale view, and nothing anywhere records that it happened.
For the other reading of the phrase, a form used as a data entry screen for a sheet, the length of the form becomes the thing to watch. When somebody fills in a form while signed into a Google account, progress is saved automatically as a draft for 30 days, which is what rescues a long entry form from a closed browser tab. Autosave does not work offline, and the form owner is able to switch it off, so a long internal form filled in on patchy connections is worth testing before it is handed to the people who will use it daily.
Filter views help, because they let one person narrow the sheet without changing what everyone else sees. Protected ranges help, because they stop accidental edits to the columns the form writes. Neither of them makes the status column reliable, because the problem is not access control. It is that a cell holds a value with no history, and the work being tracked has a history.
Permissions, which is where the surprises live
Two documented behaviours cause most of the confusion around sharing.
The first concerns the response spreadsheet. When a new response spreadsheet is created, form collaborators automatically get access to it. Convenient, and it comes with a caveat stated in the documentation: later permission changes do not sync automatically between the two files. Removing somebody from the form does not remove them from the sheet holding every submission the form has collected. Access granted once through automatic propagation has to be revoked twice.
The second concerns responders. Google has deprecated the ability to restrict responses to trusted domains, and as of September 8, 2025 responders in trusted domains lost access unless the form was reshared using the newer granular controls. Forms are automatically upgraded to a version with granular responder access, and access is now given by sharing the form with individuals or with specific Google Groups.
For anyone running intake inside an organisation, that is a change to check rather than assume. A form that has been quietly collecting internal submissions for two years may be relying on a sharing model that no longer exists, and the failure appears to the responder as a permission screen rather than to the owner as a warning.
There is a related decision about identity. Limit to 1 response, in the Responses section of the form's Settings tab, is the only way to enforce one submission per person, and it works by requiring people to sign in to a Google account. That is acceptable for staff. For public intake it means anyone without an account, or signed into the wrong one, stops at the door. Comparing that cost against the value of deduplication is a decision about who the responders are, which is the sort of thing the use cases pages lay out per situation.
The documented limits
A spreadsheet form has ceilings on both sides. The form side has four thresholds, all of them documented, and none of them announced in advance.
| Threshold | What stops working |
|---|---|
| More than 10,000 responses | The question and individual views in the form are no longer available |
| More than 10,000 responses | A CSV download is no longer sorted by submission timestamp |
| More than 50,000 responses | The response summary is no longer available |
| More than 100,000 responses | Responses no longer sync with Sheets |
The CSV one catches people who have built a process around taking the most recent row per person, because that approach assumes the export is in time order. Above 10,000 responses it is not, and the result is a wrong answer rather than an error message.
On the spreadsheet side, Google's documentation lists a limit of up to 20 million cells or 100MB for spreadsheets created in or converted to Google Sheets. Cells, not rows, which is why a wide form reaches the ceiling far sooner than a narrow one: a form with sixty questions uses sixty cells per submission before any helper columns are added. Long before the hard limit, a heavily formulated sheet becomes slow to open, and the slowness arrives gradually enough that people adjust to it rather than reporting it.
One more limit is worth stating because it is irreversible. Deleting responses inside the form cannot be undone. Cleaning up test submissions or duplicates on the form side is permanent, so marking rows in the sheet is the safer habit, and exporting before any bulk delete is the safest.
What the sheet does well
None of the above is an argument against the arrangement. For a large class of intake, a form writing to a spreadsheet is the correct answer and anything more is overhead.
It fits when the submission is the deliverable. A signup list, a headcount, a preference collection, an equipment check, a reading log. The row is read once, counted, and never needs an owner or a reply. It fits when the volume is low enough that a person can hold the state in their head, which in practice means a few dozen open items at most. And it fits when exactly one person is responsible, because every weakness described above is a weakness of shared editing rather than of spreadsheets.
It also fits when the analysis matters more than the handling. A sheet is a better place to pivot, chart and cross-tabulate responses than any form interface, and pointing a form at an existing spreadsheet is the cheapest way to get survey data next to the data it needs to be compared against.
When it is a queue wearing a spreadsheet
The signal that the arrangement has been outgrown is not the row count. It is the appearance of columns the form does not write.
A status column means the rows have a lifecycle. An owner column means the rows are assigned to people. A date replied column means somebody has been burned by a missed reply. Each of these is a queue feature being reimplemented in a tool that has no concept of a queue, and each one has to be maintained by a person remembering to maintain it. The specific failure is predictable: the person who handles a response and the person who updates the row are the same person, and updating the row is the part that gets dropped when the day is busy.
At that point the choice is between building discipline around the sheet, which works for as long as the discipline holds, and moving the intake to something where the state belongs to the response rather than to a cell somebody typed into. A form tool with response management carries owner and status as properties of each submission, so marking something handled is the same action as handling it, and the spreadsheet goes back to being what it is good at: analysis, export, and a permanent record. The features page is the quickest way to see which of those columns stop being manual.
What to change first
Count the columns in the response sheet that the form does not write, and count the people who are expected to keep them current. If that second number is more than one, the sheet is being used as a shared queue, and the next thing to fix is not the sheet but where the status lives. Checking the form's response count against the sheet's row count is worth doing on the same pass, since an unlinked sheet gives no other sign. Seeing owner and status held per response, rather than per cell, takes a couple of minutes in the Halict demo.
Q1. How do you connect a Google Form to a spreadsheet?
From the form's Responses tab, use Select destination for responses and choose either "Create a new spreadsheet" or "Select existing spreadsheet". The link is created and managed from the form rather than from the sheet, and each submission is appended to the sheet as a new row with a timestamp.
Q2. If a cell is edited in the response sheet, does the form change too?
No. The sheet receives copies of responses that the form holds, which is why Unlink form stops new responses from being sent while leaving the existing data in the sheet untouched. Anything built on top of the sheet is working from that copy.
Q3. Who can see the spreadsheet a form writes to?
When a new response spreadsheet is created, form collaborators automatically get access to it. Google's documentation notes that later permission changes do not sync between the form and the sheet, so removing somebody from the form does not remove their access to the spreadsheet holding every submission.
Q4. How many responses can a Google Form and its sheet hold?
The question and individual views stop being available above 10,000 responses, the response summary above 50,000, and responses stop syncing with Sheets above 100,000. The spreadsheet itself is documented as holding up to 20 million cells or 100MB, so a form with many questions reaches the ceiling far sooner than a short one.
Q5. Why did my form stop sending responses to the spreadsheet?
The most likely cause is that the form was unlinked, which stops new responses reaching the sheet while preserving what is already there, so nothing looks broken. Above 100,000 responses, syncing with Sheets stops as a documented limit. Comparing the response count in the form against the row count in the sheet identifies both cases.
Q6. Can a spreadsheet be used to track who replied to each submission?
It can, using added columns for owner and status, and it works while one person maintains it. With several people editing, the later write to a cell simply overwrites the earlier one with no history and no conflict, so the record of who handled what is only as reliable as everyone's memory to update it.