Citizen Developer
  • All of Microsoft
  • My Role
    • All in My Role
    • Citizen Developer
  • Focus
    • All in Focus
    • Microsoft Build 2026
    • Generative Pages and Apps
    • Microsoft Copilot Studio
    • Copilot Studio - Agent Step-by-Step
    • What's Hot
    • M365 Release
Timespan
explore our new search
Power Automate: troubleshoot wrong flow outcomes
Power Automate

Power Automate: troubleshoot wrong flow outcomes

by HubSite 365 about Softchief Learn

Learn how to take advantage of your business data with Microsoft Dynamics 365 & Power Platform & Cross Technologies. My name is Sanjaya Prakash Pradhan and I am a Microsoft Certified Trainer (MCT) and

Power Automate run history can show a successful execution even when a flow routes an approval incorrectly or creates duplicates.

Key insights

  • A Succeeded run confirms configured actions completed; it does not prove the correct business outcome.
  • Inspect trigger outputs and action inputs to verify the record ID, amount, and values used by conditions.
  • Test boundary values, including exactly 50,000, and agree on the rule with the business owner.
  • Two successful runs can create duplicate approvals if both process the same pending record.
  • For current values, retrieve the Dataverse row by ID before routing when needed.

Power Automate run history reports whether configured actions executed, but a green Succeeded status does not confirm that the flow made the right business decision. This distinction matters to makers and support teams responsible for approval flows and other production automations. Softchief Learn demonstrates the issue through a purchase-order approval scenario.

What it does

A cloud flow can complete without a runtime error and still route a record to the wrong approver. In the example, orders below 50,000 go to a manager and orders above 50,000 go to Finance, but a 200,000 order is sent to the manager. The issue may be the data or condition the flow used, rather than a failed action.

Run history is useful evidence: it exposes trigger outputs and action inputs and outputs. It does not decide whether the selected record, approver, or final status matches the business requirement. Treat technical execution and business correctness as separate checks when investigating a Power Automate flow.

Who it is for and what you need

This troubleshooting approach is for people who build or support flows that route approvals or update business records. The scenario refers to Dataverse or ERP purchase orders and a Dataverse trigger, but does not specify a required license, plan, region, or rollout status.

The example assumes an approval rule based on order amount. Confirm the exact threshold with the process owner: the material does not define what should happen at exactly 50,000, with a blank amount, or when currency differs.

How it works

Trace one business event from its trigger to the final record state. Softchief Learn’s example identifies several checks that can explain a successful run with an incorrect outcome:

  1. Open Flow Run History and inspect the trigger output, including the record ID and amount.
  2. Review action inputs and outputs, then check the condition, comparison operator, expressions, and selected column.
  3. For Dataverse, check whether the flow triggers on every modification and whether it is using an outdated trigger value. Retrieve the row by ID when the process needs the latest committed values.
  4. Verify the approval response and final record status. Check timestamps, retries, and concurrency for duplicate runs.

Test both ordinary and boundary cases, and reproduce simultaneous updates where relevant. The demonstration’s core example is that two runs can each succeed while creating duplicate approval requests. A stable transaction key, checking whether an approval already exists, and making retries safe are suggested ways to prevent duplicate processing.

Limitations and open questions

The demonstration does not provide a complete flow design, exact expressions, or a menu-by-menu setup for trigger conditions or concurrency controls. It also leaves the threshold boundary and currency handling for the business owner to define. The material does not identify a specific license or availability restriction.

A successful status alone cannot establish whether a process worked; verify the intended business result in the record and approval state. The clip does not compare this approach with a named alternative monitoring or error-handling design.

Sources

Frequently asked questions

Does Succeeded in Power Automate mean the business process worked?

No. It indicates the configured actions completed without an unhandled runtime failure, not that the right record, decision, or outcome was produced.

How do I troubleshoot a successful flow that sent the wrong approval?

Inspect the trigger outputs, action inputs and outputs, condition evaluation, approver, and final record status. Check the record ID and the amount value used for routing.

How can a Power Automate flow create duplicate approvals?

Two runs can read the same pending record and each create an approval. The material suggests checking for an existing approval, using a stable transaction key, and making retries safe.

What should an approval flow do at exactly 50,000?

The example does not specify the boundary. Confirm with the business owner whether the rule is greater than or greater than or equal to the threshold.