Operational rules
Operational rules check whether a flow survives failure and whether anyone notices when it does not. The category carries a 1.0 multiplier in scoring.
RES-01 — Missing Try-Catch Pattern (Medium)
What it checks. Whether the flow contains a Scope action and at least one action with run-after set to Failed, anywhere in the definition including nested branches, else-blocks, and switch cases. The rule fires when either is missing, and the finding records which of the two checks failed.
Why it matters. Without structured exception handling, a partial failure can leave data in an inconsistent state.
What to do. Wrap critical action sequences in a Scope, then add a second Scope that runs after the first has failed.
RES-03 — Missing Error Notification (Medium)
What it checks. Whether any action in the flow has run-after set to Failed. The rule fires when there is no failure handler at all.
Why it matters. Failures pass silently, and the operations team hears about them from users instead of from the flow.
What to do. Add a Scope-based try-catch, or a run-after Failed action that sends a notification to Teams, email, or a ticketing system.
RES-01 and RES-03 overlap by design: RES-01 checks the structure of the pattern, RES-03 checks that a failure path exists at all. One well-built try-catch clears both.
PER-10 — Auto-Shutdown Risk (Medium)
What it checks. Run history. The rule fires when the flow has failed or been throttled on seven or more consecutive days, and the finding lists the affected days. Without run data it has nothing to evaluate.
Why it matters. Power Platform can automatically disable flows with persistent failures, so a flow you depend on may simply stop.
What to do. Find the root cause: data source errors, rate limits, and authentication problems are the usual suspects. Add retry logic where the failure is transient.
In 1.2.0. This rule cannot fire — the scan does not collect run history, so there is nothing to evaluate. See Known limitations in 1.2.0.
Last updated: July 27, 2026