Approvals & workflow
How to build an approval workflow on Google Forms
Google Forms is free, familiar and quick to build — but it has no approval step. Teams add one in three ways: a status column in the response sheet, an Apps Script, or a Marketplace add-on. Here is how each works, where each runs out, and the signs it is time for a tool built for approvals.
By the Faldaro team · Published
What Google Forms gives you to work with
Out of the box, a Google Form can:
- Send responses to a Google Sheet, one row per response, via Link to Sheets.
- Collect email addresses — either verified, where the respondent signs in and their Google Account address is recorded, or responder input, where they type one.
- Send respondents a copy of their answers, on request or always.
- Email the form owner when a new response arrives.
That is a collection tool, and a good one. Everything to do with a decision — who decides, what they decided, what happens next — has to be added on.
Approach 1: a status column in the response sheet
The simplest version needs no code. Link the form to a sheet, and let the approver work in it:
- Link the form’s responses to a Google Sheet.
- Turn on the owner’s new-response email notification, or share the sheet with the approver.
- Add Status, Approved by and Decision date columns, with a drop-down (data validation) on Status: Pending, Approved, Rejected.
- Use a filter view or conditional formatting so pending rows stand out.
This works for a small team handling a few requests a week. Its limits are that nothing enforces it: anyone with edit access can set any status on any row, the requester hears nothing unless someone emails them, and a request no one looks at simply waits. Keep the status columns to the right of the form’s columns, and never sort or reorder the response rows — the form keeps writing to that sheet.
Approach 2: Apps Script
Apps Script lets you run code when a response arrives. An installable form submit trigger — on the form or on its linked sheet — can email an approver, write a Pending status, or call another service. A minimal version that emails an approver looks like this:
// In the Google Sheet linked to your form: Extensions → Apps Script.
// Add an installable "On form submit" trigger for this function.
function onFormSubmit(e) {
const answers = e.namedValues; // { "Question title": ["answer"], ... }
const row = e.range.getRow(); // where this response landed
const amount = answers['Amount'][0];
MailApp.sendEmail({
to: 'approver@example.com',
subject: 'Approval needed: request in row ' + row,
htmlBody: 'Amount: ' + amount + '<br>' +
'Review the request in the sheet and set its status.',
});
}
To let the approver decide from the email itself, the usual next step is a small web app in the same project: the email contains Approve and Reject links pointing to the web app, which writes the decision back to the row. That is where the work grows. You need:
-
Unguessable links. A link like
?row=12&decision=approvecan be edited by anyone who sees it. Generate a random token per request, store it, and check it before recording anything. - One decision per request. Refuse a second click, or a click after the request was withdrawn.
- Notification of the requester, from the same script.
- Escalation, usually a time-driven trigger that scans for rows pending too long.
Three constraints shape any Apps Script solution:
- It runs as a person. Google’s documentation is explicit that installable triggers always run under the account of the person who created them. Emails come from that account, and if it is suspended when someone leaves, the workflow stops.
- It runs within quotas. Apps Script limits emails sent per day, total trigger runtime per day and time per execution — with consumer accounts allowed less than Google Workspace accounts. Check the current quota table before relying on a script for volume.
-
Someone has to maintain it. A script is code: when the form changes — a
question renamed, for instance, changes the key in
e.namedValues— the script needs updating, by someone who understands it.
Approach 3: a Workspace Marketplace add-on
Several add-ons in the Google Workspace Marketplace package the Apps Script pattern into a configuration screen: choose approvers, write the email, define the statuses. They save you writing and maintaining the code, and many support multi-level approvals.
Before installing one, check the same things you would check of any vendor: the scopes it asks for (many need access to your forms, sheets and Gmail), where it stores approval data, whether approvers outside your domain are supported, and how it is priced — per user, per form or per response. The underlying data still lives in your Form and Sheet, so the structural limits of that pairing remain.
Limits that no approach removes
Whichever way you add approvals, some properties come from Google Forms itself:
- File uploads need a Google sign-in. Google’s help centre states that respondents must sign in to a Google Account to answer a file upload question, and uploads are stored in the owner’s Drive. For applicants, customers or claimants without Google accounts, that is a barrier.
- Identity is typed unless verified. Verified email collection requires the respondent to sign in; otherwise the email on a response is whatever was typed.
- The response is not the record. The answers live in the form and sheet, the decision in a column or script storage, the correspondence in Gmail. Answering “who approved this, and what did they see?” means looking in several places, and a sheet cell holds no history of who changed it to Approved beyond the sheet’s version history.
- No status for the submitter. The person who submitted cannot check progress; they learn only what someone emails them.
When to move to a workflow tool
A Google Forms approval setup is doing fine while it is small. The signs it has outgrown the pairing:
- More than one approval step, or approvals that depend on the answers (over a threshold, a different approver).
- Approvers or submitters outside your Google Workspace, especially ones who need to attach files.
- Requests stalling, with no one noticing until the requester chases.
- An audit or dispute where you need to prove who decided what, and when.
- The only person who understands the script is about to go on holiday.
Option: an intake platform with approvals built in
Faldaro is a form platform built for intake from outside the organization, with the approval step as part of the form rather than a script beside it. In Faldaro terms:
- Anyone can submit from a revocable public link without an account, and a form that declares a file field accepts uploads from those anonymous submitters.
- A workflow is drawn, not coded — states such as Submitted, In review, Approved and Rejected, and moves between them that each name who may take them.
- Approvers decide from an emailed link with no account: the Request an approval action sends each approver a personal link showing only the fields you choose. The link can take exactly the move you delegated, once.
- Deadlines escalate a request that waits too long, and every move lands in an append-only audit log on the record.
- The submitter can follow along through a status link that shows the current state and reference number, never the answers or internal notes.
Approvals are on every plan, including Free. The Google Forms comparison covers the wider trade-off — including when Google Forms is the better fit — and the approval workflow guide covers designing the process whichever tool you choose.