All skills
github avatar

/flowstudio-power-automate-debug

@0ccadfd official
by githubgithub/awesome-copilot40k stars
5,040

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 flow failing, inspect action outputs, find the root cause of a flow error, fix a broken Power Automate flow, diagnose a timeout, trace a DynamicOperationRequestFailure, check connector auth errors, read error details from a run, or troubleshoot expression failures. Requires a FlowStudio MCP subscription — see https://mcp.flowstudio.app

Use this Skill: https://skilld.dev/gh/github/awesome-copilot/flowstudio-power-automate-debug

This session only. Nothing lands on disk.

referencesdebug-workflow.md

≈1.4k tokens on demand. Your agent reads this file only when SKILL.md points to it.

FlowStudio MCP — Debug Workflow

End-to-end decision tree for diagnosing Power Automate flow failures.


Top-Level Decision Tree

Flow is failing
│
├── Flow never starts / no runs appear
│   └── ► Check flow State: get_live_flow → properties.state
│       ├── "Stopped" → flow is disabled; enable in PA designer
│       └── "Started" + no runs → trigger condition not met (check trigger config)
│
├── Flow run shows "Failed"
│   ├── Step A: get_live_flow_run_error  → read error.code + error.message
│   │
│   ├── error.code = "InvalidTemplate"
│   │   └── ► Expression error (null value, wrong type, bad path)
│   │       └── See: Expression Error Workflow below
│   │
│   ├── error.code = "ConnectionAuthorizationFailed"
│   │   └── ► Connection owned by different user; fix in PA designer
│   │
│   ├── error.code = "ActionFailed" + message mentions HTTP
│   │   └── ► See: HTTP Action Workflow below
│   │
│   ├── parent action is Foreach / Apply to each
│   │   └── ► Inspect child actions; handled child failures can still fail the parent
│   │
│   └── Unknown / generic error
│       └── ► Walk actions backwards (Step B below)
│
└── Flow Succeeds but output is wrong
    └── ► Inspect intermediate actions with get_live_flow_run_action_outputs
        └── See: Data Quality Workflow below

Expression Error Workflow

InvalidTemplate error
│
├── 1. Read error.message — identifies the action name and function
│
├── 2. Get flow definition: get_live_flow
│   └── Find that action in definition["actions"][action_name]["inputs"]
│       └── Identify what upstream value the expression reads
│
├── 3. get_live_flow_run_action_outputs for the action BEFORE the failing one
│   └── Look for null / wrong type in that action's output
│       ├── Null string field → wrap with coalesce(): @coalesce(field, '')
│       ├── Null object → add empty check condition before the action
│       └── Wrong field name → correct the key (case-sensitive)
│
└── 4. Apply fix with update_live_flow, then resubmit

HTTP Action Workflow

ActionFailed on HTTP action
│
├── 1. get_live_flow_run_action_outputs on the HTTP action
│   └── Read: outputs.statusCode, outputs.body
│
├── statusCode = 401
│   └── ► Auth header missing or expired OAuth token
│       Check: action inputs.authentication block
│
├── statusCode = 403
│   └── ► Insufficient permission on target resource
│       Check: service principal / user has access
│
├── statusCode = 400
│   └── ► Malformed request body
│       Check: action inputs.body expression; parse errors often in nested JSON
│
├── statusCode = 404
│   └── ► Wrong URL or resource deleted/renamed
│       Check: action inputs.uri expression
│
└── statusCode = 500 / timeout
    └── ► Target system error; retry policy may help
        Add: "retryPolicy": {"type": "Fixed", "count": 3, "interval": "PT10S"}

Data Quality Workflow

Flow succeeds but output data is wrong
│
├── 1. Identify the first "wrong" output — which action produces it?
│
├── 2. get_live_flow_run_action_outputs on that action
│   └── Compare actual output body vs expected
│
├── Source array has nulls / unexpected values
│   ├── Check the trigger data — get_live_flow_run_action_outputs on trigger
│   └── Trace forward action by action until the value corrupts
│
├── Merge/union has wrong values
│   └── Check union argument order:
│       union(NEW, old) = new wins  ✓
│       union(OLD, new) = old wins  ← common bug
│
├── Foreach output missing items
│   ├── Check foreach condition — filter may be too strict
│   └── Check if parallel foreach caused race condition (add Sequential)
│
├── Filter/Query result unexpectedly matches nulls or returns empty
│   └── Guard lookup keys before the filter; do not compare null-to-null
│
└── Date/time values wrong timezone
    └── Use convertTimeZone() — utcNow() is always UTC

