Power Automate Flow Runs But Does the Wrong Thing

A flow that runs without errors but produces the wrong output is often harder to fix than one that fails visibly — because the run history shows green checkmarks everywhere, and you have to figure out where the logic went wrong rather than where it crashed. Here's how to approach it systematically.

1. Read the run history inputs and outputs carefully

In Run History, every step shows not just whether it succeeded but what data went in and what came out. Click each step and expand the inputs and outputs — this is where logic errors become visible. Common findings: a dynamic content field pulled the wrong value, a condition evaluated differently than you expected, or an "Apply to Each" loop processed more items than intended.

2. Condition logic evaluating incorrectly

Conditions are the most common source of "it runs but does the wrong thing" behavior. A few specific things to check:

• Case sensitivity: Power Automate string comparisons are case-sensitive by default. "Approved" and "approved" are not the same. Use the toLower() or toUpper() expressions to normalize before comparing if you're not sure about casing.
• Leading/trailing spaces: data from forms or SharePoint sometimes includes invisible spaces. Use trim() around your value before comparing.
• Null/empty values: if a field is sometimes empty, a condition checking its value can behave unexpectedly. Add a null check using the empty() function before the comparison.
• Wrong branch taken: if the flow is consistently going into the "No" branch of a condition when it should go into "Yes," open the condition step and verify the expression — use the Peek code option to see the raw expression rather than the visual builder, which sometimes hides errors.

3. Flow triggering more times than expected

If your flow is running multiple times per event, or running when it shouldn't:

• "When an item is modified" triggers on its own changes: if your flow modifies a SharePoint item, that modification can re-trigger the flow, creating a loop. Fix this by adding a trigger condition that checks a specific field value before proceeding, or by checking whether the item was modified by the flow's own service account.
• Multiple triggers set up: check if you accidentally have the same flow saved in two versions, or if a second, similar flow is also running.
• Trigger firing on all modifications vs. specific ones: the SharePoint "when an item is modified" trigger fires for any column change, not just the one you care about. Use trigger conditions or check inside the flow which specific column changed.

4. Wrong data appearing in emails or actions

If the right action runs but with wrong values — the email goes to the right person but contains the wrong information, or the wrong row gets updated:

• Check which dynamic content field you used — hover over it in the flow editor to see exactly what it references
• If you're inside an "Apply to Each" loop, make sure you're referencing the current item's fields, not a field from outside the loop (a common mistake where the same value repeats for every iteration)
• Check if a filter query on a SharePoint "Get items" step is returning more items than expected — an overly broad filter can result in actions running against the wrong records

5. "Apply to Each" running once instead of for all items

If a loop only processes one item when it should process many, check what you're passing into it. The input to "Apply to Each" should be an array — if you're accidentally passing a single item or a string instead of an array, it processes only once. Use a Compose action to inspect the value going into the loop before it runs.

6. Race conditions in concurrent flows

If multiple instances of your flow run at the same time and interfere with each other (updating the same record simultaneously, for example), you may be hitting a concurrency issue. Open the trigger settings and look for the Concurrency Control option — setting the degree of parallelism to 1 forces flows to run sequentially rather than simultaneously, which is slower but eliminates race conditions on shared data.

The bottom line

Logic errors in Power Automate are almost always visible in the run history inputs/outputs — the flow isn't hiding information, it's just presenting it in a way you need to read step-by-step. The Compose action trick (inserting a step to inspect a value before it's used) resolves the majority of "wrong output" problems quickly by confirming exactly what data the flow is actually working with.