A form is collecting requests. Every request needs somebody to say yes or no before anything happens next. Right now that probably means the submission lands in a mailbox, someone forwards it to a manager with the words "ok with you?", and the answer comes back as a reply that has to be read, interpreted, and typed into a spreadsheet by hand.
That arrangement works until the third or fourth approver joins, or until somebody asks what happened to a request from two weeks ago. Then the gap becomes obvious: the form captured the request perfectly, and nothing in the system knows the request is waiting.
The four jobs hiding inside the word approval
Search results for forms approval are mostly build instructions. They show how to wire a trigger to an approval action. That skips the design question, which is what the approval step is actually responsible for. There are four distinct jobs, and tools differ sharply in how many of them they cover.
Routing. Deciding which person or people this particular request goes to. Sometimes it is one manager for everything. More often it depends on something in the submission: the department, the amount, the site, the type of request. Routing that depends on the answers has to read the answers, which is why routing by mailbox rule tends to collapse once there is more than one rule.
Holding. Keeping the request in a known state while nobody has answered yet. This is the job that email cannot do. An unanswered forward looks exactly like an answered one, and the only record that the request exists at all is somebody's memory.
Deciding. Capturing the answer in a form that a machine can act on. A reply that says "fine by me, though check the dates" is a human answer and not a decision. A decision is approved or rejected, attached to a named person, with a timestamp and optional comments.
Recording. Keeping the decision and the request together afterwards, so that six months later the question "who approved this, and what did the request say at the time" has an answer that does not depend on searching a mailbox.
A design that covers routing and deciding but not holding is the common failure. It is also the one that feels finished when it is built, because every test request gets answered within the minute.
Where the approval step lives
There are three realistic places to put it, and the choice has more effect on daily work than any setting inside the tool.
| Where the decision happens | What it needs | What it covers well | Where it gets thin |
|---|---|---|---|
| Inside the form tool, as a status on the response | A form tool that stores an owner and a state per response | Holding and recording, with no second system to keep in step | Deep conditional routing across many departments |
| A workflow builder next to the form | A flow platform and someone to maintain the flows | Routing on any field, chained stages, connections to other systems | Holding beyond the platform time limits, and visibility for anyone not in the flow |
| The approver's inbox, by convention | Nothing | Nothing that survives a holiday | Every one of the four jobs |
The third row is not a joke. It is the arrangement most teams actually have, and it is worth naming because it sets the bar: any replacement has to be quick enough that people do not quietly go back to forwarding.
The first two rows are not exclusive. A sensible split is to let the form tool hold the state and own the record, and to use a flow platform only where routing genuinely depends on logic that the form tool cannot express. What goes wrong is the reverse: the flow platform holds the state, and the state is visible only to whoever opens the run history.
What the approver needs on one screen
Approval delay is usually not disagreement. It is that the approver cannot answer without going to look something up, so the request sits in the inbox until the looking up feels worth it.
Reduce that to a single screen and the delay drops on its own. The screen needs the answers as submitted, in the order they were asked, including the ones that seem irrelevant. It needs who submitted it and when. It needs whatever the team recorded internally after the submission arrived, which is often the piece that decides the answer: the budget line it hits, whether this requester has an open request already, what was agreed last time. A form tool that keeps internal fields alongside the submitted answers puts that in the same view rather than in a second spreadsheet, and the features that matter here are the ones that operate on a response after it arrives rather than on the form before it goes out.
It also needs the two buttons to be the only two buttons. When approve and reject sit next to a free text box, approvers use the text box, because prose is easier than commitment. The comment field should stay, and it should be optional and clearly secondary.
The waiting period, and the limits nobody reads until later
If the approval runs on a workflow platform, the waiting period has hard edges that are published and worth knowing before the design is finished. On Power Automate, a single flow run has a maximum duration of 30 days, and Microsoft states plainly that the duration includes flows with pending steps such as approvals, and that after 30 days any pending steps time out. Run history is retained for 30 days as well, calculated from the run start time. Microsoft's own guidance for approvals that might run longer than 30 days is to store the approvals in Dataverse and split the work across two flows, one to send the request and one to act on the response.
Two more published limits catch approval flows specifically, because approval flows are often low volume. A cloud flow whose trigger or actions fail continuously is turned off after 14 days. A cloud flow that is not triggered within a 90 day period may be turned off, with flows owned by users holding premium or capacity licences exempt, and owners notified 30 days before suspension. A quarterly approval process can therefore switch itself off between uses, and nothing tells the requester that the form still accepts submissions which now go nowhere.
None of this is an argument against flow platforms. It is an argument for knowing where the pending request is being held. If it is held as a paused step inside a run, the request has an expiry date and the record of it disappears on a schedule. If it is held as a state on the response itself, it waits as long as it waits, and a list of everything currently waiting is a filter rather than an investigation.
More than one approver, and the words people use loosely
Multi-approver designs are where requirements get written in language that does not survive contact with a tool. Three distinctions do most of the work.
Anyone versus everyone. Whether one approval is enough or all named approvers must answer. Approval actions on flow platforms expose this as an approval type, chosen when the action is configured rather than per request, so a form that needs both behaviours needs either two paths or a decision about which one is the rule.
At the same time versus one after another. Parallel requests are faster and produce awkward outcomes when the first approver rejects while the second is still reading. Sequential requests are slower and match how authority usually works, because the second approver often only wants to see requests the first one already accepted.
Who stands in. Named substitutes are the single most effective change available, and the most commonly skipped. Established finance systems treat it as core setup rather than an afterthought: in Dynamics 365 Business Central, an approval user is set up with an approver and a substitute approver, and approvers can carry amount limits that decide which records they are qualified to approve. Borrowing that shape is sensible even without those systems. Every approver has a substitute, and a request that has waited too long moves.
What to record, and for how long
Approval records get consulted at the worst possible time: an audit, a dispute, a mistake that needs tracing. What matters then is not that a decision exists but that the decision can be tied to the request as it stood when it was made.
Keep the submission unchanged and keep the decision separate from it. A decision record that is worth having names the person who decided, the time, the outcome, and the comment if any. Where a request went through more than one stage, keep each stage rather than only the final state, because the interesting question later is almost always where it paused.
Keep the internal notes in the same place as the decision. Notes that live in a chat thread are effectively gone, since nobody will reconstruct which thread discussed which request. A response history that keeps stage changes, owner changes and sent replies in one ordered list is doing the job that a mailbox pretends to do and does not, and different intake types need different amounts of it, which is what the worked examples by intake type are useful for comparing.
Set the retention deliberately rather than inheriting it. A platform that deletes run history after 30 days has decided your retention policy for you, and it decided on 30 days.
Reminding people without nagging them
Once the holding problem is solved, the remaining delay is attention. A request that is visible on a list still needs somebody to look at the list, and reminders are how that happens. The question is who gets reminded and how often.
Notification design in the established systems is more careful than most homemade versions. Power Automate sends the approval request to the address in the assigned to field, and approvers can respond from their email inbox, from the approvals centre in Power Automate, or from the mobile app, so the reminder and the decision happen in the same place. Business Central separates the notification type from the notification method and the schedule: an approval notification can be delivered by email or as an internal note, and the schedule has its own recurrence setting, which can be set to send instantly.
Those two dials, method and frequency, are the ones worth copying. Instant notification on arrival is right for the first message, because a request nobody knows about cannot be judged as urgent or not. Instant notification on every subsequent event is how people learn to filter the sender. A daily summary of what is still waiting, sent to the approver and to whoever is accountable for the queue, does more than a stream of individual alerts, because it makes the age of a request visible rather than just its existence.
Reminders should also stop. A request that has been approved, rejected, or withdrawn has no business appearing in anything, and a reminder system that keeps mentioning closed items is trained to be ignored within a fortnight.
What to change first
Write down where a pending request is held today, and who can see the list of everything currently waiting without asking anyone. If the honest answer is a mailbox and nobody, fix that before building any routing, because routing a request into a place that cannot hold it just moves the problem downstream. Seeing an approval queue with owners and stages on one screen takes a few minutes in Halict, and it is the cheapest way to find out whether holding is the piece you are missing.
Q1. Does Google Forms or Microsoft Forms include an approval step?
Neither product decides requests on its own. The approval is added around the form, either with a workflow platform such as Power Automate, an add-on, or a form tool that keeps a status and an owner on each response. That is why searches for this phrase return build tutorials rather than a settings page.
Q2. How long will an approval request sit and wait before it breaks?
It depends entirely on where the request is held. On Power Automate, a run lasts a maximum of 30 days and pending steps time out after that, with run history retained for 30 days from the start of the run. When the pending state is stored as a status on the response instead, there is no timer, and a request that has waited three months is still on the list.
Q3. What is the fastest way to cut approval delay without changing tools?
Name a substitute for every approver and agree a point at which a waiting request moves to them. Delay is usually one person being unavailable rather than the process being slow, and a substitute costs nothing to set up.
Q4. Should approvers work in email or in a separate approvals screen?
Email gets answered faster because approvers are already there, so keeping the notification in email is sensible. What should not live in email is the record of what is still waiting, because an inbox cannot tell an answered request from an unanswered one.
Q5. How should an approval be recorded for an audit later?
Keep the submitted answers unchanged, and store the decision separately with the person, the time, the outcome and any comment. Keep each stage the request passed through rather than only the final state, and check what your platform's retention period is before assuming the history will still be there.