A Teams Approval Workflow with Power Automate

A purchase request, a quote to sign off, a leave request, an expense claim. Today it goes out by email, someone replies "ok" from their phone, and three months later nobody knows who said yes, or on which version of the quote. The process exists, but it lives in inboxes.

A Teams approval workflow changes that without changing anyone's habits: the request lands where your teams already spend their day, the answer takes one click, and everything is recorded. Here is how we build it with Power Automate, and the details that separate a workflow people use from one they work around.

How a Teams approval workflow actually works

The heart of it is Power Automate approvals. The flow contains a "start and wait for an approval" action. The approver receives a card in Teams, plus an email copy, with the request details, an Approve button, a Reject button and a comment field. The flow waits for the answer, then carries on.

Three shapes exist: first to respond decides, everyone must approve, or custom responses such as "Approve", "Send back for details" and "Reject". That third shape is the one we use most, because a flat rejection is rarely the right answer to an incomplete request.

The request itself is born in a form: Microsoft Forms for the simplest cases, a small Power Apps screen as soon as you need proper dropdowns or an attachment. It is saved to a SharePoint list or a Dataverse table, and that creation is what triggers the flow.

Routing by amount and department without freezing the flow

First classic mistake: hard-coding the rules inside the flow. If Marie approves technical purchases up to a certain amount and Marie leaves, someone has to reopen the flow. We do it differently: an "Approval rules" list with department, threshold, approver and deputy. The flow reads that table for every request.

A common example for purchases: under 500 euros, the department head; between 500 and 5,000 euros, the department head then the finance director; above that, the managing director joins, in sequence. When a threshold or a person changes, you edit a row, not a flow. That is exactly the logic behind our Purchase request and approval template.

Delegation, automatic reminders, and when nobody answers

Delegation works on two levels. An approver can reassign a request from the Approvals app in Teams, which is fine for a one-off. For absences, we rely on the deputy in the rules table plus an out-of-office indicator: if the approver is flagged as away, the flow routes straight to the deputy.

Reminders have to be built; Power Automate does not nag on its own. Two ways: a parallel branch that waits two working days then posts a Teams message, or a timeout on the approval action itself. Keep in mind that a flow run cannot wait forever; the limit is in the region of thirty days.

Then the case everyone forgets: nobody answers. Decide it up front. After two reminders, escalate to the line manager. After a delay you set, the request moves to "Expired" and the requester is told so they can resubmit. A request with no possible outcome is the number one reason a workflow gets abandoned.

Audit trail: what you keep and where you keep it

Approvals store their data in your environment's Dataverse, but that history is not designed to be browsed two years from now. So we copy what matters into your list or table: who answered, when, which answer, which comment, and against which version of the request. The day of an audit or a dispute with a supplier, you pull up the full chain in ten seconds.

SharePoint or Dataverse? SharePoint is enough for one workflow, one team and a few hundred requests a year, with no extra licence. Dataverse becomes necessary when you run several workflows, need fine-grained permissions by role, see volumes climbing and want native auditing. It requires a Premium licence per user; we cover this in detail in our article on Power Platform licensing.

To get started, pick a single workflow, the one generating the most emails today. List the approvers, the thresholds and the acceptable delay. Our method begins with that mapping before anything is built, and the workflow is then delivered for a fixed sum agreed at the end of scoping.