Flowstudio Power Automate Debug

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 |

Data entry, not a flow bug |

Null value crashes child flow

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

import json, urllib.request

MCP_URL   = "https://mcp.flowstudio.app/mcp"
MCP_TOKEN = "<YOUR_JWT_TOKEN>"

def mcp(tool, **kwargs):
    payload = json.dumps({"jsonrpc": "2.0", "id": 1, "method": "tools/call",
                          "params": {"name": tool, "arguments": kwargs}}).encode()
    req = urllib.request.Request(MCP_URL, data=payload,
        headers={"x-api-key": MCP_TOKEN, "Content-Type": "application/json",
                 "User-Agent": "FlowStudio-MCP/1.0"})
    try:
        resp = urllib.request.urlopen(req, timeout=120)
    except urllib.error.HTTPError as e:
        body = e.read().decode("utf-8", errors="replace")
        raise RuntimeError(f"MCP HTTP {e.code}: {body[:200]}") from e
    raw = json.loads(resp.read())
    if "error" in raw:
        raise RuntimeError(f"MCP error: {json.dumps(raw['error'])}")
    return json.loads(raw["result"]["content"][0]["text"])

ENV = "<environment-id>"   # e.g. Default-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

---

Step 1 — Locate the Flow

result = mcp("list_live_flows", environmentName=ENV)
# Returns a wrapper object: {mode, flows, totalCount, error}
target = next(f for f in result["flows"] if "My Flow Name" in f["displayName"])
FLOW_ID = target["id"]   # plain UUID — use directly as flowName
print(FLOW_ID)

---

Step 2 — Find the Failing Run

runs = mcp("get_live_flow_runs", environmentName=ENV, flowName=FLOW_ID, top=5)
# Returns direct array (newest first):
# [{"name": "08584296068667933411438594643CU15",
#   "status": "Failed",
#   "startTime": "2026-02-25T06:13:38.6910688Z",
#   "endTime": "2026-02-25T06:15:24.1995008Z",
#   "triggerName": "manual",
#   "error": {"code": "ActionFailed", "message": "An action failed..."}},
#  {"name": "...", "status": "Succeeded", "error": null, ...}]

for r in runs:
    print(r["name"], r["status"], r["startTime"])

RUN_ID = next(r["name"] for r in runs if r["status"] == "Failed")

---

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.

err = mcp("get_live_flow_run_error",
    environmentName=ENV, flowName=FLOW_ID, runName=RUN_ID)
# Returns:
# {
#   "runName": "08584296068667933411438594643CU15",
#   "failedActions": [
#     {"actionName": "Apply_to_each_prepare_workers", "status": "Failed",
#      "error": {"code": "ActionFailed", "message": "An action failed..."},
#      "startTime": "...", "endTime": "..."},
#     {"actionName": "HTTP_find_AD_User_by_Name", "status": "Failed",
#      "code": "NotSpecified", "startTime": "...", "endTime": "..."}
#   ],
#   "allActions": [
#     {"actionName": "Apply_to_each", "status": "Skipped"},
#     {"actionName": "Compose_WeekEnd", "status": "Succeeded"},
#     ...
#   ]
# }

# failedActions is ordered outer-to-inner. The ROOT cause is the LAST entry:
root = err["failedActions"][-1]
print(f"Root action: {root['actionName']} → code: {root.get('code')}")

# allActions shows every action's status — useful for spotting what was Skipped
# See common-errors.md to decode the error code.

---

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.**

# Get the root failing action's full inputs and outputs
root_action = err["failedActions"][-1]["actionName"]
detail = mcp("get_live_flow_run_action_outputs",
    environmentName=ENV,
    flowName=FLOW_ID,
    runName=RUN_ID,
    actionName=root_action)

if len(detail) > 1:
    print(f"{root_action} returned {len(detail)} repetitions; inspect iteration indexes")
out = detail[0] if detail else {}
print(f"Action: {out.get('actionName')}")
print(f"Status: {out.get('status')}")

