A form goes out, responses land in Microsoft Forms, and somebody has to say yes or no to each one. Budget requests, leave requests, event places, supplier applications, expense claims. For the first dozen the routing happens by hand: open the response, forward it to whoever decides, wait, chase, then type the answer into a column so it is not lost. Somewhere past the first dozen that stops working, and the search for an approval workflow starts.
Power Automate is the built in answer inside Microsoft 365, and it does the job. It also has a set of conditions that are easy to miss until the flow refuses to save or refuses to run. What follows is the shape of the build, the choices that matter, and the parts that tend to go wrong after it is live.
What the manual version is really costing
Naming the failure points first makes it clearer which of them a flow will fix and which it will not.
The request gets lost. A forwarded response is one message in an inbox that already has two hundred. There is no list of what is outstanding, so the only way to find out is to ask.
The decision lives in one thread. When the approver replies "fine by me", that sentence exists in two mailboxes and nowhere else. Three months later, when somebody asks who approved it, the answer depends on whether either person still has the thread.
The person who submitted hears nothing. The decision is made, recorded, and never sent back. This is the one that generates follow up messages, and it is also the one automation is least likely to fix on its own, because sending the reply is a separate step that has to be built deliberately.
An approval workflow fixes the first two by default. The third is only fixed if the flow is built to send something at the end.
The three pieces the flow is built from
A Microsoft Forms approval workflow is shorter than most people expect. Three actions carry the whole thing.
The trigger
The Microsoft Forms connector provides When a new response is submitted. It fires on submission rather than polling. Worth knowing before you build: the trigger payload does not contain the answers. Per the connector reference, it returns a Response Id and nothing more. Everything else has to be fetched.
Get response details
This is the second action, and it is the one people forget. It takes the Form Id and the Response Id from the trigger, and returns the actual answers as fields you can drop into the rest of the flow. Without it there is nothing to put in the approval request except an identifier.
Start and wait for an approval
The Approvals connector provides Start and wait for an approval. The flow pauses at this action until the approvers respond, then carries on with the outcome and any comments available to later steps. Microsoft documents the whole pattern in Get started with approvals.
Approvers do not have to log into Power Automate to answer. They can respond from the email they receive, from the approvals centre in Power Automate, or from the Power Automate mobile app. For occasional approvers who will never open the tool, the email route is what makes this workable at all.
After the approval action, most builds add a condition on the outcome, then a branch that writes the result somewhere and sends the applicant an email. That last part is optional in the software and not optional in practice.
Pick the approval type before you build
There are five types, and swapping between them later means reworking the branches underneath. Choose deliberately.
| Approval type | How it completes |
|---|---|
| Approve/Reject, everyone must approve | Every approver must answer, or one rejection ends it |
| Approve/Reject, first to respond | The first answer from any approver decides it |
| Custom responses, wait for all responses | You define the options, and every approver must answer |
| Custom responses, wait for one response | You define the options, and one answer ends it |
| Sequential approval | Requests go out one at a time, in order, each waiting on the last |
Two of these are worth extra thought.
First to respond is the right default for most intake work. When three people can approve a training request and any one of them is enough, requiring all three guarantees the request sits waiting on whoever is on holiday.
Custom responses matter when the real world answer is not binary. An event application is often not approved or rejected but approved, waitlisted, or asked for more information. Forcing that into Approve and Reject means the middle case leaves the flow and goes back to being an email, which is exactly what the build was meant to stop.
Sequential approval covers the case where a second signature is only needed above a threshold. Microsoft's own example is invoices over a set amount going to Finance after a pre-approval. If your form has a cost field, that is where to use it.
What has to be true before the first run
Four conditions catch people out, and none of them are obvious from inside the designer.
The Forms connector needs a work or school account. The connector documentation states plainly that it only works with organizational accounts. A form built on a personal Microsoft account cannot be the trigger for a flow, no matter what licence sits on the Power Automate side. If the form is currently on a personal account, it has to be rebuilt on the organizational one before any of this applies.
Approvals need Dataverse. Approval flows are stored in Dataverse, not in the flow itself. In the default environment the database is provisioned automatically the first time an approval flow runs. In any other environment, the user who runs that first flow needs an administrator role in the environment, and provisioning takes a few minutes. This is why the first run in a new environment sometimes appears to hang and then works fine afterwards.
The licence question is narrower than it looks. The approvals connector is a standard connector, so any licence that grants Power Automate use of standard connectors is enough to build this. The Microsoft Forms connector is also classed as standard. Power Automate Premium is listed at $15.00 per user per month paid yearly, and it becomes relevant when the flow needs premium or custom connectors, not for approvals on their own.
Group forms behave differently. Forms owned by a group do not appear in the connector's dropdown list. The Form Id has to be pasted in by hand, taken from the address bar while editing the form, using only the part after FormId=. Plenty of flows that "cannot see the form" are group forms.
One more number worth keeping: the Forms connector allows 300 API calls per connection per 60 seconds. That is generous for approvals and tight for anything that loops over historic responses.
Where these flows break after they are live
The build is the easy part. The failure modes show up later.
The form changes and the flow does not. Add a question, rename an existing one, and the dynamic fields the flow was mapped to can stop resolving. Nothing warns you at the moment of the edit. The failure appears on the next submission, as an approval email with blank fields. Any change to a form that feeds a flow needs a test submission immediately afterwards.
Ownership sits with one person. A flow built in an individual account stops when that account is disabled. Moving approval flows into a shared solution or adding co-owners is a five minute job that gets skipped every time.
There is no queue anybody can see. The approvals centre shows each approver what is waiting on them. It does not give the person who runs the process a view of every request and where it stands. That view usually ends up rebuilt by hand in a SharePoint list or a spreadsheet the flow writes to, which is a second system to maintain.
The applicant still hears nothing. If the branch that emails the submitter was never added, or was added only to the approved path, half of the original problem survives the automation. Check the rejected branch specifically.
Nobody tests the unhappy paths. Most flows are tested once, with a clean submission that gets approved. The paths that matter later are the ones nobody exercised: a rejection, a submission with an optional question left blank, a file upload that is larger than expected, an approver who never answers. Running four test submissions covering those cases at build time costs half an hour and catches most of what would otherwise surface in front of a real applicant.
The trail is thinner than it looks. The approval record holds the outcome and the approver's comments. It does not hold the conversation that happened around the decision, the attachment somebody sent separately, or the reason a request was re-sent. Teams that need to answer "why was this one handled differently" six months later usually end up keeping notes somewhere else, which is one more place for the record to drift out of step.
Flow or list: two shapes of the same job
Power Automate builds a pipeline. Some tools instead give each response a status and an owner and keep the decision next to the response. The two are not interchangeable, and the choice depends on what the approval is embedded in.
| Forms with a Power Automate approval | A form tool with response management | |
|---|---|---|
| Where the decision is recorded | In Dataverse, surfaced through the flow | On the response itself |
| What approvers use | Email, approvals centre, or mobile app | The response list |
| Visible queue for the process owner | Built separately | Included |
| Reply to the submitter | An action you add | Sent from the same screen |
| Account requirement | Organizational Microsoft account | An account with the tool |
| Connects to other systems | More than 200 services | Varies by tool |
A flow wins when the approval has to touch systems outside the form: post to Teams, update a SharePoint list, create a record in Dynamics, file something in a document library. That breadth is the reason Power Automate exists, and no form tool matches it.
A response list wins when the approval is the whole job, and what you actually want is to see every application, know who owns it, know what stage it is at, and answer it. In that case a flow adds a second place where state lives, and state in two places drifts. Tools built around that shape, such as the ones described in these use cases, keep the stage, the owner and the reply on one screen, which is the part a flow leaves to you to assemble.
Cost shapes the choice as well. Approval flows are priced per user of the automation platform, so they scale with how many people build and run flows. Some form tools are priced only by how many people use the workspace, with no cap on forms or responses, which is a different curve entirely once volume rises. The pricing page of whatever you are comparing against is worth reading next to the Power Automate figures above.
What to change first
Build the flow with first to respond and custom responses if the real answer is ever anything other than yes or no, and add the email back to the submitter before you call it finished. Then check whether you also need a queue, because that is the piece Power Automate will not hand you. If the queue is the thing you actually needed, see how Halict holds that queue on a demo form before building a second system to hold it.
Q1. Can a Microsoft Forms approval flow run on a personal Microsoft account?
No. The Microsoft Forms connector documentation states that it only works with organizational accounts. A form created on a personal Microsoft account cannot be used as a Power Automate trigger. The form has to be recreated under a work or school account first.
Q2. Why is the approval email arriving with blank fields?
Usually because the flow is missing the Get response details action, or because a question on the form was renamed or removed after the flow was built. The trigger only returns a Response Id, so the answers must be fetched with a second action before they can be used in the approval request.
Q3. Do approvers need a Power Automate licence to approve something?
Approvers respond to the request rather than build it. They can answer from the email they receive, from the approvals centre in Power Automate, or from the Power Automate mobile app. The licence that matters is the one held by the person who creates and owns the flow.
Q4. Why does the form not appear in the connector's dropdown list?
Group forms do not show up in that list. The Form Id has to be entered manually, taken from the address bar while editing the form, using only the portion that follows FormId=.
Q5. Can the flow send a different reply depending on the decision?
Yes. Add a condition on the approval outcome and put a separate email action on each branch. The common mistake is building the approved branch and leaving the rejected branch empty, which means half the submitters never hear anything.
Q6. What happens to running approvals if the flow owner leaves?
A flow owned by a single account stops working when that account is disabled, and approvals waiting on it are stranded. Adding co-owners, or moving the flow into a shared solution, prevents this and takes only a few minutes.