Debug failing Power Automate cloud flows using the FlowStudio MCP server. The Graph API only shows top-level status codes. This skill gives your agent action-level inputs and outputs to find the actual root cause. Load this skill when asked to: debug a flow, investigate a failed run, why is this flo

Power Automate Debugging with FlowStudio MCP A step by step diagnostic process for investigating failing Power Automate cloud flows through the FlowStudio MCP server. Real debugging examples : [Expression error in child flow](https://github.com/ninihen1/power automate mcp skills/blob/main/examples/fix expression error.md) [Data entry, not a flow bug](https://github.com/ninihen1/power automate mcp skills/blob/main/examples/data not flow.md) [Null value crashes child flow](https://github.com/ninihen1/power automate mcp skills/blob/main/examples/null child flow.md) Prerequisite : A FlowStudio MCP server must be reachable with a valid JWT. See the flowstudio power automate mcp skill for connection setup. Subscribe at https://mcp.flowstudio.app Source of Truth Always call list skills / tool search first to confirm available tool names and parameter schemas. Tool names and parameters may change between server versions. This skill covers response shapes, behavioral notes, and diagnostic patterns — things tool schemas cannot tell you. If this document disagrees with tool search or a real API response, the API wins. Python Helper Step 1 — Locate the Flow Step 2 — Find the Failing Run Step 3 — Get the Top Level Error CRITICAL : get live flow run error tells you which action failed. get live flow run action outputs tells you why . You must call BOTH. Never stop at the error alone — error codes like ActionFailed , NotSpecified , and InternalServerError are generic wrappers. The actual root cause (wrong field, null value, HTTP 500 body, stack trace) is only visible in the action's inputs and outputs. Step 4 — Inspect the Failing Action's Inputs and Outputs This is the most important step. get live flow run error only gives you a generic error code. The actual error detail — HTTP status codes, response bodies, stack traces, null values — lives in the action's runtime inputs and outputs. Always inspect the failing action immediately after identifying it. What the action outputs reveal (that error codes don't) Error code from get live flow run error What get live flow run action outputs reveals ActionFailed Which nested action actually failed and its HTTP response NotSpecified The HTTP status code + response body with the real error InternalServerError The server's error message, stack trace, or API error JSON InvalidTemplate The exact expression that failed and the null/wrong type value BadRequest The request body that was sent and why the server rejected it Foreach iterations When actionName refers to an action inside a foreach, the output tool can return every repetition of that action. Each item may include repetitionIndexes with the loop name and zero based itemIndex . Use iterationIndex to inspect one iteration after you find the suspicious item: Evidence Compose Bookends For uncertain connector work, add a Compose Request before the risky action and a Compose Result after it, with the result action allowed on both Succeeded and Failed . This gives future debugging a clean payload snapshot without requiring another deploy. Do not include secrets or long binary payloads in these bookends. Example: HTTP action returning 500 Example: Expression error on null Step 5 — Read the Flow Definition Find the failing action in the definition. Inspect its inputs expression to understand what data it expects. Step 6 — Walk Back from the Failure When the failing action's inputs reference upstream actions, inspect those too. Walk backward through the chain until you find the source of the bad data: ⚠️ Output payloads from array processing actions can be very large. Always slice (e.g. [:500] ) before printing. Tip : Omit actionName to list top level actions when you're not sure which action produced the bad data. Once you pick an action inside a foreach, pass iterationIndex to avoid pulling every repetition into context. Step 7 — Pinpoint the Root Cause Expression Errors (e.g. split on null) If the error mentions InvalidTemplate or a function name: 1. Find the action in the definition 2. Check what upstream action/expression it reads 3. Inspect that upstream action's output for null / missing fields Wrong Field Path Expression triggerBody()?['fieldName'] returns null → fieldName is wrong. Inspect the trigger output to see the actual field names: HTTP Actions Returning Errors The error code says InternalServerError or NotSpecified — always inspect the action outputs to get the actual HTTP status and response body: Connection / Auth Failures Look for ConnectionAuthorizationFailed — the connection owner must match the service account running the flow. Cannot fix via API; fix in PA designer. Outlook user picker failures ( DynamicListValuesUndefinedOrInvalid ) Outlook actions like GetEmailsV3 use parameters ( mailboxAddress , to , cc , from ) whose dropdown is backed by builtInOperation:AadGraph.GetUsers — which is broken at the PA listEnum layer and always returns DynamicListValuesUndefinedOrInvalid . This shows up when an agent rebuilds or modifies an Outlook action via update live flow and tries to resolve a user through dynamic options. Don't fix it by retrying AadGraph — switch to shared office365users.SearchUserV2 instead (returns the same AAD user shape). Use describe live connector to confirm whether the affected parameter exposes a structured fallback , then call get live dynamic options against shared office365users.SearchUserV2 instead of the broken AadGraph operation. For dynamic field schemas rather than dropdown options, use get live dynamic properties with the metadata returned by describe live connector . Step 8 — Apply the Fix For expression/data issues : ⚠️ update live flow always returns an error key. A value of null (Python None ) means success. Step 9 — Verify the Fix Use resubmit live flow run to test ANY flow — not just HTTP triggers. resubmit live flow run replays a previous run using its original trigger payload. This works for every trigger type : Recurrence, SharePoint "When an item is created", connector webhooks, Button triggers, and HTTP triggers. You do NOT need to ask the user to manually trigger the flow or wait for the next scheduled run. The only case where resubmit is not available is a brand new flow that has never run — it has no prior run to replay. When to use resubmit vs trigger Scenario Use Why Testing a fix on any flow resubmit live flow run Replays the exact trigger payload that caused the failure — best way to verify Recurrence / scheduled flow trigger live flow (no body ) Runs it now, like the portal's "Run flow" button; resubmit replays a past run's data SharePoint / connector trigger resubmit live flow run Cannot be triggered without creating a real SP item HTTP, Button, or PowerApps trigger with custom test payload trigger live flow When you need to send different data than the original run Brand new flow, never run trigger live flow No prior run exists to resubmit Testing HTTP, Button, and PowerApps flows with custom payloads For flows with a Request trigger (HTTP request, manual Button, or PowerApps), use trigger live flow when you need to send a different payload than the original run. Pass trigger inputs as body for every kind: trigger live flow handles AAD authenticated triggers automatically. Works for Request triggers (HTTP request, Button, PowerApps) and for scheduled (Recurrence) flows, which it runs immediately — with no body , since a scheduled trigger takes no inputs (a body is refused). Automated connector triggers only fire from their source event. Power Automate does not enforce a trigger's required inputs. If you leave one out the run still starts, with that input null, and the result carries a warning naming the missing keys. Cancel the run and call again with the full body if that matters. runName is only returned for Button and PowerApps runs. For HTTP triggers find the run with get live flow runs . Over a browser extension key, Button and PowerApps triggers run only with an empty body. The tool says so and lists the ways round it: resubmit a past run, default the inputs inside the flow with coalesce(triggerBody()?['x'], 'value') , or use a standard API key. Quick Reference Diagnostic Decision Tree Symptom First Tool Then ALWAYS Call What to Look For Flow shows as Failed get live flow run error get live flow run action outputs on the failing action HTTP status + response body in outputs Error code is generic ( ActionFailed , NotSpecified ) — get live flow run action outputs The outputs.body contains the real error message, stack trace, or API error HTTP action returns 500 — get live flow run action outputs outputs.statusCode + outputs.body with server error detail Expression crash — get live flow run action outputs on prior action null / wrong type fields in output body Flow never starts get live flow — check properties.state = "Started" Action returns wrong data get live flow run action outputs — actual output body vs expected Fix applied but still fails get live flow runs after resubmit — new run status field Rule: never diagnose from error codes alone. get live flow run error identifies the failing action. get live flow run action outputs reveals the actual cause. Always call both. Reference Files [common errors.md](references/common errors.md) — Error codes, likely causes, and fixes [debug workflow.md](references/debug workflow.md) — Full decision tree for complex failures Related Skills flowstudio power automate mcp — Foundation skill: connection setup, MCP helper, tool discovery flowstudio power automate build — Build and deploy new flows

flowstudio-power-automate-debug