A Microsoft Forms approval workflow is a Power Automate cloud flow with four parts: the Microsoft Forms trigger "When a new response is submitted", the action "Get response details" to read the answers, the Approvals action "Start and wait for an approval" to send the request, and a Condition that does one thing when the outcome is Approve and another when it is Reject. Microsoft Forms has no approval step of its own. The approval lives in Power Automate, and the form is only the front door.
That is the whole shape. The rest of this guide covers the exact build, which of the four approval types to pick, the limits that catch teams out after a few weeks, and the question that comes up once the flow is running: where do you see every request, who has it, and what state it is in. Connector names, approval types and limits below were checked against Microsoft Learn on October 8, 2026.
Before you build: what you need
Three things need to be in place, and each has caught teams halfway through a build.
A work or school account. The Microsoft Forms connector page on Microsoft Learn lists, under known issues and limitations, that the connector only works with organizational accounts. A form made with a personal Microsoft account cannot trigger the flow.
A license that covers standard connectors. Microsoft's "Get started with approvals" page says the Approvals connector is a standard connector, so any license that grants access to Power Automate and standard connectors is enough. It names Power Automate, Office 365, and Dynamics 365 licenses with built in Power Automate capabilities.
A Dataverse database for the environment. Approval flows are stored in Dataverse. In the default environment it is created for you. In any other environment, the first person to run an approval flow needs an administrator role there, because the database is provisioned on that first run, and Microsoft notes it can take a few minutes.
Two smaller checks save time later. If the form belongs to a Microsoft 365 group, it will not appear in the trigger's dropdown list. The connector page says to paste the Form Id manually, taking only the part after "FormId=" from the address bar while editing the form. And decide now how the flow will know who sent the request. If the form only accepts responses from people in your organisation and records names, the response carries the responder's email. If it accepts anonymous responses, add a required email question to the form.
Building the flow, step by step
The names below are what you see in the Power Automate designer. The steps are similar in the new and the classic designer.
- Create the flow. Sign in to Power Automate, select My flows, then New flow and Automated cloud flow. Name it after the form, for example "Equipment request approval".
- Choose the trigger. Search for Microsoft Forms and pick "When a new response is submitted". In Form Id, choose your form, or paste the Form Id for a group form.
- Read the answers. Add the Microsoft Forms action "Get response details". Set Form Id to the same form, and set Response Id to the Response Id from the trigger. Without this step the flow knows a response arrived but not what it says.
- Find the approver. For a manager approval, add the Office 365 Users action "Get manager (V2)" and pass it the responder's email. For a fixed approver, such as a finance mailbox owner, skip this and type the address in the next step.
- Start the approval. Add "Start and wait for an approval". Choose the approval type (see the next section). Fill Title with something an approver can scan in a list, such as "Equipment request: laptop, 1,200". Put the manager's email in Assigned to. Use Details for the answers. Microsoft's how to page says Details accepts markdown, so a short table of answers reads well in Outlook. Set Requestor to the responder's email.
- Branch on the outcome. Add a Condition. Set the left side to the Outcome output of the approval step, the operator to "is equal to", and the right side to Approve.
- Act on each branch. In the yes branch, send an approval email to the requester and record the decision. In the no branch, send a rejection email that includes the approver's comments from the Responses output.
- Test it. Use the flow's Test option, submit the form yourself, and approve from the email to see both the outcome and the follow up email arrive.
Approvers can answer from their email inbox, from the approvals center in Power Automate, or from the Power Automate app, according to Microsoft's "Create and test an approval workflow" page. They do not need to open the form.
Two habits make the flow easier to live with. Put the response number and the requester's name in the Title, so approvers can tell two similar requests apart in their list. And keep Details short: the three or four answers the approver needs to decide, followed by a link to the full response. An approver reading on a phone will skim a long block of text and may approve something they did not fully read. If the form has optional questions, test with a response that leaves them blank, because empty values can produce a Details table with gaps that look like errors.
Choosing one of the four approval types
The approval type decides when the flow continues. Microsoft's "Get started with approvals" page describes four, plus a sequential pattern.
| Approval type | Who is asked | When the flow continues | Typical use |
|---|---|---|---|
| Approve/Reject, Everyone must approve | Several approvers | After all approve, or as soon as one rejects | Policy exceptions needing joint sign off |
| Approve/Reject, First to respond | Several approvers | After any one responds | A shared team queue |
| Custom Responses, Wait for all responses | Several approvers | After all respond with your custom options | Panel scoring |
| Custom Responses, Wait for one response | One or several | After any one responds | Choosing a tier, such as a discount limit |
| Sequential approval | One at a time, in order | After the last in the sequence responds | Manager first, then finance |
First to respond is the right default for team queues. If three people cover the same request type, it lets whoever is free deal with it. Everyone must approve is stricter than it sounds: a single rejection ends the request immediately.
Custom responses are useful when Approve or Reject is not the real decision. Microsoft's example is a discount request with the options Up to 5%, Up to 10%, Up to 15% and Denied. Your Condition then checks the Outcome against each option instead of against Approve.
To send to several people, put their addresses in Assigned to, separated by semicolons.
Limits that show up after the first month
The flow works on day one. These are the rules that cause trouble later.
Pending approvals time out after 30 days. Microsoft's "Limits of automated, scheduled, and instant flows" page sets the run duration at 30 days and says this includes flows with pending steps such as approvals. After 30 days, pending steps time out. If an approver is on leave, the request quietly fails. Add a reminder or an escalation before that point, or set a deadline on your process that is well under 30 days.
Run history is kept for 30 days. The same page sets run retention to 30 days from the run's start time. If you need to know in March who approved a request in January, the flow's run history will not have it. Write each decision somewhere permanent, such as a SharePoint list or an Excel table, in both branches of the Condition.
The approval email shows the creation date in GMT. Microsoft's how to page says the Date Created field in approval emails is always GMT and cannot be changed. If approvers are in another time zone, put the local submission time in Details.
Requesters cannot reassign. An approver can reassign a request from the Approvals page in Power Automate. The person who sent it cannot. They can cancel it from the Sent tab and edit the flow to change Assigned to.
The Forms connector has a throttle. The connector page lists 300 API calls per connection per 60 seconds. A normal approval form will not reach it, but a form that receives a burst of responses after a mass email can.
Changing the trigger's concurrency setting is one way. The connector page notes that once concurrency control is enabled and then disabled, it cannot be undone in place. The documented workaround is to export the flow, remove the concurrency section from the JSON, and import it again.
Where the requests actually live
Once the flow runs for a while, the question changes from "does the approval send" to "what is the state of everything". That information is spread across several places:
- The answers are in Microsoft Forms, and in the Excel workbook if you open responses there.
- The decision is in the Approvals center, under Received for approvers and Sent for the flow owner.
- The follow up emails are in Outlook.
- The run itself is in the flow's run history, for 30 days.
For a handful of requests a week, that is fine. When a requester asks where their request has got to, someone checks the Approvals center. When a manager asks how many requests were approved last month, someone reads the SharePoint list that the flow writes to.
It gets harder when the process has more than two states. A request might need information from the requester before it can be approved, or be approved but not yet fulfilled, or be fulfilled and waiting for a receipt. Each new state means another branch, another column and another email template inside the flow, and the flow becomes the only place where the process is defined. When the person who built it moves on, that is difficult to hand over.
There are two common ways forward. One is to keep Microsoft Forms and Power Automate and make the SharePoint list the system of record, with a status column that the flow updates and a view for each state. The other is a form builder with response management, where each response already has an owner, a stage and a history on one screen, and replies are sent from the same place. Some of these tools connect to Teams, Zapier or n8n, so the approval email can still go out while the state lives with the response. The features page shows owners, stages and replies together, and the use cases page covers request and application flows of this kind.
What to change first
Add a step in both branches of the Condition that writes the decision to a permanent list, since run history disappears after 30 days. If the process already has more states than Approve and Reject, see how a request looks when owner and stage travel with the response in the Halict demo.
Q1. Does Microsoft Forms have a built in approval feature?
No setting for approvals appears in Microsoft Forms itself. Approvals are handled in Power Automate, using the Microsoft Forms trigger "When a new response is submitted" and the Approvals action "Start and wait for an approval".
Q2. Why does my Microsoft Form not appear in the Power Automate trigger?
Group forms do not show up in the dropdown list, according to the Microsoft Forms connector page. Paste the Form Id manually, using only the part after "FormId=" in the address bar while you edit the form. Also check that the form was made with a work or school account, since the connector only works with organizational accounts.
Q3. What happens if the approver never responds?
The flow waits, but Power Automate limits a single run to 30 days, including pending approvals. After that, the pending step times out. Add a reminder or escalation earlier in the process so a request is not lost.
Q4. Can a form response go to the submitter's manager automatically?
Yes. After "Get response details", use the Office 365 Users action "Get manager (V2)" with the responder's email, then put the manager's email in Assigned to on the approval step. This needs the responder's email, so the form must record it or ask for it.
Q5. Can approvers respond from Microsoft Teams instead of email?
Yes. Microsoft's how to page points to a Teams approval template, and approvers can also respond from the approvals center in Power Automate or the Power Automate app.