Google Forms approval workflow: from a form submission to a routed decision
There are four routes people actually take. What follows covers each of them, what Google provides natively in Drive, how to build a working approval on a form, and the point at which each free route stops being sufficient.
What a form does and does not give you
Google Forms is a good intake mechanism. It captures structured answers, writes them to a Sheet, validates formats, and shows different questions depending on earlier answers. What it does not do is decide anything. A response sitting in a sheet is a request nobody has been asked to act on.
The approval layer supplies four things the form cannot: routing, deciding who should see the request; a decision mechanism, giving that person a way to approve or reject; state, so the request has a current status rather than just a timestamp; and a record, showing who decided what and when.
Every route on this page is a way of supplying those four things. They differ in how much they supply, how much work it takes, and what happens when the process grows past one approver.
Terms used here
Google’s own naming overlaps confusingly with general workflow vocabulary. These are the terms as used on this page.
Drive approvals
Google’s built-in feature for requesting approval on a file in Drive. Operates on documents, not on form responses.
Response sheet
The Google Sheet a form writes to. Usually where approval status and decision history are also kept.
Approval chain
The ordered set of stages a request must clear from submission to outcome.
Glossary: approval chainApproval routing
The logic deciding which approver receives a request at each stage, and in what order.
Glossary: approval routingConditional routing
Selecting the chain at run time from the form’s own answers — amount, department, category.
Glossary: conditional approvalMulti-level approval
A chain requiring two or more distinct stages before the request is granted.
Glossary: multi-level approvalFor the wider category, see approval workflow software and the approval workflow definition.
Four ways to add approvals to a Google Form
Almost every implementation is one of these four, or a combination. They are listed in rough order of effort, and the right one depends far more on how the process will grow than on how it looks today.
| Route | What it is | Suits | Stops at |
|---|---|---|---|
| Drive approvals | Google’s built-in file approval, requested on a Doc, Sheet or PDF in Drive | Approving a document, with a small named set of reviewers | Form responses, conditional routing, amount bands |
| Marketplace add-on | A Forms add-on that emails an approver and writes the decision back | One approver, one form, a process that will stay simple | Multi-level chains, delegation, routing on several attributes |
| Apps Script | Custom script on the form submit trigger, sending mail and updating the sheet | Teams with a developer and an unusual requirement | Maintenance — quotas, retries, and one person understanding it |
| Workflow platform | A dedicated tool that takes the form response as a trigger and runs the chain | Multi-stage chains, conditional routing, audit requirements | Cost, if the process genuinely is one approver and one form |
Choosing between them
What separates them is what the process will need after the first two changes, rather than what it needs today. Approval processes reliably acquire a second condition — a value above which someone else must also sign, a department that routes differently, a category needing a specialist. An add-on handles the first version well and rarely handles the third. A script handles anything and becomes the responsibility of whoever wrote it.
On the free options
Free routes are genuinely sufficient for a large share of cases, and it is worth being honest about that. A single-approver holiday request form served by an add-on needs nothing more. What free routes tend not to cover is the audit requirement — knowing six months later who approved what, against which version of the request — and the behaviour when an approver is unavailable. If neither matters for your process, the free route is the right answer.
Google Drive and Google Docs approvals
Google Workspace includes an approvals feature in Drive, and it is frequently mistaken for a general approval engine. It is worth understanding precisely, because it solves one problem well and is unrelated to form responses.
What it does
Drive approvals let the owner of a file request approval from one or more people. While a request is open the file is locked to prevent edits, reviewers can comment or approve, and the file carries a visible approval status. It works on Docs, Sheets, Slides and PDFs held in Drive, and the lock behaviour is genuinely useful — it is the same principle covered on the document approval workflow page.
Where it stops
It operates on a file, so a Google Forms response cannot be sent for approval this way unless it is first turned into a document. Approvers are named on each request rather than resolved from a rule, so there is no routing by amount, department or category. It has no concept of stages, so a request needing a manager and then finance cannot be expressed. There is no delegation when someone is away, no escalation when a request ages, and no reporting across requests.
When it is the right answer
Use it when what you actually need approved is a document, the approvers are known in advance, and one round of approval is the whole process. Policy documents, contracts going to a named legal reviewer, and design sign-offs all fit. For anything selecting approvers from data, or requiring more than one stage, it is the wrong tool rather than a limited one.
Building an approval workflow on a Google Form
The mechanics below apply whichever route you take. The form design in particular decides how much the rest of the workflow can do, and it is the part hardest to change once responses exist.
Capture the fields the routing will need
Every attribute the chain routes on has to be a structured answer, not free text. Amount as a number, department and category as dropdowns, cost centre from a validated list. Collect the respondent’s email automatically rather than asking for it, since a typed address is what breaks routing most often. Required fields and response validation belong here too — a rejected request that was only ever missing a field is wasted cycles.
Add the columns the workflow writes back to
The response sheet becomes the record, so it needs somewhere to put status, current approver, decision, decision time and any comment. Add these as columns to the right of the form’s own, never between them — Forms appends new responses by column position and inserting a column mid-range breaks that. Keep a separate sheet for the approval rules themselves.
Decide the approver from the answers, not from a name
Keep the rules as data rather than as logic: a sheet mapping amount bands and departments to the approver role required. Resolve the actual person from the Google Directory at run time, so “the requester’s manager” stays correct after a reorganisation. Bands must be contiguous and closed so every response lands in exactly one.
Give the approver enough to decide in place
The request should reach the approver in Gmail or Google Chat carrying the answers that matter, not a link saying a response is waiting. Include the requester, the amount, the justification and any attachment, with approve and reject available from the message. An approver who has to open a sheet to find out what they are approving is the main reason approvals sit unanswered.
Write the decision back and trigger what follows
The decision goes to the response sheet with actor and timestamp, the requester is notified with the reason if rejected, and whatever the approval authorises actually happens — a calendar entry, a document generated, a record created in another system. An approval that notifies nobody and changes nothing is a status field.
Using Sheets as the configuration layer
Holding approval limits and approver mappings in a Sheet rather than inside the workflow is the single most useful design decision available here. It means the person who owns the policy can change a threshold without raising a ticket, the rules are reviewable by anyone who needs to audit them, and a change is a cell edit rather than a deployment. Protect the range, keep a change history, and have the workflow read the sheet at run time rather than caching it.
Where the free and DIY routes stop
These are the six requirements that consistently exceed what an add-on or a script handles well. None of them appear in the first version of a process; all of them appear eventually.
The request needs more than one approver
A second stage means the workflow has to hold state between decisions, and that is where most add-on implementations end. A manager approval followed by a finance approval requires knowing which stage a request is at, what happens if the second approver rejects after the first approved, and whether the requester sees the intermediate state. The routing patterns are covered on the multi-level approval workflow page.
Routing depends on several answers at once
One condition is usually configurable; three interacting conditions usually are not. Routing on amount alone is within reach of most add-ons. Routing on amount and department and category, where a software request above a threshold adds a security reviewer while a facilities request of the same value does not, needs rules expressed as data rather than as settings.
The approver is on leave
Without delegation and a timeout, a request sent to someone who is away waits until they return. Delegation needs standing authority set in advance with both parties recorded on the decision; a timeout needs the stage to escalate to the approver’s manager rather than simply resending. Reassigning the task by hand works until nobody notices the request is stuck.
Someone edits their response after submitting
Decide whether editing is allowed at all, and if it is, invalidate approvals given against the earlier answers. Google Forms can let respondents edit after submitting, which silently changes the request an approver already agreed to. Either disable editing on forms that feed an approval, or detect the change and restart the affected stages — particularly if the edit crosses a threshold and alters which chain applies.
Someone asks what was approved, months later
The audit trail needs actor, timestamp, decision and the request state at the time of that decision — not just a status cell. A sheet showing “Approved” with a name tells you the outcome and nothing about what was agreed to. Delegated decisions need both parties recorded, and timeouts and escalations need to appear as events rather than silent transitions.
The script fails and nobody is told
Apps Script has execution quotas and no retry by default, so a failed run is a request that silently stops. Trigger limits, mail quotas and timeout errors all surface as nothing happening. Add error handling and alerting from the start if you take the script route, and accept that the maintenance burden sits with whoever wrote it.
How form-based approvals degrade over time
A form, a sheet and a script is a reasonable first version, and it usually works. What changes is the process around it rather than the tooling — a second approver, a new department, a threshold nobody wrote down.
Teams graduating from brittle scripts recognise all three of these.
The sheet is the source of truth
Status lives in a cell someone updates. Two people editing at once overwrite each other, a sort reorders the rows, and there is no record of what the state was before the last change.
Failures are silent
A trigger misses, a quota is hit, a mail send fails. Nothing retries and nobody is notified, so the request simply stops — and surfaces when the requester follows up, well after the decision was needed.
One person understands it
The routing rules are hard-coded in a script that one person wrote. Changing a threshold means editing code, and reviewing the rules means reading it. When they move on, the process becomes untouchable.
When the form outgrows an add-on or a script
The routes above cover most requirements, and for a single-approver form an add-on is often the right answer. Where a workflow platform earns its place is the point at which the chain acquires stages, conditions or an audit requirement.
We build Zenphi natively for Google Workspace, so a form submission triggers the chain directly, approvers resolve from the Google Directory at run time, approval rules live in a Google Sheet the process owner edits, and approvers decide from Gmail or Google Chat. Every decision, delegation, timeout and escalation is recorded as an event rather than a status cell.
Native to the Google tools in use
Forms, Sheets, Docs, Gmail, Drive and Chat are first-class rather than reached through a generic connector, so the response sheet and the approval rules stay where their owners already work.
No per-run or per-submission pricing
Cost does not scale with the number of form submissions or workflow runs, so a busy month does not change what the process costs.
AI agents inside the platform
Zenphi lets teams choose AI agents across three providers — Gemini, OpenAI, and Claude — and use them within the workflow to read attachments submitted with a form, summarise a request for the approver, or classify a response for routing.
First-class actions beyond Workspace
QuickBooks, Xero and other business tools are supported as first-class actions, so an approved request can create a record elsewhere without a custom integration project.
Google Forms approvals — common questions
Map your form workflow with an automation expert
If you are deciding between an add-on, a script and a workflow platform — or already have a form-based approval that is starting to strain — a call with one of our automation experts is a practical way to work through it. We can map the chain with you during the call and point out where it will need to change.
