When an organisation asks SCSB to automate an approval, the request is almost always framed as a build: route this document to that manager. SCSB's first response is to slow that down by one step, because Microsoft Power Automate will faithfully automate a control that was never properly defined — and recording a response does not establish that the right person approved a complete request.
The platform can route a request and record a response. It cannot decide who should hold authority, whether a request is complete, or what evidence the organisation needs to retain. Those are the organisation's decisions, and they should be made before the first action is added to a flow.
What the approval action actually does
Microsoft's approval workflow guidance describes adding the Approvals — Start and wait for an approval action to any flow. Once added, the flow can manage the approval of documents or processes: Microsoft cites document approval flows for invoices, work orders and sales quotations, and process approval flows for vacation requests, overtime work and travel plans.
Approvers can respond from their email inbox, from the approvals centre in Microsoft Power Automate, or from the Microsoft Power Automate app. Microsoft also notes that on modern email clients the request email is updated automatically once the approval is completed, so an approver revisiting an old message is not left guessing whether a response is still needed.
The approval action does not define the organisation’s completeness rules. Build validation into the source or flow before the request is sent. SCSB's practice is to fix the completeness rule at the trigger — required fields on the source record — rather than rely on an approver to notice what is missing at the point of decision.
Approval type is a control decision, not a formatting choice
The Approval type field is where the control is really set, and it is routinely chosen without much thought. The two most consequential options are first to respond and everyone must respond; Microsoft also supports custom response values, so an organisation is not confined to approve and reject where its policy genuinely has a third outcome such as return for amendment.
Before that field is set, SCSB asks an organisation to document the policy the automation is meant to operate:
- the request type, and the information required before a submission is valid;
- who holds authority, and at what limits;
- what separation of duties is required — in particular whether a submitter may ever approve their own request;
- how delegation works when an approver is absent;
- what happens on rejection, and whether a resubmission is a new request or an amendment to the original;
- what cancellation means for the underlying business document;
- who owns the retention of the resulting record.
Where that policy does not exist in writing, the automation project has just uncovered a control gap. SCSB's view is that this is a useful finding rather than a delay, and that automating over the gap is the one option that should be rejected outright.
Group approvals change what "approved" means
Sending an approval to a group is convenient and quietly changes the control. Microsoft's group-approval documentation is explicit: only a single user from the group needs to respond, and that user's response is used to represent the entire group.
Combining groups and individuals compounds this. Microsoft sets out the expected outcomes:
- For Approve/reject – First to respond, the first response from either group determines the outcome. Test rejection as well as approval; this is not a rule that waits until somebody approves.
- Everyone must respond sent to group 1 and group 2 — at least one user from both groups must approve.
- Everyone must respond sent to user 1 and group 1 — user 1 and at least one member of group 1 must approve.
So "everyone must respond" does not mean every member of a group responds. It means one member from each addressed group. Where a policy genuinely requires two named individuals to approve, addressing a group of four does not implement that policy. A successful flow run can therefore conceal a mismatch between the configured approval route and the written policy.
Three documented limitations shape the design further. Only mail-enabled Microsoft 365 groups and security groups are supported. Group approvals do not generate Teams notifications, although members can view them in the Approvals app in Teams. Teams notifications are sent only for approvals assigned to individual users. Make the notification and review route clear to users. And the group must allow email from external senders to receive the notification at all.
The 30-day boundary that reshapes the design
This is the constraint SCSB raises earliest, because discovering it late means rebuilding rather than adjusting.
Microsoft advises that if a flow might run for more than 30 days, the approvals should be stored in Microsoft Dataverse, using two flows rather than one: the first sends the approval request, and the second runs the business logic on the responses. That second pattern is built on the Create an approval (v2) action, and it allows the organisation to act on a response even after the original flow run has timed out.
A single "start and wait" flow is therefore appropriate for approvals that complete in days. It is the wrong shape for a capital request that sits with a board, an approval that pauses over a long shutdown, or anything routed to a person who may be away for an extended period. Any of these can quietly exceed the window, and the resulting failure is not a rejection — the run simply ends, which is a materially different thing for an organisation trying to evidence what happened.
Cancellation depends on which action was used
Requests do get raised in error, or become irrelevant before a decision. Microsoft documents that the sender can cancel a request from the Approvals area, on the Sent tab, and that cancelled requests remain visible on the History tab.
The detail that determines whether this is available is easy to miss: Microsoft states that the cancel feature is supported on the Create an approval (v2) action. An organisation that needs user cancellation should test the chosen approval action and user experience, including the effect on the flow and underlying business record. A statement that one action supports cancellation does not establish that every other pattern lacks it. SCSB treats cancellation as a requirement to establish during design for exactly that reason.
Approvers outside the organisation
Approval requests can be sent to people outside the tenant. Microsoft documents doing this through guest accounts in Microsoft Entra ID, inviting users from other tenants as guests, and notes that assigning a role to a guest is what gives that guest the permission required to participate in the approval process.
This is worth handling deliberately rather than incidentally. An external approver — an adviser, a joint-venture partner, a client representative — is being granted a role in the tenant, and both the identity and the retention of what they can see belong in the governance decision rather than in the flow build.
A practical test set before production
- Submit a complete request and confirm it follows the normal route.
- Submit a request above an authority threshold, and confirm it escalates rather than settling at the wrong level.
- Attempt to submit an incomplete request, and confirm it is stopped at the trigger.
- Reject and resubmit, preserving a clear record of what changed between the two.
- Test an unavailable approver, then a delegated one.
- Test a group approval and confirm the number of responses actually required matches the written policy.
- Cancel a request and confirm both the resulting status and that users understand it.
- Reconcile the approval record against the underlying business document where an integration is in scope.
Ownership after go-live
Named owners are needed for the policy, the flow, the access roles, the connection credentials, the change route and the periodic review. Review every connection when an owner changes role or leaves. Adding a new flow owner does not itself establish that the connection, permissions and licensing have been transferred correctly; test those dependencies before the handover is accepted.
Retain enough evidence for the organisation to establish who approved what, on the basis of which record, and whether the workflow behaved as intended. The appropriate retention period and assurance requirements depend on the organisation and are for its own responsible owners and advisers to determine.
Some approvals should not be automated at all. Where a control runs a few times a year, or turns on judgement an approver exercises with the requester in the room, a signed record and a clear policy may serve better than a flow that nobody maintains. SCSB will say so where that is the honest answer. Where an approval workflow needs an agreed design, build, exception tests and handover, discuss SCSB’s Power Platform & AI Automation service. Tenant, identity and collaboration prerequisites can be considered through the Microsoft 365 implementation service.
General-information limitation
This article is general technology information about Microsoft Power Automate approval capabilities. It is not control, assurance, audit or legal advice, and it does not state that a particular workflow is suitable for a regulated, financial or audit purpose, nor that any approval record satisfies a specific requirement. Platform behaviour and documented limits are set by Microsoft and change over time. Confirm the current position against Microsoft's published material.
Microsoft, Microsoft 365, Microsoft Dataverse, Microsoft Entra ID, Microsoft Power Automate and Microsoft Teams are trademarks of the Microsoft group of companies.