Power Automate Approvals - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What an approval in Power Automate actually is somewhere in your company right now. An expense report is sitting in an inbox waiting for someone to say yes. That waiting is exactly what Power Automate approvals removes your flow. Starts it asks a real human for a decision, and then it keeps running based on what that human said. You don't write code and you don't build an app because the whole thing is one step. You configure with a title, some details, and a name. The person approving doesn't even need to learn a new tool, since most people just click a button in an email, they already know how to read. It sounds simple, and the core idea really is simple, but there are honest limits that catch people out, and we're going to walk straight into those. So let's start with the plain version. An approval is a decision. Your flow asks a real person to make, and the flow stops and waits until that person answers. Microsoft describes approvals as a way to automate sign off requests and blend human decision making into a workflow, and the examples it reaches for are the ones you already recognize. Vacation time documents that need a sign off, and expense reports all show up on that list. A flow, if you're new to this, is just an automated recipe. Something happens like a form getting filled in, and that event kicks the recipe into gear. Whatever starts it is called a trigger, and every step after that is an action which is a small task. The flow performs on your behalf. An approval is one of those actions sitting in the middle of the recipe. Like any other step, the action that does the work has a name. You'll see a lot, and it's called start and wait for an approval. You give it a title, you give it some details, and you name the person or people who should decide. Then the flow genuinely waits, sometimes for days, until an answer comes back. That's the whole idea. And it's smaller than most people expect. You're not building an app and you're not writing code. You're adding one step that pauses your automation and asks a human a question, which is a very different thing from the project. Most beginners imagine approvals matter because the work around them is invisible until it's late. A form gets filled in and then it waits. Someone has to remember to chase it. Someone has to find the right person to ask, and the whole thing stalls on a human being who is busy with something else. Automating the ask doesn't remove the human decision, and it shouldn't because the decision is the point. What it removes is the chasing. There's a catch, though, and it's one almost nobody sees coming. The flow can't wait forever. And when that limit finally hits, the approval doesn't politely vanish. Hold that thought, because we'll come back to exactly what happens. How a flow asks someone for a decision. Now let's look at what's happening underneath. Still, in plain terms, a flow moves in a straight line. Something happens first. That's the trigger. And then each step runs in order until the flow reaches the end of the recipe. When your flow reaches the approval. Step three things decide what the approver sees. There's a title, which is the one line summary of the ask. There are the details which are the body of the request, and there's the assigned to field where you put the email addresses of the people who get asked. You can format those details. So the request reads like a clean note instead of a wall of text. And that matters more than it sounds. A manager who can see the amount, the date and the reason at a glance responds fast. A manager staring at a jumble of fields closes the tab and promises to come back later. Once the person responds, the answer lands in a field called the outcome, and from there your flow reads it and works out what to do next. The usual pattern is a simple condition, and it reads almost like a sentence. If the outcome is approved, do one thing. If it's reject, do another. The flow doesn't make the decision and it doesn't have an opinion about it. It carries the decision from a person to the rest of your process, which is the whole job. And it's worth remembering the next time someone worries that automation is taking over the judgment calls. One more detail matters if you care about things quietly going wrong. The basic approve and reject answers are case sensitive, so a flow hunting for the word approve won't recognize a lowercase approve, and that trips up people who write their own conditions. The built in condition builder handles it for you, which is one more reason to start there. The different ways to ask for an approval. Not every approval works the same way, and picking the right style is the first real decision you'll make. Power automate gives you a handful of standard patterns, and each one answers a slightly different question about who gets to decide. The first is everyone must approve. Every approver gets the same two buttons approve or reject, and the flow only moves on once every single person has answered one rejection ends the whole thing. Even if everyone else said yes, you reach for this one. When a decision really does need the whole group, like a committee signing off on a policy, the second is first to respond. Any one approvers answer completes the request and moves the flow along, and the rest of the group doesn't have to do a thing. This is the one people need most of the time, because usually you want somebody to sign off, not everybody. Then there are custom responses which let you replace the plain approve and reject buttons with your own list of choices. Microsoft's own example is an expense report where the approver can pick, accept, reject, or need more info. You can set custom responses to wait for one answer or to wait for all of them. So you keep the same control over who decides while changing what they're allowed to say. Custom responses earn their keep when a simple yes or no can't capture the real decision, picture a discount request where the approver chooses up to five percent, up to ten percent, up to fifteen percent or denied. That's one approval step. Doing the work of a small negotiation, and the person asking gets a clear answer instead of a vague Maybe. There's also a sequential pattern where approvers are asked one at a time in a set order. Each person has to respond before the request moves to the next name on the list, which is how most companies already escalate decisions. A common version is a small pre-approval before finance gives the final sign off on anything above a certain amount. These patterns exist as separate choices rather than one flexible setting, and there's a reason for that. Each one encodes a real world policy. Everyone must approve guards against a single person waving something through while first to respond, guards against a decision stalling because one approver is unreachable. Choosing the pattern is really choosing which risk bothers you more. Where the person clicks, approve the question that decides whether your approval works in the real world is where the approver actually clicks the button. Get that wrong, and the cleverest flow in the company still sits there waiting. Approvers have three places to respond, and the first is the one almost everyone uses. The approval arrives as an outlook email with working buttons built right in so your manager reads the request clicks, approve or reject and gets back to their day. The other two are a Microsoft Teams card and the Power Automate Action Center, and both of them handle the same job. Teams has its own native approvals app, and it's worth knowing because it changes your starting point. You can kick off an approval from the same place you send a chat or a channel message without building a flow at all, and these requests run directly on the power automate infrastructure behind the scenes. If you later want to add something before or after the approval, you can still build a flow around it. Two small conveniences make life easier for real teams. If you receive an approval and you're the wrong person to decide, you can reassign it to someone else. If you sent one and it's still unanswered, you can cancel it from the sent tab. The practical takeaway is to match the channel to where your approvers already live. If your team runs on teams, the card gets seen in minutes, and if your culture is email, the inbox is the fastest path by default. The request lands in email and you can add the teams card alongside it. One honest detail sits alongside all of that. The person who created the flow is always shown in the approval details, in the email and in every client, and Microsoft does that on purpose to stop anyone spoofing the sender an approval can't quietly pretend to come from your boss, which is a small thing that matters a lot in a company. A small example, start to finish. Let's put the pieces together with one example you could build this afternoon. An employee fills in an expense report in a SharePoint list, and that new list item is the trigger. The moment the item is saved, your flow wakes up and starts running. The flow arrives at the approval step. Sets a title like expense report for approval, drops in the details of the claim, and assigns it to the employee's manager. Then the flow waits and the manager gets an email with the request and a couple of buttons in it. The manager reads it and clicks. Suppose they choose need more info instead of a plain yes or no. The flow reads that outcome branches down the matching path and sends the employee a short note asking for the missing receipt if the manager approves. Instead, the flow sends accounting a note to reimburse the claim. If they reject it, the flow tells the employee and you can pass along the reason so nobody is left guessing why. Step back and look at the shape of it. Something triggers the flow. The flow asks. The flow waits and then the flow acts on the answer. Every approval you ever build is a variation on those four moves, no matter how complicated the business process looks from the outside. What makes this example useful to remember is how little of it is custom. You didn't invent a database, you didn't design an interface, and you didn't build a form from scratch. You pointed a flow at a list that already existed and added one approval step and wired up two or three simple branches. How this fits into Microsoft three hundred sixty five and Azure approvals don't live in a vacuum, so it's worth seeing where they sit in the wider Microsoft picture. Behind the scenes, your approvals are stored in Dataverse, which is Microsoft's data service for business apps. That's why a Dataverse database is a prerequisite, and it's why the very first approval in a brand new environment might need an admin to set that up once. Now for the reassuring part about cost. The approvals connector is a standard connector rather than a premium one, and a connector in this world is simply the piece that lets a flow talk to another service. In practice, that means a normal power automate license, an office three hundred sixty five license, or an eligible dynamics three hundred sixty five license is enough to build approval flows. You don't buy a special add on just to ask someone a question. The same approval action turns up across Microsoft's tools. You'll find it in Power Automate, PowerApps, Copilot Studio, and Microsoft Teams so you can meet it wherever you already work. One limitation is worth flagging approvals started inside teams all land in your organization's default environment today, which matters if your team keeps its work somewhere specific. The Azure Connection is simpler than it sounds. Power automate itself runs on Microsoft's cloud, and if you work in Azure, Logic Apps tackles the same kind of job in its own way. It sends an approval email through the office three hundred sixty five outlook connector, and then checks the answer with a condition so the shape stays familiar. Even though the tool underneath is different, Azure doesn't offer the same approvals connector that Power Automate does, and that's a useful thing to know before you go looking for it. There's also a boundary to be clear about. Approvals aren't a governance or compliance tool, and they won't enforce a policy on their own. They route a decision and record it, which is a narrower and more honest description of the job. If you need an audit trail with retention rules and formal controls, that's a different and much larger conversation. The limits worth knowing before you build. Remember the catch I promised at the start? Here it is. A flow that waits for an approval. Can wait twenty eight days, and if the wait runs past that, the flow fails. The approval itself doesn't disappear when that happens. And that's the part which surprises people. It stays in the action center with no flow waiting on it. So it sits there until the requester or an environment admin deletes it by hand. Builders call these abandoned approvals, and they pile up quietly in organizations that build a lot of them, it helps to understand why the limit exists at all. A flow run is a process living on a server and servers don't hold processes open indefinitely just in case someone answers an email six weeks later. The ceiling is a design choice rather than an oversight, and knowing that makes it easier to plan around instead of fighting it. There's a workaround the community leans on, though it's a workaround rather than a magic setting. You split the job into two flows, one that creates the approval and one that waits for the outcome, which lets the waits stretch far longer than a single flow run allows. It's a well-known pattern, and the good news is that it doesn't need a premium license. Guest users bring their own rules. If you assign an approval to a guest, they can't view it or act on it by default unless they hold a valid Power Automate license. Guests who never accepted their invitation get dropped from the approver list entirely. And if everyone on that list is a pending guest, the approval fails to create at all. The team's card has its own quirk to the email, and the team's card are two separate channels. So if your approver answers by email, the card and teams may still show the old status. Microsoft's fix is to switch off the default notification email when you're relying on the card, so there's only one place to look. A few smaller ones round this out. Only the first five custom responses are clickable in the outlook email. Timestamps are always shown in UTC, and you can't change that. And attachment names have to be unique or the notification won't go out. The mistakes beginners make those limits turn into a handful of very predictable mistakes, and you can dodge all of them once you know they exist. Asking everyone to approve when you really meant first to respond is the classic first mistake. It feels safer to include the whole group. So people do. And then the flow sits for days because one person is away and nobody wants to decide without them. Then there's the approval built with no plan for the rejection branch and no arrives. Nothing is wired to it and the process simply stops. Give the no somewhere to go. Even if that somewhere is just an email explaining what happened. Putting the approval where nobody looks causes a slower and quieter kind of failure. If your approvers live in teams and the request only lands in email or the reverse, you've built a delay into the process and then blame the tool for being slow. Custom responses can also bite when they meet a large group, and the everyone must approve type. Microsoft warns that combination can fail because the results field runs into a data size limit, so keep the group small or switch to first to respond. A do until loop wrapped around an approval is another trap, because a loop that doesn't handle every possible outcome can spin forever. A plain condition or a switch statement is a safer choice for this kind of work, and the Sneakiest one is hard coding a single person's name instead of a group. The day that person changes roles, your carefully built process quietly breaks and nobody notices until something important is stuck. Notice the pattern running through all six of these. Almost everyone comes from treating an approval as a checkbox, rather than as a conversation with a person who has their own schedule, their own priorities, and their own idea of what the request actually means. How to start without getting overwhelmed. Starting small is the whole trick here. Pick one boring process that repeats on a schedule and expense reports, time off or a document sign off are the classic first candidates. You want something where the pain is obvious and the steps are already clear in your head. Choose the simplest approval type to begin with. First. To respond with a single approver is enough to prove the idea, and you can always add people once it's working. If a blank canvas feels intimidating, start from one of Microsoft's approval templates and tweak it because that's exactly what the templates are for. Keep the request readable. A clear title and a few well formatted details. Let your approver decide in seconds, which is the entire point of automating this in the first place. Build the what if they say no branch on day one rather than later? Because that's the branch people forget. And when a request is genuinely urgent, send a reminder through the channel your approver already watches instead of introducing a second tool for them to check. There's one more habit worth building. Test the flow yourself before you unleash it on a colleague and put your own address in the assigned to field. You'll spot the confusing title, the missing detail, and the broken branch in five minutes, rather than hearing about them later from a manager who is already annoyed. A quick recap and a question for you. So that's the short version of everything we covered. And approval is just a flow. Pausing to ask a human a question, and the action behind it is called start and wait for an approval. You choose who gets asked and what choices they see, and they answer from an email, a team's card, or the action center. You can start with one simple step, and the honest limits to remember are the roughly month long wait, the guest user rules, and the teams card that can fall out of sync. Here's my question for you. What's the one approval in your job that eats the most time every week? And would you hand it to a flow tomorrow if this made the topic feel less intimidating? Subscribe to M365 FM to master the tools and the mindset shaping the future of work.