A client approval in Power Automate can go missing just before the decision or just after it. Sometimes the request sits unanswered and nobody is chasing it. Other times the partner approves, and the next person's task quietly fails. The Start and wait for an approval action does its own part well, and Microsoft's own tutorial writes the approver's decision back to a SharePoint list. What it doesn't give you on its own is one place where anyone on the team can see who has a request right now, and whether the work after the decision got done. For a practice, that gap looks like a new client waiting on an engagement letter nobody knows is stuck.
One approval, three separate events
The request goes out first, by email by default and optionally as a card in Teams. Someone decides. Then the next step runs, whether that's creating the client folder or sending the engagement letter. Each of those can fail without the others noticing. Microsoft is precise about the middle part: a flow using Start and wait for an approval sends the request, then holds until the approvers respond before the run can finish.
A sent request proves very little, and a recorded decision proves only that someone decided. What your team needs to know is whether the next task happened, and who to ask when it didn't.
Start with Microsoft's own pattern
You probably don't need custom code for this. The native pattern covers most of it: a SharePoint list holds the request, a flow starts when a new item lands on it, Start and wait for an approval asks the right person, and a Condition on the outcome decides what happens next. Microsoft's tutorial is built the same way. Before building anything, check whether your practice software or an existing template already handles the approval.
Two choices in that pattern matter more than they look. The first is the approval type. Microsoft offers Approve/Reject as First to respond or as Everyone must approve. If either of two partners can approve, put both names on the request and use First to respond, so one person's week off doesn't stall it. Save Everyone must approve for decisions that need every signature.
The second is the reject branch, which deserves as much care as the approve branch. When a partner says no, mark the row Rejected and tell the requester why. Nothing downstream should run. Make sure nothing anywhere treats no answer as a yes, either. A request that times out is a request nobody decided, and the list should say exactly that.
One list that answers "who has it?"
Run history is a poor place to look up a client's request. A SharePoint list is a good one, and if you already keep an intake list, add columns to it instead of starting another. This is the minimum we'd put on each row:
- The request or item ID your team already uses
- A named owner for the process, plus the approver
- A business due date
- Status: waiting, approved, rejected, overdue or failed
- When the decision was made, and the approver's comments
- What happened at the next step, and when
These columns are our suggestion rather than anything Microsoft prescribes, and none of them acts on its own. A due date column won't chase anybody. Only a flow that reads it will. Keep the approval request itself thin, too: a client name and a link to the row is enough, and the full intake form doesn't belong on a card in a busy Teams channel.
Why the Teams card can be wrong
By default, every approval flow emails the approver, and you can also send the approval to Teams as an adaptive card. Approvers can answer in the approvals center in Power Automate as well. Microsoft documents the catch: when the approver responds by email or in the approvals center, the card in Teams doesn't update. The card and the flow can disagree about whether the request is still waiting.
Picture a partner approving from Outlook at 7:40 in the morning while the card in your intake channel still asks for a decision. Somebody spends the afternoon chasing a yes that already happened. Tell the team the list is the record and the card is only a notification. Microsoft's own fix is to turn off the default approval email, but that takes the email away, and some approvers will only ever answer from their inbox. For most practices we'd keep the email and point everyone at the list.
Set a deadline before Microsoft sets one for you
Microsoft's documentation gives two different numbers here. On the approvals known-issues page, an approval flow can wait for 28 days and fails if the wait runs longer. The general limits page counts pending steps like approvals in a run's duration and times them out after 30 days. We wouldn't design around either one.
No client should wait four weeks for a yes.
Agree on a business deadline with whoever owns the process. Two business days is a sensible starting point for a new-client approval; that's our suggestion, and Microsoft sets no such default. Then build the check. A scheduled flow that runs each morning can mark any row still waiting past its due date as overdue and send it to the owner, who decides whether to chase the approver or ask the backup to answer.
When a flow does hit the platform limit, Microsoft notes that the approval itself stays in the approvals center with no flow waiting on it. Those abandoned approvals have to be deleted by hand, by the requestor or an environment admin. Record the outcome on the row before anyone deletes anything, so the history of who asked, and who never answered, survives.
If a request really needs longer than one run allows, Microsoft points to a different design: store approvals in Dataverse so a separate flow can act on the response after the original run times out. That's a bigger build with its own access and licensing questions. Most client-intake approvals shouldn't need it.
Send every failure to a person
Microsoft's error-handling guidance is direct. Use Run after settings to decide what happens when an action fails, times out, is skipped or succeeds, and record error details in a SharePoint list or similar before alerting the people who need to know. For a client approval, put that branch after the approval and after every step that follows it. It should write what happened to the request's row and notify a named person. Send it to a shared inbox and everyone will assume someone else has it.
Before anyone resubmits a failed run, look at the row. If the partner already approved and only the folder step failed, rerunning the whole flow can send her the same request again. Finish the failed step instead, by fixing it or doing it by hand, and note on the row what you did.
Write the manual path down while you're at it. If the flow is switched off or broken, someone still needs to know who approves and where that decision gets recorded. A short note in the list's description covers it.
What you need, and five tests before you rely on it
You'll need a Power Automate license that includes standard connectors. Microsoft says that's enough to build approval flows, because the approvals connector is a standard one. Add a SharePoint Online list your team can reach, plus the Office 365 Outlook and Office 365 Users connections Microsoft's tutorial uses. Approvals are stored in Dataverse. In a non-default environment, the first approval flow provisions that database, and Microsoft says the person who runs it needs an administrator role in the environment; after that, other people building approval flows don't need an admin role. Check your data loss prevention policies and any premium connector you plan to use after the decision, because a standard approvals connector doesn't make the rest of the flow free.
Keep approvers internal to start. Microsoft notes that a guest who hasn't accepted your tenant invitation is dropped from the approver list, and if every approver is in that state, the approval isn't created at all. We checked all of this against Microsoft's documentation on October 20, 2026. None of it is a new feature. Once it's built, run five tests on dummy requests before a real client goes through:
- Approve a request from Outlook. Check the row for the decision and comments, and confirm the next step ran.
- Reject one. The row should say Rejected, and nothing downstream should run.
- Leave one unanswered past its due date. The morning check should flag it to the owner, and nothing should treat the silence as approval.
- Approve one by email while someone watches the Teams card, and make sure your team goes to the list for the answer.
- Break the next step on purpose, for example by pointing it at a folder the flow's account can't reach. The failure should land on the row and with a named person, without anyone opening the run history.
If you already run an approval flow, start with test five. It shows you whether a failure reaches a person or just sits in the run history.