Power Automate
Automating approvals in Microsoft Teams
Approvals are where Microsoft Teams automation stops feeling cute and starts touching money, access, and reputation. I have seen a three-person approval finish in eleven minutes. I have also seen a “quick yes” sit for nine days because the only approver was on leave and nobody configured coverage.
I am Priya Shah. This article is about designing approval flows that people trust. It is educational, based on work I do with Teams and Power Automate. I am not affiliated with Microsoft, and I am not asking you to buy anything. If a decision needs human judgment, keep a human in the loop on purpose.
Approvals app versus chat prompts
Teams can surface approvals through the Approvals experience and through chat or channel messages that carry Adaptive Cards. Both can work. They solve different social problems.
The Approvals app gives people a place to find pending items later. That matters when someone was in meetings all day and missed the card in a busy channel. Chat or channel cards are visible in context, which helps when the approval is about a specific conversation or file sitting right there.
I usually pair them in thinking even if I only build one surface. Ask: if the card scrolls away, can the approver still find the request? If the answer is no, you need a durable queue, not only a message.
Chat approvals also create peer pressure. Sometimes that speeds honest decisions. Sometimes it pushes people to click Approve because the whole channel is watching. For sensitive topics, prefer a private approval path.
Sequential versus parallel routing
Sequential means one person after another. Finance after manager. Security after finance. Use sequential when later approvers need the earlier decision, or when policy says a chain of custody matters.
Parallel means several people get the request at once. Use parallel when any one of two leads can sign off, or when you need two independent checks and waiting in a line only adds delay.
A hybrid shows up often: parallel among peers, then a final sequential gate. Example: either regional lead can approve the spend estimate, then a controller must approve before purchase. Write that logic down before you click through the designer. Approval graphs are easy to sketch on paper and easy to tangle in software.
Failure mode for sequential: one missing person blocks everyone. Failure mode for parallel: you thought you needed all approvers, but the flow was set to first response, and a junior click closed the case. Read the completion rule twice. First to respond, wait for all, wait for a percentage. Those settings change outcomes more than the pretty card design.
Timeouts, reminders, and what happens when nobody answers
Every approval needs a timeout plan. Not because people are lazy. Because calendars collide with life. Set a reminder cadence that matches the urgency. A content publish approval might remind after one business day. An emergency access request might remind after an hour and escalate after three.
Decide what timeout means. Does the request reject? Escalate to a backup? Return to the requester with instructions? “Expire quietly” is usually the worst option, because the requester assumes silence means progress.
I annotate timeout behavior in the card body itself. “If no response in 48 business hours, this request escalates to the ops on-call list.” People behave better when the rules are visible in the same place as the buttons.
Also align timeout with business hours if your tool allows it. A weekend countdown that rejects a Monday-morning request will train requesters to hate the system.
Audit trails you can defend later
If an approval matters, someone will ask who approved it and when. Build for that question on day one. Store the request payload, the approver identity, timestamps, comments, and the final outcome in a SharePoint list or another system of record your retention policy covers.
Do not rely on channel history alone. Channels get reorganized. Messages get deleted by users who think they are cleaning up. Run history in Power Automate helps administrators, but business stakeholders often cannot read it, and retention settings may not match your compliance needs.
Include a request ID in the card and in the channel confirmation. When finance asks about “that thing from last month,” you want a searchable ID, not a vibe.
I worked with a program team that could not prove whether a vendor discount had been approved. The chat card was gone. The flow run had been cleaned up. They rebuilt the process with a list that stored every decision. The next audit took minutes instead of a panicked week.
Vacation coverage without breaking the chain
Out-of-office is predictable. Your flow should treat it as normal. Options include delegate settings where your platform supports them, a backup approver field on the request, or an escalation path to a role mailbox monitored by a duty person.
What does not work: hoping the primary approver set Teams status to away and that everyone notices. Status is not a workflow engine.
Ask managers to maintain a simple coverage roster for approval roles. Update it when people rotate. Your flow can read that roster from a list. Yes, someone has to keep the list honest. That small human chore beats frozen work every summer.
Test coverage. Submit a request while the primary is simulated as unavailable. Confirm the backup receives it. Confirm the audit log shows the backup, not a ghost. I have seen flows “succeed” by auto-approving when the assigned user was invalid. That is not coverage. That is a hole.
Content publish example, step by step
Here is a concrete pattern for publishing a blog post, release note, or customer email draft that needs review.
The requester submits a form or posts a message with a link to the draft, the target audience, the publish time, and a risk note if anything is sensitive. A flow creates an approval for an editor. If approved, a second approval goes to a channel owner or communications lead. If either rejects, the requester gets the comments and a link back to the draft. If both approve, the flow posts a “cleared to publish” message to a private ops channel and writes the decision to the audit list. A human still presses the actual publish button in the content tool unless your organization has a separate controlled release system.
Why keep the final publish human? Because approval of a draft is not the same as confirming the correct version went live, the right site was selected, or a last-minute legal edit landed. Automate the routing. Do not pretend the bot understands nuance.
Timeout for this example might be two business days at each stage, with a reminder at twenty-four hours, escalating to a backup editor. Parallel review is tempting for speed, but sequential editor-then-owner often catches tone issues before leadership sees them.
Card copy that helps people decide
Approvers skim. Write the card like a briefing, not a novel. Lead with what is being asked, the amount or scope, the due impact if delayed, and a link to the artifact. Put policy references below the fold. If the approver must open five tabs to understand the request, they will either delay or guess.
I ask requesters to include a one-line risk note. “Customer-facing. Contains pricing.” That sentence changes how carefully someone reads. Without it, a routine-looking request can hide a sensitive publish.
Buttons should be boring and precise. Approve, Reject, and Request changes beat cute labels. If you add Request changes, make sure the flow returns comments to the requester and keeps the audit trail connected to the same request ID.
What you should not automate
Do not automate final judgment on exceptions that need empathy or context a form cannot capture. Do not auto-approve because a request is “similar to last time.” Do not hide a reject reason from the requester if your culture expects coaching. Do not let a flow delete content because an approval expired.
Be careful with approvals that grant access to data. Pair them with joiner-mover-leaver processes and periodic access reviews. An approved access request is a moment in time. Access itself lingers.
Also avoid building so many approval steps that people rubber-stamp to survive. If everything needs four yeses, nothing is actually reviewed. Shorten the chain or split request types by risk.
A useful test: would you be comfortable explaining this approval design to a skeptical auditor and to a tired employee on the same afternoon? If only one audience would accept it, keep designing.
I also refuse flows that approve by default when an email address is missing or a user lookup fails. Fail closed for access and money. Fail loud for content publishing. Quiet success on bad input is how broken identity data becomes a security story.
Teach requesters that rejection is information. A good reject comment shortens the next submission. If your cards only support a yes path, people will approve weak requests just to keep work moving. That is a design failure, not a character failure.
Approvals in Microsoft Teams work best when they are visible, time-bounded, covered during leave, and recorded somewhere durable. Use the Approvals app when you need a queue. Use contextual cards when the conversation is the point. Choose sequential or parallel on purpose. Set timeouts that escalate instead of vanishing. And leave human judgment with humans, especially when the stakes are content, access, or money.