A Google Form collects answers. That is the whole of what it does. The moment a submission has to be looked at by a named person, marked as accepted or turned down, and answered, the form has already handed the problem to a spreadsheet and walked away. Anyone searching for a Google Form approval workflow has hit that wall: the intake half works beautifully, and the half after the intake is being held together by a shared tab and a habit.
This is not a failure of Google Forms. Forms was built as a survey tool, and the survey model ends at the point the answer is recorded. Approval is a different shape of problem. It has state, it has an owner, and it has a reply going back out. Building that on top of Forms is possible in at least four different ways, and each of them fails differently. Knowing which failure you can live with is the actual decision.
What an approval workflow needs that a form does not have
Strip away the tooling and an approval process is four things.
A status that everyone reads the same way. Not a colour, not a note, not a vague recollection that Sam probably took that one. A value from a fixed list, visible on the record itself, that means the same thing to the person who set it and the person who reads it tomorrow.
An owner. One name attached to each submission. Without it, a request either gets worked twice or gets worked never, and both look identical from the outside until someone complains.
A record of what happened. Who moved it, when, and on what grounds. This is the part that gets skipped, and the part that gets asked for six months later when a decision is challenged.
A reply that goes back out. An approval nobody told the applicant about is not an approval. This is where most home-built workflows leak the worst, because the reply happens in a personal mailbox that nobody else can see.
Google Forms supplies none of these. It supplies a timestamp, the answers, and optionally the respondent's email address. Everything above has to be added by something else. The four options below differ only in what that something else is.
Option one: the linked spreadsheet with status columns
The default. Open the form, click Responses, click Link to Sheets, and every submission lands as a row. Then add three columns to the right of the answers: Status, Owner, Notes.
It works, and for a low volume of requests handled by one or two people it keeps working for a long time. The cost is real but slow to appear.
The first problem is that the form owns the left half of the sheet. New responses are appended by Forms, and if anyone sorts, filters with a range, or inserts a row in the middle, the added columns drift out of alignment with the answers they describe. Sorting a linked response sheet is the single most common way these setups quietly corrupt themselves.
The second problem is the reply. The sheet has no send button. Approving a row means copying the applicant's address into a mail client, writing the message, and coming back to mark the row. The reply itself is not recorded anywhere the next person can see, so "has this been answered" becomes a question you can only answer by trusting the status column.
The third is the audit trail. Sheets keeps version history, and you can open it and see edits, but reading a decision history out of version history is an archaeology exercise, not a report. It shows that a cell changed from one value to another at a certain minute. It does not show why, and it does not survive the day someone rebuilds the sheet.
The fourth is scale of the form itself. Google Forms allows up to 300 pieces of content in a form, which includes questions, descriptions, images and videos, and up to 75 sections. That is generous for a survey and it is not usually the constraint. The constraint is almost always the sheet behind it, and the number of hands editing that sheet at once.
Response notifications help slightly. Under Responses, click More, then Get email notifications for new responses. Note that collaborators have to switch this on individually for their own account; turning it on does not notify the team.
Option two: Apps Script with an installable trigger
The second step almost everyone takes. Attach a script to the form or the response sheet, hang an onFormSubmit installable trigger off it, and have the script send a routing email with approve and reject links, write a status back to the sheet, and send the applicant a confirmation.
This genuinely solves routing. It is also where the real limits start.
Apps Script quotas are published and they are not generous for a busy intake. Email recipients per day run at 100 for a consumer Google account and 1,500 for a Google Workspace account. Script runtime is capped at six minutes per execution. Total trigger runtime is 90 minutes per day on a consumer account and six hours per day on Workspace. A form that receives a few hundred submissions in a burst, each firing a script that sends two emails, will hit the daily recipient cap before the day is over, and the failures are silent from the applicant's point of view.
The second cost is ownership of the code. The script runs as the account that authorised it. When that person leaves, changes password policy, or simply has the authorisation revoked by an admin, the workflow stops and nothing announces that it has stopped. Scripted intakes tend to be discovered broken rather than reported broken.
The third is that you are now maintaining software. Every change to the form questions is a change to the script's column indexes. That is fine when the person who wrote it is still there, and expensive when they are not.
Option three: Google Drive Approvals, and why it does not apply here
Google Workspace does have a formal approval feature, and it is easy to assume it covers forms. It does not.
Drive Approvals works on files. A user sends a document in Drive for approval, reviewers get email or Drive notifications, they approve, reject, or leave feedback inside Drive and the Docs editors, and when every reviewer has approved, the file is locked. If one reviewer rejects, the file is rejected. If the file is edited after approval, every reviewer has to approve the new version again.
That is a good contract review process. It is not a submissions queue. The unit of work is a document, not a form response, and there is no path from "a person filled in your form" to "a file is now awaiting approval" without building one.
There is also an edition requirement. Google lists Approvals as supported on Business Standard and Business Plus, Enterprise Standard and Enterprise Plus, Education Plus, the Essentials tiers, and G Suite Business. A personal Google account does not have it, and neither does Business Starter. If your form lives on a free Google account, this option is not on the table at all.
Option four: move the intake to a tool that has the state built in
The fourth option is to stop adding layers and use a form builder where the status, the owner, the history and the reply are part of the product rather than bolted to the side of it.
The trade is straightforward. You give up the familiarity of Forms and the zero price of a consumer Google account. You get back the four things at the top of this article without writing or maintaining anything, and the reply lives on the record where the next person can see it. Tools in this category are usually priced per person rather than per response, which matters if your volume is spiky. It is worth reading what a response management tool actually does after submission before assuming the difference is cosmetic.
The four options side by side
| Linked spreadsheet | Apps Script | Drive Approvals | Form tool with response management | |
|---|---|---|---|---|
| Status on the record | Manual column | Written by script | Approved, rejected, pending | Built in |
| Owner per submission | Manual column | Possible with code | Reviewer list per file | Built in |
| History of changes | Sheet version history | Whatever you log | Per file | Built in |
| Reply to the applicant | Separate mail client | Script, within quota | Not applicable | On the same screen |
| Works on a free Google account | Yes | Yes, at 100 recipients a day | No | Depends on the tool |
| Someone has to maintain it | Low | High | Low | Low |
| Breaks when | Someone sorts the sheet | The script owner leaves | Never, it never applied | Plan limits |
Where each approach actually breaks
Spreadsheet setups break on sorting and on volume. The threshold is roughly the point where more than one person is editing at once, because two people can overwrite each other's status edits in a shared sheet and neither gets a warning.
Script setups break on quota and on people leaving. Both failures are silent. If you run a scripted workflow, the single most useful thing you can add is a daily check that counts yesterday's submissions against yesterday's sent confirmations and complains when the two numbers differ.
Drive Approvals breaks on scope. It is the right tool for a document that needs sign-off and the wrong tool for a queue of incoming requests, and the edition list means it is not available to everyone even when it would fit.
A dedicated tool breaks on cost and on migration effort. Moving an active intake mid-season is unpleasant, and moving one with historical data attached is worse. The usual answer is to move at a natural boundary: the end of an application round, the start of a new programme, the beginning of a financial year. Several of the intake patterns this shape of tool is built around are seasonal for exactly this reason.
Deciding without rebuilding everything first
The honest test is volume against number of people. One person handling fewer than about twenty requests a week can run a linked spreadsheet indefinitely and should not be talked out of it. Two or more people sharing a queue will eventually lose something in a shared sheet, and the only question is whether that happens before or after it matters.
If routing is the only missing piece and the volume is small, a script is a reasonable investment. If status, ownership, history and replies are all missing, a script is four separate projects, and the maintenance sits on one person forever.
What to change first
Before choosing any of the four, add one column to your existing response sheet and fill it in for a fortnight: the date the applicant was actually replied to. That single number tells you whether you have a routing problem or a reply problem, and they need different fixes. If the gap turns out to be the reply, look at a tool where the submission and the send box sit on the same screen, such as Halict, rather than adding another layer to the form.
Q1. Can Google Forms send a submission to a manager for approval automatically?
Not on its own. Forms can email you that a new response arrived, but it cannot route that response to a named approver or record their decision. Routing requires Apps Script with an installable onFormSubmit trigger, a third party add-on, or a form tool that has approval states built in.
Q2. Is Google Drive Approvals the same as approving form responses?
No. Drive Approvals operates on files in Drive such as Docs, Sheets and PDFs, not on rows of form responses. It also requires a qualifying Google Workspace edition, and it is not available on personal Google accounts or on Business Starter.
Q3. How many emails can an Apps Script approval workflow send per day?
Google publishes a limit of 100 email recipients per day for consumer accounts and 1,500 per day for Google Workspace accounts. A workflow that sends both a routing email and an applicant confirmation uses two recipients per submission, so the practical ceiling is roughly half those numbers in submissions.
Q4. Why does the status column in the linked spreadsheet keep pointing at the wrong row?
Because Google Forms appends new responses to the sheet independently of anything you do to it. If someone sorts the sheet, applies a sort to a partial range, or inserts a row, the columns you added stop lining up with the answers they describe. Adding a helper column that copies the response timestamp lets you detect this, but it does not prevent it.
Q5. Is it worth moving off Google Forms just to get approval states?
It depends on how many people share the queue. One person with light volume rarely benefits. Two or more people working the same submissions usually do, because the cost of a shared spreadsheet is not the spreadsheet itself but the collisions, the untracked replies, and the absence of a record when a decision is questioned later. Comparing the cost per person against the hours currently spent reconciling is a reasonable way to settle it.