diff --git a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/SKILL.md b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/SKILL.md index dbea0a05..87237229 100644 --- a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/SKILL.md +++ b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/SKILL.md @@ -392,7 +392,7 @@ if runs: print(result) # {"resubmitted": true, "triggerName": "..."} ``` -### HTTP-triggered flows — custom test payload +### HTTP, Button, and PowerApps flows — custom test payload Only use `trigger_live_flow` when you need to send a **different** payload than the original run. For verifying a fix, `resubmit_live_flow_run` is @@ -407,7 +407,8 @@ print("Expected body:", manual.get("inputs", {}).get("schema")) result = mcp("trigger_live_flow", environmentName=ENV, flowName=FLOW_ID, body={"name": "Test", "value": 1}) -print(f"Status: {result['responseStatus']}") +print(f"Status: {result['responseStatus']}, via: {result['invocation']}") +print(result.get("warning")) # set when a required input was missing: the run still ran, with null ``` ### Brand-new non-HTTP flows (Recurrence, connector triggers, etc.) @@ -469,7 +470,7 @@ payload. | Flow deployed but state is "Stopped" | Flow won't run on schedule | Call `set_live_flow_state` with `state: "Started"` — do **not** use `update_live_flow` for state changes | | Teams "Chat with Flow bot" recipient as object | 400 `GraphUserDetailNotFound` | Use plain string with trailing semicolon (see below) | | Copilot/Skills flow not in a solution | Copilot Studio may not discover it as an agent tool | After deploy, call `add_live_flow_to_solution` with the target `solutionId` | -| Button/Skills trigger used for MCP testing | MCP cannot directly fire the production trigger | Test the same actions through a temporary HTTP twin, then swap the trigger back | +| Button/Skills trigger used for MCP testing | Runs even when a required input is missing (null) | Pass inputs in `trigger_live_flow` `body`; on `warning`, cancel and retry with the full body | | Connector action missing `metadata.operationMetadataId` | Designer/run-only UI can behave inconsistently | Preserve existing IDs; add stable GUIDs for new connector actions | | Placeholder Excel `scriptId` | Dynamic validation fails at save time | Resolve the real Office Script ID before deploying | | SharePoint `PatchItem` omits required fields | Save can fail even if the field is not changing | Echo unchanged required fields such as `item/Title` | diff --git a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/references/trigger-types.md b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/references/trigger-types.md index 613da3b0..ee224146 100644 --- a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/references/trigger-types.md +++ b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-build/references/trigger-types.md @@ -121,9 +121,9 @@ input names and types. After deploying a production Skills-triggered flow, call `add_live_flow_to_solution` with the target `solutionId`; Copilot Studio agent -tool discovery expects the flow to be solution-aware. For MCP-driven testing, -use a temporary HTTP twin with the same actions and payload shape, then restore -the Skills trigger after the actions are verified. +tool discovery expects the flow to be solution-aware. To test it from MCP, call +`trigger_live_flow` with the inputs in `body` — Skills triggers run through the +connector runtime the same way Button and PowerApps triggers do. --- diff --git a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-debug/SKILL.md b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-debug/SKILL.md index 5944db84..c4d1ddd9 100644 --- a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-debug/SKILL.md +++ b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-debug/SKILL.md @@ -411,13 +411,14 @@ print(new_runs[0]["status"]) # Succeeded = done | **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 | `resubmit_live_flow_run` | Cannot be triggered on demand any other way | | SharePoint / connector trigger | `resubmit_live_flow_run` | Cannot be triggered without creating a real SP item | -| HTTP 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` (HTTP only) | No prior run exists to resubmit | +| 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` (HTTP, Button, PowerApps) | No prior run exists to resubmit | -### Testing HTTP-Triggered Flows with custom payloads +### Testing HTTP, Button, and PowerApps 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: +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: ```python # First inspect what the trigger expects — read directly from the flow definition @@ -438,10 +439,27 @@ result = mcp("trigger_live_flow", flowName=FLOW_ID, body={"name": "Test User", "value": 42}) print(f"Status: {result['responseStatus']}, Body: {result.get('responseBody')}") +print(f"Kind: {result['triggerKind']}, via: {result['invocation']}, run: {result.get('runName')}") +if result.get("warning"): + print(result["warning"]) # required trigger inputs you left out ``` > `trigger_live_flow` handles AAD-authenticated triggers automatically. -> Only works for flows with a `Request` (HTTP) trigger type. +> Works for `Request` triggers only: HTTP request, Button, and PowerApps. +> Scheduled and connector triggers cannot be run this way. +> +> 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. --- diff --git a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-mcp/references/tool-reference.md b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-mcp/references/tool-reference.md index 00f5676b..060eea61 100644 --- a/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-mcp/references/tool-reference.md +++ b/plugins/flowstudio-power-automate/skills/flowstudio-power-automate-mcp/references/tool-reference.md @@ -435,31 +435,47 @@ responseSchemaCount - Number of Response actions that define output schemas ### `get_live_flow_trigger_url` -Deprecated. Prefer `trigger_live_flow` when you need to invoke an HTTP-triggered -flow; it fetches the current callback URL internally. +Deprecated. Prefer `trigger_live_flow` when you need to run a flow; it fetches the +callback URL internally for HTTP triggers and uses the connector runtime for +Button and PowerApps triggers, which have no callback URL. Returns the signed callback URL for HTTP-triggered flows. Response includes `flowKey`, `triggerName`, `triggerType`, `triggerKind`, `triggerMethod`, `triggerUrl`. ### `trigger_live_flow` -Response keys: `flowKey`, `triggerName`, `triggerUrl`, `requiresAadAuth`, `authType`, -`responseStatus`, `responseBody`. +Response keys: `flowKey`, `triggerName`, `triggerKind`, `invocation`, `triggerUrl`, +`requiresAadAuth`, `authType`, `responseStatus`, `responseBody`, `runName`, and +`warning` when a required trigger input was not supplied. -> **Only works for `Request` (HTTP) triggers.** Returns an error for Recurrence -> and other trigger types: `"only HTTP Request triggers can be invoked via this tool"`. -> `Button`-kind triggers return `ListCallbackUrlOperationBlocked`. +> **Works for `Request` triggers: HTTP request, Button, and PowerApps.** Returns an +> error for Recurrence and connector triggers: +> `"only HTTP Request triggers can be invoked via this tool"`. +> +> HTTP triggers go through the signed callback URL (`invocation: callbackUrl`). +> Button and PowerApps triggers have no callback URL; with a `body` they run +> through the Power Platform connector runtime (`connectorFlowToken` or +> `connectorApihubToken`), which is the only route that delivers the inputs. +> With no body they use the cheaper direct run (`directRun`). +> +> `runName` is returned only for connector-runtime runs. Otherwise look the run +> up with `get_live_flow_runs`. +> +> Power Automate does not enforce a trigger's `required` list. A missing input +> still starts the run with a null value; `warning` names the missing keys and +> the body shape to retry with. +> +> Browser-extension keys cannot reach the connector runtime, so Button and +> PowerApps triggers run only with an empty body over that key type. The error +> lists the alternatives (resubmit a past run, default the inputs inside the flow +> with `coalesce()`, or use a standard key). > > `responseStatus` + `responseBody` contain the flow's Response action output. > AAD-authenticated triggers are handled automatically. > -> **Content-type note**: The body is sent as `application/octet-stream` (raw), -> not `application/json`. Flows with a trigger schema that has `required` fields -> will reject the request with `InvalidRequestContent` (400) because PA validates -> `Content-Type` before parsing against the schema. Flows without a schema, or -> flows designed to accept raw input (e.g. Baker-pattern flows that parse the body -> internally), will work fine. The flow receives the JSON as base64-encoded -> `$content` with `$content-type: application/octet-stream`. +> **Content type**: `body` is sent as `application/json`, so `triggerBody()` and +> the trigger schema see the object you passed. Verified 2026-08-27 on server 1.2.43 +> against Button, PowerAppV2, and Skills triggers with `required` schemas. --- @@ -578,8 +594,10 @@ tool schemas cannot tell you. connectionReferences. Use `set_live_flow_state` to start/stop a flow. ### `trigger_live_flow` -- **Only works for HTTP Request triggers.** Returns error for Recurrence, connector, - and other trigger types. +- **Works for HTTP, Button, and PowerApps triggers.** Returns error for Recurrence, + connector, and other trigger types. +- Pass trigger inputs as `body`. A `warning` in the result means a required input + was missing and the run started with it null. - AAD-authenticated triggers are handled automatically (impersonated Bearer token). ### `get_live_flow_runs` diff --git a/skills/flowstudio-power-automate-build/SKILL.md b/skills/flowstudio-power-automate-build/SKILL.md index dbea0a05..87237229 100644 --- a/skills/flowstudio-power-automate-build/SKILL.md +++ b/skills/flowstudio-power-automate-build/SKILL.md @@ -392,7 +392,7 @@ if runs: print(result) # {"resubmitted": true, "triggerName": "..."} ``` -### HTTP-triggered flows — custom test payload +### HTTP, Button, and PowerApps flows — custom test payload Only use `trigger_live_flow` when you need to send a **different** payload than the original run. For verifying a fix, `resubmit_live_flow_run` is @@ -407,7 +407,8 @@ print("Expected body:", manual.get("inputs", {}).get("schema")) result = mcp("trigger_live_flow", environmentName=ENV, flowName=FLOW_ID, body={"name": "Test", "value": 1}) -print(f"Status: {result['responseStatus']}") +print(f"Status: {result['responseStatus']}, via: {result['invocation']}") +print(result.get("warning")) # set when a required input was missing: the run still ran, with null ``` ### Brand-new non-HTTP flows (Recurrence, connector triggers, etc.) @@ -469,7 +470,7 @@ payload. | Flow deployed but state is "Stopped" | Flow won't run on schedule | Call `set_live_flow_state` with `state: "Started"` — do **not** use `update_live_flow` for state changes | | Teams "Chat with Flow bot" recipient as object | 400 `GraphUserDetailNotFound` | Use plain string with trailing semicolon (see below) | | Copilot/Skills flow not in a solution | Copilot Studio may not discover it as an agent tool | After deploy, call `add_live_flow_to_solution` with the target `solutionId` | -| Button/Skills trigger used for MCP testing | MCP cannot directly fire the production trigger | Test the same actions through a temporary HTTP twin, then swap the trigger back | +| Button/Skills trigger used for MCP testing | Runs even when a required input is missing (null) | Pass inputs in `trigger_live_flow` `body`; on `warning`, cancel and retry with the full body | | Connector action missing `metadata.operationMetadataId` | Designer/run-only UI can behave inconsistently | Preserve existing IDs; add stable GUIDs for new connector actions | | Placeholder Excel `scriptId` | Dynamic validation fails at save time | Resolve the real Office Script ID before deploying | | SharePoint `PatchItem` omits required fields | Save can fail even if the field is not changing | Echo unchanged required fields such as `item/Title` | diff --git a/skills/flowstudio-power-automate-build/references/trigger-types.md b/skills/flowstudio-power-automate-build/references/trigger-types.md index 613da3b0..ee224146 100644 --- a/skills/flowstudio-power-automate-build/references/trigger-types.md +++ b/skills/flowstudio-power-automate-build/references/trigger-types.md @@ -121,9 +121,9 @@ input names and types. After deploying a production Skills-triggered flow, call `add_live_flow_to_solution` with the target `solutionId`; Copilot Studio agent -tool discovery expects the flow to be solution-aware. For MCP-driven testing, -use a temporary HTTP twin with the same actions and payload shape, then restore -the Skills trigger after the actions are verified. +tool discovery expects the flow to be solution-aware. To test it from MCP, call +`trigger_live_flow` with the inputs in `body` — Skills triggers run through the +connector runtime the same way Button and PowerApps triggers do. --- diff --git a/skills/flowstudio-power-automate-debug/SKILL.md b/skills/flowstudio-power-automate-debug/SKILL.md index 5944db84..c4d1ddd9 100644 --- a/skills/flowstudio-power-automate-debug/SKILL.md +++ b/skills/flowstudio-power-automate-debug/SKILL.md @@ -411,13 +411,14 @@ print(new_runs[0]["status"]) # Succeeded = done | **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 | `resubmit_live_flow_run` | Cannot be triggered on demand any other way | | SharePoint / connector trigger | `resubmit_live_flow_run` | Cannot be triggered without creating a real SP item | -| HTTP 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` (HTTP only) | No prior run exists to resubmit | +| 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` (HTTP, Button, PowerApps) | No prior run exists to resubmit | -### Testing HTTP-Triggered Flows with custom payloads +### Testing HTTP, Button, and PowerApps 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: +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: ```python # First inspect what the trigger expects — read directly from the flow definition @@ -438,10 +439,27 @@ result = mcp("trigger_live_flow", flowName=FLOW_ID, body={"name": "Test User", "value": 42}) print(f"Status: {result['responseStatus']}, Body: {result.get('responseBody')}") +print(f"Kind: {result['triggerKind']}, via: {result['invocation']}, run: {result.get('runName')}") +if result.get("warning"): + print(result["warning"]) # required trigger inputs you left out ``` > `trigger_live_flow` handles AAD-authenticated triggers automatically. -> Only works for flows with a `Request` (HTTP) trigger type. +> Works for `Request` triggers only: HTTP request, Button, and PowerApps. +> Scheduled and connector triggers cannot be run this way. +> +> 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. --- diff --git a/skills/flowstudio-power-automate-mcp/references/tool-reference.md b/skills/flowstudio-power-automate-mcp/references/tool-reference.md index 00f5676b..060eea61 100644 --- a/skills/flowstudio-power-automate-mcp/references/tool-reference.md +++ b/skills/flowstudio-power-automate-mcp/references/tool-reference.md @@ -435,31 +435,47 @@ responseSchemaCount - Number of Response actions that define output schemas ### `get_live_flow_trigger_url` -Deprecated. Prefer `trigger_live_flow` when you need to invoke an HTTP-triggered -flow; it fetches the current callback URL internally. +Deprecated. Prefer `trigger_live_flow` when you need to run a flow; it fetches the +callback URL internally for HTTP triggers and uses the connector runtime for +Button and PowerApps triggers, which have no callback URL. Returns the signed callback URL for HTTP-triggered flows. Response includes `flowKey`, `triggerName`, `triggerType`, `triggerKind`, `triggerMethod`, `triggerUrl`. ### `trigger_live_flow` -Response keys: `flowKey`, `triggerName`, `triggerUrl`, `requiresAadAuth`, `authType`, -`responseStatus`, `responseBody`. +Response keys: `flowKey`, `triggerName`, `triggerKind`, `invocation`, `triggerUrl`, +`requiresAadAuth`, `authType`, `responseStatus`, `responseBody`, `runName`, and +`warning` when a required trigger input was not supplied. -> **Only works for `Request` (HTTP) triggers.** Returns an error for Recurrence -> and other trigger types: `"only HTTP Request triggers can be invoked via this tool"`. -> `Button`-kind triggers return `ListCallbackUrlOperationBlocked`. +> **Works for `Request` triggers: HTTP request, Button, and PowerApps.** Returns an +> error for Recurrence and connector triggers: +> `"only HTTP Request triggers can be invoked via this tool"`. +> +> HTTP triggers go through the signed callback URL (`invocation: callbackUrl`). +> Button and PowerApps triggers have no callback URL; with a `body` they run +> through the Power Platform connector runtime (`connectorFlowToken` or +> `connectorApihubToken`), which is the only route that delivers the inputs. +> With no body they use the cheaper direct run (`directRun`). +> +> `runName` is returned only for connector-runtime runs. Otherwise look the run +> up with `get_live_flow_runs`. +> +> Power Automate does not enforce a trigger's `required` list. A missing input +> still starts the run with a null value; `warning` names the missing keys and +> the body shape to retry with. +> +> Browser-extension keys cannot reach the connector runtime, so Button and +> PowerApps triggers run only with an empty body over that key type. The error +> lists the alternatives (resubmit a past run, default the inputs inside the flow +> with `coalesce()`, or use a standard key). > > `responseStatus` + `responseBody` contain the flow's Response action output. > AAD-authenticated triggers are handled automatically. > -> **Content-type note**: The body is sent as `application/octet-stream` (raw), -> not `application/json`. Flows with a trigger schema that has `required` fields -> will reject the request with `InvalidRequestContent` (400) because PA validates -> `Content-Type` before parsing against the schema. Flows without a schema, or -> flows designed to accept raw input (e.g. Baker-pattern flows that parse the body -> internally), will work fine. The flow receives the JSON as base64-encoded -> `$content` with `$content-type: application/octet-stream`. +> **Content type**: `body` is sent as `application/json`, so `triggerBody()` and +> the trigger schema see the object you passed. Verified 2026-08-27 on server 1.2.43 +> against Button, PowerAppV2, and Skills triggers with `required` schemas. --- @@ -578,8 +594,10 @@ tool schemas cannot tell you. connectionReferences. Use `set_live_flow_state` to start/stop a flow. ### `trigger_live_flow` -- **Only works for HTTP Request triggers.** Returns error for Recurrence, connector, - and other trigger types. +- **Works for HTTP, Button, and PowerApps triggers.** Returns error for Recurrence, + connector, and other trigger types. +- Pass trigger inputs as `body`. A `warning` in the result means a required input + was missing and the run started with it null. - AAD-authenticated triggers are handled automatically (impersonated Bearer token). ### `get_live_flow_runs`