# For HTTP actions, the real error is in outputs.body
if isinstance(out.get("outputs"), dict):
    status_code = out["outputs"].get("statusCode")
    body = out["outputs"].get("body", {})
    print(f"HTTP {status_code}")
    print(json.dumps(body, indent=2)[:500])

    # Error bodies are often nested JSON strings — parse them
    if isinstance(body, dict) and "error" in body:
        err_detail = body["error"]
        if isinstance(err_detail, str):
            err_detail = json.loads(err_detail)
        print(f"Error: {err_detail.get('message', err_detail)}")

# For expression errors, the error is in the error field
if out.get("error"):
    print(f"Error: {out['error']}")

# Also check inputs — they show what expression/URL/body was used
if out.get("inputs"):
    print(f"Inputs: {json.dumps(out['inputs'], indent=2)[:500]}")

What the action outputs reveal (that error codes don't)

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:

all_reps = mcp("get_live_flow_run_action_outputs",
    environmentName=ENV,
    flowName=FLOW_ID,
    runName=RUN_ID,
    actionName=root_action)

for rep in all_reps[:10]:
    print(rep.get("repetitionIndexes"), rep.get("status"), rep.get("error"))

one_rep = mcp("get_live_flow_run_action_outputs",
    environmentName=ENV,
    flowName=FLOW_ID,
    runName=RUN_ID,
    actionName=root_action,
    iterationIndex=3)

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

Error code: "InternalServerError" ← this tells you nothing

Action outputs reveal:
  HTTP 500
  body: {"error": "Cannot read properties of undefined (reading 'toLowerCase')
    at getClientParamsFromConnectionString (storage.js:20)"}
  ← THIS tells you the Azure Function crashed because a connection string is undefined

Example: Expression error on null

Error code: "BadRequest" ← generic

Action outputs reveal:
  inputs: "body('HTTP_GetTokenFromStore')?['token']?['access_token']"
  outputs: ""   ← empty string, the path resolved to null
  ← THIS tells you the response shape changed — token is at body.access_token, not body.token.access_token

---

Step 5 — Read the Flow Definition

defn = mcp("get_live_flow", environmentName=ENV, flowName=FLOW_ID)
actions = defn["properties"]["definition"]["actions"]
print(list(actions.keys()))

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:

# Inspect multiple actions leading up to the failure
for action_name in [root_action, "Compose_WeekEnd", "HTTP_Get_Data"]:
    result = mcp("get_live_flow_run_action_outputs",
        environmentName=ENV,
        flowName=FLOW_ID,
        runName=RUN_ID,
        actionName=action_name)
    out = result[0] if result else {}
    print(f"\n--- {action_name} ({out.get('status')}) ---")
    print(f"Inputs:  {json.dumps(out.get('inputs', ''), indent=2)[:300]}")
    print(f"Outputs: {json.dumps(out.get('outputs', ''), indent=2)[:300]}")

⚠️ 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

# Example: action uses split(item()?['Name'], ' ')
# → null Name in the source data
result = mcp("get_live_flow_run_action_outputs", ..., actionName="Compose_Names")
if not result:
    print("No outputs returned for Compose_Names")
    names = []
else:
    names = result[0].get("outputs", {}).get("body") or []
nulls = [x for x in names if x.get("Name") is None]
print(f"{len(nulls)} records with null Name")

Wrong Field Path

Expression triggerBody()?['fieldName'] returns null → fieldName is wrong. Inspect the trigger output to see the actual field names:

result = mcp("get_live_flow_run_action_outputs", ..., actionName="<trigger-action-name>")
print(json.dumps(result[0].get("outputs"), indent=2)[:500])

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:

result = mcp("get_live_flow_run_action_outputs", ..., actionName="HTTP_Get_Data")
out = result[0]
print(f"HTTP {out['outputs']['statusCode']}")
print(json.dumps(out['outputs']['body'], indent=2)[:500])

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:

defn = mcp("get_live_flow", environmentName=ENV, flowName=FLOW_ID)
acts = defn["properties"]["definition"]["actions"]

# Example: fix split on potentially-null Name
acts["Compose_Names"]["inputs"] = \
    "@coalesce(item()?['Name'], 'Unknown')"

conn_refs = defn["properties"]["connectionReferences"]
result = mcp("update_live_flow",
    environmentName=ENV,
    flowName=FLOW_ID,
    definition=defn["properties"]["definition"],
    connectionReferences=conn_refs)

print(result.get("error"))  # None = success

⚠️ 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.

# Resubmit the failed run — works for ANY trigger type
resubmit = mcp("resubmit_live_flow_run",
    environmentName=ENV, flowName=FLOW_ID, runName=RUN_ID)
print(resubmit)   # {"resubmitted": true, "triggerName": "..."}

# Wait ~30 s then check
import time; time.sleep(30)
new_runs = mcp("get_live_flow_runs", environmentName=ENV, flowName=FLOW_ID, top=3)
print(new_runs[0]["status"])   # Succeeded = done

When to use resubmit vs trigger

Testing HTTP-Triggered Flows with custom payloads

For flows with a Request (HTTP) trigger, use trigger_live_flow when you need to send a different payload than the original run:

# First inspect what the trigger expects — read directly from the flow definition
defn = mcp("get_live_flow", environmentName=ENV, flowName=FLOW_ID)
triggers = defn["properties"]["definition"]["triggers"]
manual = next(iter(triggers.values()))   # usually the only trigger on HTTP flows
request_schema = manual.get("inputs", {}).get("schema")
print("Expected body schema:", request_schema)

# Response schemas live on Response action(s) in the actions block
for name, act in defn["properties"]["definition"]["actions"].items():
    if act.get("type") == "Response":
        print(f"Response {name}:", act.get("inputs", {}).get("schema"))

# Trigger with a test payload
result = mcp("trigger_live_flow",
    environmentName=ENV,
    flowName=FLOW_ID,
    body={"name": "Test User", "value": 42})
print(f"Status: {result['responseStatus']}, Body: {result.get('responseBody')}")

trigger_live_flow handles AAD-authenticated triggers automatically.

Only works for flows with a Request (HTTP) trigger type.

---

Quick-Reference Diagnostic Decision Tree

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 — Error codes, likely causes, and fixes
• 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 MCP — Common Power Automate Errors

Reference for error codes, likely causes, and recommended fixes when debugging Power Automate flows via the FlowStudio MCP server.

---

Expression / Template Errors

InvalidTemplate — Function Applied to Null

Full message pattern: "Unable to process template language expressions... function 'split' expects its first argument 'text' to be of type string"

Root cause: An expression like @split(item()?['Name'], ' ') received a null value.

Diagnosis: 1. Note the action name in the error message 2. Call get_live_flow_run_action_outputs on the action that produces the array 3. Find items where Name (or the referenced field) is null

Fixes:

Before: @split(item()?['Name'], ' ')
After:  @split(coalesce(item()?['Name'], ''), ' ')

Or guard the whole foreach body with a condition:
  expression: "@not(empty(item()?['Name']))"

---

InvalidTemplate — Wrong Expression Path

Full message pattern: "Unable to process template language expressions... 'triggerBody()?['FieldName']' is of type 'Null'"

Root cause: The field name in the expression doesn't match the actual payload schema.

Diagnosis:

# Check trigger output shape
mcp("get_live_flow_run_action_outputs",
    environmentName=ENV, flowName=FLOW_ID, runName=RUN_ID,
    actionName="<trigger-name>")
# Compare actual keys vs expression

Fix: Update expression to use the correct key name. Common mismatches:

• triggerBody()?['body'] vs triggerBody()?['Body'] (case-sensitive)
• triggerBody()?['Subject'] vs triggerOutputs()?['body/Subject']

---

InvalidTemplate — Type Mismatch

Full message pattern: "... expected type 'Array' but got type 'Object'"

Root cause: Passing an object where the expression expects an array (e.g. a single item HTTP response vs a list response).

Fix:

Before: @outputs('HTTP')?['body']
After:  @outputs('HTTP')?['body/value']    ← for OData list responses
        @createArray(outputs('HTTP')?['body'])  ← wrap single object in array

---

Connection / Auth Errors

ConnectionAuthorizationFailed

Full message: "The API connection ... is not authorized."

Root cause: The connection referenced in the flow is owned by a different user/service account than the one whose JWT is being used.

Diagnosis: Check properties.connectionReferences — the connectionName GUID identifies the owner. Cannot be fixed via API.

Fix options: 1. Open flow in Power Automate designer → re-authenticate the connection 2. Use a connection owned by the service account whose token you hold 3. Share the connection with the service account in PA admin

---

InvalidConnectionCredentials

Root cause: The underlying OAuth token for the connection has expired or the user's credentials changed.

Fix: Owner must sign in to Power Automate and refresh the connection.

---

HTTP Action Errors

ActionFailed — HTTP 4xx/5xx

Full message pattern: "An HTTP request to... failed with status code '400'"

Diagnosis:

actions_out = mcp("get_live_flow_run_action_outputs", ..., actionName="HTTP_My_Call")
item = actions_out[0]   # first entry in the returned array
print(item["outputs"]["statusCode"])   # 400, 401, 403, 500...
print(item["outputs"]["body"])         # error details from target API

Common causes:

• 401 — missing or expired auth header
• 403 — permission denied on target resource
• 404 — wrong URL / resource deleted
• 400 — malformed JSON body (check expression that builds the body)

---

ActionFailed — HTTP Timeout

Root cause: Target endpoint did not respond within the connector's timeout (default 90 s for HTTP action).

Fix: Add retry policy to the HTTP action, or split the payload into smaller batches to reduce per-request processing time.

---

Control Flow Errors

ActionSkipped Instead of Running

Root cause: The runAfter condition wasn't met. E.g. an action set to runAfter: { "Prev": ["Succeeded"] } won't run if Prev failed or was skipped.

Diagnosis: Check the preceding action's status. Deliberately skipped (e.g. inside a false branch) is intentional — unexpected skip is a logic gap.

Fix: Add "Failed" or "Skipped" to the runAfter status array if the action should run on those outcomes too.

---

Foreach Runs in Wrong Order / Race Condition

Root cause: Foreach without operationOptions: "Sequential" runs iterations in parallel, causing write conflicts or undefined ordering.

Fix: Add "operationOptions": "Sequential" to the Foreach action.

---

Foreach Parent Failed After Handled Inner Failure

Symptom: Inner actions have failure handlers, but the parent Foreach still shows Failed, and downstream actions such as Response are skipped.

Root cause: A handled child failure can still mark the loop container as failed. Downstream runAfter that only accepts Succeeded will not run.

Diagnosis: Inspect the parent foreach with get_live_flow_run_error, then inspect child action outputs for the iteration that failed.

Fix: If partial success is acceptable, allow the downstream join/response to run after Succeeded and Failed, and include an explicit error summary in the payload. If the loop must be all-or-nothing, wrap risky inner work in a Scope and handle success/failure at the Scope boundary.

---

Update / Deploy Errors

update_live_flow Returns No-Op

Symptom: result["updated"] is empty list or result["created"] is empty.

Likely cause: Passing wrong parameter name. The required key is definition (object), not flowDefinition or body.

---

update_live_flow — "Supply connectionReferences"

Root cause: The definition contains OpenApiConnection or OpenApiConnectionWebhook actions but connectionReferences was not passed.

Fix: Fetch the existing connection references with get_live_flow and pass them as the connectionReferences argument.

---

Data Logic Errors

union() Overriding Correct Records with Nulls

Symptom: After merging two arrays, some records have null fields that existed in one of the source arrays.

Root cause: union(old_data, new_data) — union() first-wins, so old_data values override new_data for matching records.

Fix: Swap argument order: union(new_data, old_data)

Before: @sort(union(outputs('Old_Array'), body('New_Array')), 'Date')
After:  @sort(union(body('New_Array'), outputs('Old_Array')), 'Date')

---

Null Cascade in Filter Array / Query

Symptom: A lookup/filter step returns the wrong record or a later expression fails on null even though the filter action itself succeeded.

Root cause: The lookup key is null or empty. A condition such as equals(item()?['Email'], outputs('Lookup_Email')) can accidentally match rows where both sides are null, or can pass an empty array downstream.

Diagnosis: Inspect the action that creates the lookup key and the filter output length. Confirm the key is non-empty before trusting the filter result.

Fix: Add a non-empty guard before the filter, normalize comparison values with trim()/toLower(), and branch explicitly when no match is found.

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