The run said succeeded and the work was not done
The most misleading number in a Power Automate operations review is the success rate. I sat in one last spring where the flow that turned a SharePoint request form into purchase requisitions showed a month of green runs, and the procurement lead had a spreadsheet open on her second monitor with forty rows she had corrected by hand. Every one of those rows came from a run the flow had reported as a success. Nobody in the room had connected the two things, because the maker looked at run history and procurement looked at the spreadsheet.
That gap is where automation ownership breaks. It breaks in the stretch between a run finishing and the business outcome being put right, and nobody is watching that stretch.
Three places the thread gets dropped
The first is the scope with a run-after set to has failed that ends in a Send an email action. The email goes to the maker's inbox, or to a shared mailbox that was set up for a different project. Because the error branch completed, the run itself shows as succeeded. The run history is clean, the inbox has the failure, and the person who reads that inbox has no idea what to do with a JSON error body.
The second is the condition that ends in Terminate with a status of Succeeded. Makers do this to keep run history readable when a record is not ready for processing, for example a new vendor with no tax ID on file yet. It works, and it also means the record silently drops out of the process. Nobody gets a task. The vendor waits, someone in accounts payable chases it three weeks later, and the flow never appears in the investigation because it never failed.
The third is the resubmit. A flow that failed halfway through a Dataverse create and was resubmitted from run history produces a second requisition with a second number. The design side of that problem is covered in give queued work a business owner. The operations side is simpler and uglier. Whoever clicked resubmit is now the person who has to find the duplicate, and they usually do not know that.
The owner on the flow is rarely the recovery owner
Every flow has an owner in the Power Platform admin center. That owner is almost always the maker, and the maker is almost never the person who repairs the business outcome when the flow does something wrong. The maker fixes the flow. Someone in procurement, finance, or HR fixes the requisition, the journal, or the leave balance. That second person is the recovery owner, and in most of the tenants I have reviewed their name is written down nowhere.
I ask one question in reviews. When this flow last went wrong, who fixed the data, and how did they find out? The answer is usually a name, a shrug, and a story about a Teams message. That name and that Teams message are your recovery owner and your detection method. Neither is recorded, so neither survives that person changing roles.
It gets worse when the maker leaves. The flow keeps running on a connection that belongs to a departed account until the account is disabled. Then it fails, and the failure email goes to a mailbox nobody reads. I wrote about getting through the first thirty minutes of a platform incident, and the honest fix is to know the recovery owner before the incident.
What a monthly operations review should look at instead
Run counts and success rates go on the first slide because they are easy to pull. I would move them to the last slide. The first slide should be the exceptions list: every run that ended in the error branch, every Terminate as Succeeded, every resubmit, and every record a person touched by hand after the flow touched it. That last category is the hard one because the flow does not know about it. You get it by asking the recovery owner to keep a tally, or by looking at the modified-by column on the records the flow creates and filtering for humans.
The second thing to review is handoffs. A flow that creates a Planner task or assigns a Dataverse record has handed the work to a person, and the review should show how many of those items are still open. A flow that runs successfully and hands off into a queue nobody works is a broken process with a clean run history. The same discipline applies when the handoff is to an agent rather than a person, which is why I keep pointing people at the human review step for agent work.
The third is the unresolved ownership list. Every flow where the answer to who fixes the data was a shrug goes on it. The review does not end until each one has a name or a decision to switch the flow off. I have watched teams keep this list for six months and shorten it by one flow a meeting, and that is fine. It fits the short-conversation style of review I described in governance that keeps low-code work moving.
Measure time to a resolved outcome, not time to a rerun
The number I want on the wall is the time from a failure being detected to the business outcome being resolved. A rerun that creates a duplicate has resolved nothing. For the requisition flow, resolved means procurement has one requisition with the right supplier and the right cost centre, and the requester has been told. That might take an hour or two weeks, and the two weeks is the number that changes behaviour in the room.
Split that number in two and the first half is usually the embarrassing one. Time to detection is how long the failure sat unnoticed. If the only detection is a person in the business noticing something is missing, time to detection is measured in weeks, and no amount of retry logic in the flow will shorten it. Time to resolution after detection is what the recovery owner controls, and it is usually reasonable once they know.
High run volume hides all of this. A flow that runs four thousand times a month with a two percent problem rate produces eighty pieces of manual cleanup that nobody is counting. The success rate says ninety-eight percent and the review moves on. The recovery measure would say eighty items and an average of nine days to detection, and the review would stop right there.
What I say in the meeting
I bring one flow, the one with the most runs, and I ask three things. Who fixed the last bad outcome from this flow. How did they know it needed fixing. How long did it take from the bad run to the corrected record. If the answers are a name, a Teams message, and nobody knows, that flow has no recovery owner and it goes first on the list.
Then I ask the maker for three changes. Put the recovery owner's name in the flow description. Change the error branch so it creates a task assigned to that person instead of sending an email. Replace the Terminate as Succeeded with a Terminate as Failed that carries a plain-language reason a non-technical person can act on. None of that needs a new licence or a new tool. It needs the maker and the platform owner to agree that a green run history was never the goal.
Before your next operations review, go and find the person who cleaned up after your busiest flow last month. Ask them how they knew. Write down the answer, because that is the recovery process you actually have.
