Power Automate

Power Automate — operate cloud flows through Dataverse, honestly

Drive Microsoft Power Automate cloud flows from code: create, enable, update, list, and delete them, plus pull run history for debugging. This skill operates the live surface. Deciding what the flow should do and shaping its trigger→actions→error definition is design — that lives in ../automation-flows/SKILL.md; this skill wraps that definition, ships it, and manages it.

Read these three facts before you write a line — they set the boundary of what is even possible:

1. Only flows inside a Dataverse solution are code-manageable. Classic personal "My Flows" cannot be created or edited by code — the Microsoft docs say so explicitly. If the target is a My Flow, the honest answer is: move it into a solution first, or drive it by hand. There is no API workaround.
2. api.flow.microsoft.com is unsupported. Microsoft's own words: use it "at your own risk," it is subject to breaking changes. The supported programmatic surface is the Dataverse Web API (or the .NET SDK) against the workflow table. For admin-style operations the Power Automate Management connector is the other supported path.
3. The unified Power Platform API (api.powerplatform.com) is maturing fast. It already lists cloud flows (api-version 2024-10-01) and its Inventory API went GA in early 2026. It may eventually supersede the Dataverse path for flow management. Treat the Dataverse-vs-Power-Platform-API split as fast-moving — verify the current recommendation at author time.

Connect first — API vs MCP

Everything runs against your org's Dataverse Web API. Base URL: https://{org}.{region}.dynamics.com/api/data/v9.2 (find yours under Power Platform admin → your environment → developer resources). Auth is OAuth2 / Entra ID — a user token or, for CI, a service principal (app registration). For a service principal the org needs a Dataverse application user mapped to that app plus a security role; the token audience is the Dataverse URL. Full setup, including the delegated user_impersonation vs app .default scope split and the 401/403 causes, is in references/entra-auth-setup.md.

Put these in .env (never inline a secret in a flow or a script):

PA_DATAVERSE_URL=https://contoso.crm.dynamics.com   # no trailing slash, no /api/...
PA_TENANT_ID=<entra-tenant-guid>
PA_CLIENT_ID=<app-registration-client-id>
PA_CLIENT_SECRET=<app-registration-secret>          # service-principal flow only

When to use the REST API vs the MCP:

FlowStudio MCP is NOT Microsoft-affiliated — it is a de-facto third-party server (mcp.flowstudio.app/mcp). Microsoft's own MCP story is Copilot Studio consuming MCP servers and a Dataverse MCP, neither of which authors Power Automate flows. Flag the third-party dependency to anyone before wiring it into a pipeline.

The workflow table — the data model

Cloud flows are rows in the Dataverse Process (workflow) table. The columns that matter:

List the cloud flows that are on:

curl -s "$PA_DATAVERSE_URL/api/data/v9.2/workflows?\$filter=category eq 5 and statecode eq 1&\$select=name,statecode,type,workflowid" \
  -H "Authorization: Bearer $TOKEN" -H "OData-Version: 4.0" -H "Accept: application/json"

clientdata — the payload, and the trap that bites everyone

clientdata is a JSON string, not a nested JSON object. It is the serialized form of:

{
  "properties": {
    "connectionReferences": { "shared_commondataserviceforapps": { "runtimeSource": "embedded", "connection": {}, "api": { "name": "shared_commondataserviceforapps" } } },
    "definition": { "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#", "contentVersion": "1.0.0.0", "triggers": { }, "actions": { } }
  },
  "schemaVersion": "1.0.0.0"
}

Two load-bearing parts:

• definition — a Logic Apps workflow definition: triggers (exactly one) then actions. This is the design artifact. Do not invent it from scratch here — get the trigger→actions→branch→error shape from ../automation-flows/SKILL.md, then drop it into definition. Fastest reliable way to get a real one: build the flow once in the maker portal, export the solution, and copy its clientdata.
• connectionReferences — the map from the definition's connectors to actual connections. A flow whose connection references are not authorized will not turn on. In a solution these are connection-reference records the target environment must resolve; unresolved references are the #1 reason a PATCH statecode=1 "succeeds" but the flow never runs.

The trap: clientdata must be escaped into a string before it goes in the request body — a nested object is rejected. In a script, JSON.stringify(clientDataObject) and assign the result; do not paste the object raw. Full annotated example — plus the endpoint cheat-sheet (token, list/filter, create, enable, update, delete, ExportSolution, share), OData headers and error handling — in references/dataverse-web-api.md.