Walk-Back Analysis (Unknown Failure)

When the error message doesn't clearly name a root cause:

# 1. Get all action names from definition
defn = mcp("get_live_flow", environmentName=ENV, flowName=FLOW_ID)
actions = list(defn["properties"]["definition"]["actions"].keys())

# 2. Check status of each action in the failed run
for action in actions:
    actions_out = mcp("get_live_flow_run_action_outputs",
        environmentName=ENV, flowName=FLOW_ID, runName=RUN_ID,
        actionName=action)
    # Returns an array of action objects
    item = actions_out[0] if actions_out else {}
    status = item.get("status", "unknown")
    print(f"{action}: {status}")

# 3. Find the boundary between Succeeded and Failed/Skipped
# The first Failed action is likely the root cause (unless skipped by design)

Actions inside Foreach / Condition branches may appear nested — check the parent action first to confirm the branch ran at all.


Post-Fix Verification Checklist

  1. update_live_flow returns error: null — definition accepted
  2. resubmit_live_flow_run confirms new run started
  3. Wait for run completion (poll get_live_flow_runs every 15 s)
  4. Confirm new run status = "Succeeded"
  5. If flow has downstream consumers (child flows, emails, SharePoint writes), spot-check those too

Source: SKILL.md on GitHub

1 alert16d5 checks · Risk SAFE
  • Gen Agent Trust Hub16d

    This skill provides tools for debugging Power Automate flows by interacting with a third-party MCP server. While functionally sound, it introduces a surface for indirect prompt injection because the agent reads and interprets potentially untrusted data from flow outputs and error messages to perform high-impact actions like updating flow definitions or re-triggering runs.

  • Socket16d

    1 alert: gptAnomaly

  • Snyk16d

    Risk: MEDIUM · 1 issue

  • Runlayer6mo

    1/3 files flagged

  • ZeroLeaks5mo

    Score: 93/100 · 2 sections analyzed

Signed by skilld at 0ccadfd. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 20 hours ago.

Activeupdated 4 weeks ago
  • Debugging
  • MCP
  • power-automate
  • flowstudio
  • cloud-flows
  • diagnostics
  • connector-errors
  • action-outputs

README badge

README badge for github/awesome-copilot/flowstudio-power-automate-debug

Debugs failing Power Automate cloud flows by inspecting action-level inputs and outputs through the FlowStudio MCP server, revealing the actual root cause when Graph API only shows generic error codes. Targets Power Automate flows specifically and requires a FlowStudio MCP subscription.

Generated from the current SKILL.md.

What does this skill require to work?
A FlowStudio MCP server must be reachable with a valid JWT token. You need a FlowStudio MCP subscription — see https://mcp.flowstudio.app and load the `flowstudio-power-automate-mcp` skill for connection setup.
Can this skill debug any Power Automate flow error?
Yes, it handles any failing cloud flow run. The skill walks you through inspecting action-level inputs and outputs to find the root cause — whether it's an HTTP error, expression failure, null value, timeout, connector auth issue, or DynamicOperationRequestFailure.
How does this differ from checking the Graph API directly?
The Graph API only shows top-level status codes like 'ActionFailed' or 'InternalServerError'. This skill calls FlowStudio MCP to retrieve the actual inputs and outputs of each action, revealing the real error — HTTP response bodies, null values, stack traces, or wrong field paths.
What if an action runs multiple times in a foreach loop?
The `get_live_flow_run_action_outputs` tool returns every repetition by default. You can pass `iterationIndex` to inspect a single iteration, or iterate through the results to find which loop cycle failed.
Does this work with child flows or nested actions?
Yes. The skill inspects any action in the flow definition, including those nested in foreach, switch, or do-until scopes. The failedActions array is ordered outer-to-inner, so the root cause is always the last entry.

Generated from the current SKILL.md. These answers refresh after source changes.