Google Forms is the default answer for a sign up sheet, and for good reason. It is already in the account, it costs nothing, and the responses land in a spreadsheet without anyone writing a line of code. Where it gets awkward is the part people assume comes free: a running list of names that the right people can see, a limit that actually closes the sheet, and some acknowledgement of who is in and who is waiting.
All three are solvable. None of them are a single checkbox. Knowing which of them Forms does natively, which needs a workaround, and which needs a different tool entirely is the difference between a sign up sheet that runs itself and one that quietly becomes somebody's second job.
Build the form so the list is usable, not just collected
A running list is only as good as the columns behind it, and those are decided when the questions are written.
Ask for the email address and treat it as the identifier for the person. Names collide and get typed three different ways. The email address is the one value that lets the same person be recognised across a second and third sign up. Forms has a setting under Responses to collect email addresses, and turning it on saves asking for the same thing twice.
Turn a choice into a choice. Shift, session, date, role, size: every one of those should be multiple choice or a dropdown, never short answer. Free text here is what produces nineteen spellings of one Saturday shift, and it is the single most common reason a sign up spreadsheet has to be cleaned by hand before it can be used.
Mark the fields that matter as required. There is a toggle on each question, and using it is cheaper than chasing people for a phone number afterwards.
Keep the form shorter than feels safe. Room is not the constraint: a single form holds up to 300 pieces of content and up to 75 sections, which is far more than a sign up sheet will ever need. The constraint is attention. Every question is a place where somebody stops.
One question worth thinking twice about is file upload. It exists, and it is useful for a signed form or a photo, but to answer it a respondent has to sign in to a Google Account, and the files arrive in a new folder on Google Drive. For an internal sign up that is fine. For a public one, requiring a Google account is a real cost in completed entries.
Get the running list out of the form and into a sheet
Out of the box, responses live inside the form. The Responses tab has a Summary view, and that tab only appears once at least one response has arrived, which is why a brand new form looks like it is not recording anything.
For a running list of names, the summary is not the right surface. Link a spreadsheet instead: Responses, then the More menu, then Select destination for responses, then either Create a new spreadsheet or Select existing spreadsheet. From that point every submission appends a row with a timestamp, and the sheet is where the list gets worked on.
Two details are worth knowing before this becomes the backbone of an event.
When a new response spreadsheet is created, form collaborators get access to it automatically, but the permissions stop tracking each other after that. Later changes to who can edit the form do not propagate to the sheet, so access has to be updated in both places. This is how an ex-volunteer keeps read access to a list of phone numbers for a year.
The link can be broken. Unlink form stops new responses flowing to the spreadsheet while leaving the rows already there intact, and a spreadsheet can be reconnected later through the same destination setting. Useful when an event ends and the sheet becomes an archive.
The timestamp column is the running order, and it is the one thing to protect. Anyone who sorts the sheet by name to find themselves has destroyed the arrival order for everybody else. If several people are going to work in that sheet, sort a copy, never the original.
The four settings that decide how the sign up behaves
Most of what people want from a sign up sheet is controlled by four toggles, and each one has a cost that is easy to miss.
| Setting | What it gives you | What it costs |
|---|---|---|
| Collect email addresses | An identifier for each person, no extra question | Nothing, and it should usually be on |
| Limit to 1 response | Stops the same person signing up twice | Respondents must sign in to a Google Account |
| Allow response editing | People fix their own typos instead of emailing | The list changes under you after you have read it |
| View results summary | Respondents see the list of answers themselves | The summary is visible to anyone who can respond |
Limit to 1 response is the one most sign up sheets reach for and the one with the sharpest trade-off. Google's own documentation is explicit: to access and fill out the form, users must sign in to a Google Account, and their usernames are not recorded unless the setting to collect email addresses is also on. For a school or a company on Google Workspace, that is free duplicate protection. For a public event, it turns away everyone who does not want to sign in.
View results summary is the setting people mistake for a public sign up list. It does show respondents a summary of results after they submit, but it shows the answers to every question, to anyone who can respond to the form. A rota where people need to see which slots are taken is exactly the case where this looks right and is wrong, because the same switch also exposes phone numbers and anything else asked on the form.
One more setting worth setting properly: the confirmation message. It is under Presentation, it can be edited, and it is the only thing a respondent sees for certain. It should say what happens next and when, not just that the form was received.
Capacity is the part Forms does not do
There is no setting in Google Forms that closes a form when a chosen number of responses has arrived. That is the honest starting point, and every approach to capacity is a way around it.
Closing by hand works if somebody is watching. A form has to be published before responders can access it, and the publishing state can be changed back, so the mechanics are simple. The failure is human: the twenty-ninth and thirty-fourth entries arrive eleven minutes apart while nobody is looking.
Closing by deadline is the most defensible. A date removes the argument about who was thirty-first, and it can be announced up front. Responder access can even be given an expiration date when the form is shared with named people rather than by open link.
Closing by script is what most teams end up with when a hard cap is genuinely required. Apps Script, a trigger on form submit, a row count on the linked sheet, and the form closes itself. It works. It is also a piece of code that nobody remembers owning eighteen months later, and when it fails it fails silently in the direction of accepting too many people.
Running a waiting list is the approach that does not fight the tool. Accept past capacity on purpose, treat everything after the line as waiting, and tell those people they are waiting. This is entirely reasonable, but notice what it requires: a status on each entry, and a record of who has been told what. A spreadsheet can hold a status column. What it cannot do is stop two people both emailing the same person, because neither of them can see what the other sent. Handling the same list as a queue where every entry carries an owner and a stage is what the tools built around response management are for.
Showing the list without showing everything
The request that breaks a Google Forms sign up sheet is usually this one: people want to see the list before they sign up, so they know which slots are left.
Sharing the response spreadsheet is the obvious move and the wrong one. It exposes every answer to everyone with the link, and it lets anyone with edit access change another person's row.
There are two workable versions. The first is to publish a narrow view rather than the sheet: a second tab that pulls only the columns which are safe to show, such as the shift and a first name, and then share only that. The second is to publish the count rather than the names, which is what most people actually needed. Nobody signing up for a shift needs the names. They need to know that four of six places are gone.
Both of these are spreadsheet work, and both stay fragile as long as the intake and the display are the same document. Tools that separate the respondent's answers from the fields a team fills in afterwards avoid the problem by design, because the internal columns were never in the same place as the public ones. Seeing that split on a worked example is faster than reading about it, and the demo is set up with sample responses already in it.
Where the work actually piles up
A sign up sheet has three messages in it. Google Forms sends the first one and none of the others.
The acknowledgement is handled: the confirmation message, and a copy of the answers if that option is on. That is the easy one.
The decision is where the work is. Confirmed, waiting, or not this time. Someone has to read the list and act on it, and there is nowhere in a spreadsheet to record that they did. The moment a second person helps, the list has no memory of who wrote to whom, and the choice becomes silence or duplicates.
The reminder before the day is the one that decides whether a full list turns into a full room, and it is the first thing dropped when the week gets busy.
This is the real boundary of Google Forms as a sign up sheet. It is a strong intake surface: free, familiar, generous with questions, and it puts the data in a spreadsheet without complaint. It is not a place where work gets assigned and tracked. If the trouble with the current sheet is the questions, the settings, or the running order, everything above fixes it. If the trouble is that entries sit there unanswered, the missing piece is not another column.
What to change first
Link a spreadsheet, turn on collecting email addresses, replace every free text field that should be a choice, and write a real confirmation message. Then decide capacity out loud: deadline, manual close, or a stated waiting list. If the list is already clean and the problem is the follow through, the next thing to try is a form tool that keeps an owner, a status and the sent replies on each entry, which is what Halict is built around.
Q1. Can Google Forms close a sign up sheet automatically when it is full?
Not with a built-in setting. There is no option for a maximum number of responses, so the choices are closing the form by hand, announcing a deadline, or adding an Apps Script trigger that closes the form when the linked spreadsheet reaches a row count. Many teams accept past capacity instead and run a stated waiting list.
Q2. How do you stop one person signing up several times?
Turn on Limit to 1 response in the form settings. The trade-off is that respondents then have to sign in to a Google Account to answer, and their usernames are not recorded unless the setting to collect email addresses is also turned on. On a Google Workspace domain this is free duplicate protection, and on a public form it costs completed entries.
Q3. Can people see the list of names who have already signed up?
Only if the form owner chooses to show it. View results summary shares a summary of the answers with respondents, but it shows every question to anyone who can respond, including contact details. A safer pattern is a separate tab in the response spreadsheet that pulls only the columns which are safe to publish, or simply showing how many places are left.
Q4. Where does the running list of names live?
Inside the form under the Responses tab, and in a linked Google Sheet if one has been connected through Select destination for responses. The Summary tab only appears after at least one response has arrived. The timestamp column in the spreadsheet is the arrival order, so sorting that sheet by name destroys the order for everyone.
Q5. Does asking for a file upload change anything?
Yes. A file upload question requires the respondent to sign in to a Google Account, and the uploaded files are stored in a new folder on Google Drive belonging to the form owner. File types, the number of files and the maximum file size can all be restricted. For a public sign up, the sign in requirement is the part that costs entries.