Approvals & workflow

How to set up a form approval workflow

Purchase requests, expense claims, change requests, vendor applications: most organizations have a handful of forms where somebody has to say yes before anything happens. This guide walks through designing that approval properly, then compares the tools you can build it in.

By the Faldaro team · Published September 25, 2026

What a good approval workflow does

Before choosing a tool, it helps to agree on what “working” means. A good approval workflow:

Collects everything the decision needs, once, in a consistent shape.
Puts the request in front of the right person without anyone forwarding emails.
Makes the decision easy to take — ideally from wherever the approver already is.
Never lets a request disappear: every request is somewhere, and waiting has a limit.
Records the decision — who, when, and on what information — where you can find it later.
Does the follow-up automatically, so approval always leads to the same next steps.

Most broken approval processes fail on the fourth and fifth points: a request sits in someone’s inbox for a fortnight, and months later nobody can say who signed it off.

Step by step

Write down the decision. Name the decision being made, who makes it, and which facts they need to make it. Everything else in the workflow follows from that sentence.
Build the form around what the approver needs. Ask for exactly the information the decision depends on, make it required, and compute totals rather than asking people to type them.
Define the states. List where a request can be — Submitted, In review, Approved, Rejected, and usually Returned for changes — and which moves connect them.
Name the approvers and the rule. For each approval step, decide who approves and whether one yes is enough or everyone must agree.
Choose how approvers respond. Decide where the decision happens: an email link, an app, a chat message. The fewer sign-ins it takes, the faster approvals come back.
Add deadlines and escalation. Decide how long a request may wait at each step and what happens when that time runs out.
Automate what happens after the decision. Notify the requester, generate the document, start the next step — so every approval ends the same way.
Test with real examples, then publish. Run a few realistic requests through every path, including rejection and return, before anyone depends on it.

Designing the states

The states are the backbone. A good default for a single-approver process is Submitted → In review → Approved or Rejected, plus Returned for requests that need changes rather than a no. Returned matters more than it looks: without it, “please add the quote” becomes a rejection and a brand-new request, and the history splits in two.

For multi-step approvals, give each step its own state:

Submitted → Manager review → Finance review → Approved
A condition that skips finance under a threshold, rather than a second form
Final states — Approved, Rejected, Withdrawn — that nothing moves out of

Name each move by what the person does (Approve, Send back, Escalate), and decide who is allowed to take it. A move anyone can take is not an approval.

Choosing approvers, and the approval rule

Decide per step whether one approver is enough (first to respond) or everyone named must agree. “Everyone must agree” is the safer rule for money and risk; “first to respond” is faster for routine requests shared across a team. Whichever you choose, decide what a single rejection means — in most processes, one no should stop the request.

Then ask where each approver sits. Colleagues in your own systems can approve anywhere. A client, landlord, partner firm or external consultant is different: if your tool requires them to have an account, every approval starts with an invitation and a password.

Deadlines and escalation

Every waiting step should have a time limit and a consequence. Common patterns:

Remind the approver after a day.
Escalate to a deputy or manager after two.
Expire the request after a set period, telling the requester — an unanswered approval should never quietly count as a yes.

Your options for building it

Approach	Good for	Where it runs out
Email and a spreadsheet	A handful of requests a month, one approver, no budget	Nothing enforces the process; decisions live in inboxes; no deadlines
Microsoft Forms + Power Automate	Microsoft 365 organizations where everyone involved is in the tenant	External approvers need guest access and a licence; external submitters cannot upload files
Google Forms + Apps Script or an add-on	Google Workspace teams with someone comfortable maintaining a script	Scripts run as their creator, within daily quotas; approval state lives in a sheet
Dedicated workflow or intake tools	Recurring processes with several steps, external parties, or an audit requirement	Another tool to adopt; check how each one prices approvers and submitters

The Microsoft and Google routes each have a guide of their own: Microsoft Forms approvals for external users and Google Forms approval workflows.

Building it in Faldaro

Faldaro is one of the dedicated tools, built for intake from outside the organization. The eight steps above map onto it directly:

The form is built in the browser — or drafted from a description or an existing PDF — with totals computed on the server, so a browser cannot fabricate a figure the approver relies on. A free expense claim or project request template is a head start.
The states are drawn as a diagram in the builder’s Workflow tab, with a Review and approve quick start. Each move names the privilege required to take it, and can require a condition or filled-in fields first.
The approvers are reached by the Request an approval action: each named approver is emailed a personal approve/decline link that needs no account, showing only the fields you chose. With several approvers, the move fires once everyone has said yes; any no reads as declined.
Deadlines sit on states: after a set wait, the platform takes the move you named, such as Escalate, and the audit log says the deadline did it. An expired approval request never counts as a yes.
What happens next — a notification, a generated PDF, an e-signature request, a payment request, a linked record on another form — is configured on the states, and runs after the move commits.

Approvals are on every plan, including Free. See approval workflows for the overview and the workflow docs for every setting.

Common mistakes

Approving the wrong version. If the request can be edited after approval, record what was approved, or lock it.
Letting the requester set the flag. An “approved” field anyone can tick is not an approval; the decision should be recorded by the system.
No way back. Without a Returned state, every correction becomes a rejection and a fresh request.
Showing approvers everything. An approver outside the organization should see the fields they are deciding on, not the whole record.
No owner for the queue. Someone should be able to see every waiting request in one place.

Questions

What is a form approval workflow?

A form approval workflow is a process where a submitted form is routed to one or more people who approve or reject it, with the outcome recorded and follow-up actions — notifications, documents, next steps — triggered by the decision.

Should approvals be sequential or parallel?

Sequential when each approver depends on the one before (a manager, then finance over a threshold). Parallel when approvers are independent and you only need everyone’s agreement, which is usually faster.

Can people outside my organization approve?

It depends on the tool. Some require every approver to have an account or a guest identity in your system; others send each approver a personal link that needs no sign-in. If your approvers are clients, partners or landlords, make this the first question you ask a tool.

How do I stop approvals getting stuck?

Give every waiting step a deadline and a defined consequence — a reminder, an escalation to someone else, or an automatic move — and make the queue of waiting requests visible to whoever owns the process.