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.
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.
Google’s own naming overlaps confusingly with general workflow vocabulary. These are the terms as used on this page.
Google’s built-in feature for requesting approval on a file in Drive. Operates on documents, not on form responses.
The Google Sheet a form writes to. Usually where approval status and decision history are also kept.
The ordered set of stages a request must clear from submission to outcome.
Glossary: approval chainThe logic deciding which approver receives a request at each stage, and in what order.
Glossary: approval routingSelecting the chain at run time from the form’s own answers — amount, department, category.
Glossary: conditional approvalA 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.
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 |
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Cost does not scale with the number of form submissions or workflow runs, so a busy month does not change what the process costs.
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.
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.
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.
