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 an approval that is recorded but not thought through is worse than a manual one, since it now carries the appearance of rigour.
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.
What the action does not do is validate the request. If a submitter can raise a request without a supporting document, a cost centre or a stated amount, the flow will route it anyway. 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:
- First to respond sent to group 1 and group 2 — at least one user from either group must approve.
- 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, and SCSB has seen this misreading survive into production because the flow ran and produced an approval record.
Three documented limitations shape the design further. Only mail-enabled Microsoft 365 groups and security groups are supported. Microsoft Teams notifications are not supported for group approvals — they are sent only for approvals assigned to individual users, so an organisation that has trained its people to work from Microsoft Teams will find group approvals arriving somewhere else. 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 wants a user-cancellable request has therefore made an architectural choice at the point it selected an action, not a configuration choice it can revisit later. 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. The connection credentials matter more than teams expect: a flow authenticated as a departing employee stops working, or keeps working under an identity that no longer should exist.
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 automation is the right answer and the broader platform scope is in question, that is addressed under SCSB's 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.