Microsoft put the approver on the exception path
Microsoft's September 3 post previewing PPCC 2026 uses a procurement process as its example of an intelligent business process. An employee starts with a request in Copilot. An agent gathers the relevant supplier information and purchasing policies. The application applies the data model, permissions, and approval rules, and a workflow routes the request and handles the routine steps. Then comes the sentence we care about: "Higher-risk exceptions go to the right person for review."
That sentence describes a process in which most requests never wait for a person. The human approval in Microsoft's example sits on the exception path and nowhere else. Most tenants we have seen never made that decision. They lifted the approval off the old paper form, dropped it into a flow, and kept it on every request. When the agent arrives, the sponsor asks why the pilot is slower than the form, and the honest answer is that the person was always the slow part.
An approval earns its place when the approver can say no
Here is the test we would put to every approval action in a flow before an agent is allowed near it. Can the approver reject the request and make the rejection stick? Do they know something the agent could not have gathered? Will their name sit on the record afterwards? Three yeses make the step a control. One no makes it a delay with a signature on it.
The usual failure is easy to recognise. A cost centre manager gets forty approval cards on a Friday afternoon, each for a purchase under the team's normal threshold, each from a requester she trusts. She approves all forty by five o'clock without opening one. Every request passed through a person, none was reviewed, and the run history shows a clean approval on each.
Now take the request Microsoft's example routes to a person, and give it the detail the post leaves out. The supplier is not on the approved list, the requester has marked it urgent, and the agent has pulled the policy line that says new suppliers complete a security questionnaire first. The manager remembers that this supplier failed that questionnaire fourteen months ago under a different trading name. No agent had that. That is judgment, and it is worth the wait.
Higher-risk is a rule somebody has to write down
The post does not define higher-risk, and it should not, because the threshold is your purchasing policy rather than Microsoft's. What the post does say is where the rule lives. The application applies the approval rules. The agent gathers and the workflow routes, and neither of them decides whether a person is needed. We think that split is why the example holds together. The agent's reasoning never touches the question of who has to sign.
Someone in your organisation therefore has to write the rule as data in Dataverse rather than as a line in a Copilot Studio prompt. Off-contract supplier. Spend above a named amount. A category the company has been burned on before. Each of those is a row in a table with an owner's name against it. Our sibling piece on why process ownership matters more than the demo argues that the owner's name is the shortest line on the page. The routing rule is the second shortest, and it decides how often that owner gets interrupted.
The approver has to see what the agent gathered
An approval card that shows an amount, a requester, and two buttons gives the person nothing to judge. In Microsoft's example the agent has already collected the supplier information and the relevant policy. If that work does not reach the approver, one of two things happens. They approve blind, which is the Friday queue again. Or they open Teams, ask the requester what this is for, get a two-line answer, and approve on the strength of it. The conversation never lands in the record, and the next auditor finds a signature with nothing behind it.
So the approval card has real requirements. Which rule fired. What the agent found. What the requester said. What a rejection does to the request. Our piece on designing the human review step for agent work sets out what that person should be shown, and our other PPCC piece on the durable process record covers where the decision has to land. The post lists human approvals and Dataverse in the same workshop description. We read that as the approval writing to the record, and we would ask the workshop leads in October whether the approval action in their build does.
Measure the approval you already have before October
You do not need to wait for Las Vegas to learn whether your approval steps are controls or delays. Pull the run history of one approval flow in Power Automate for the past ninety days. Count the approvals, count the rejections, and note the median time between the card going out and the button being pressed. A rejection rate near zero with a wait measured in days means the person is adding calendar time and nothing else. A rejection rate of one in ten with reasons written in the comments means the step is doing work.
Then do what the post describes. Move the routine requests onto the path the workflow handles alone, raise the threshold until the approver's queue only holds the cases she would want to see, and put her name against the rule that decides what reaches her. The governance that keeps low-code moving guide has a review pattern light enough for this. Bring the ninety-day numbers to your next process review and ask the approver one question. Of everything you approved last quarter, which requests would you have wanted to see if the agent had handled the rest?
