--- title: "Microsoft Power Automate Integration" description: "Microsoft Power Automate is Microsoft's cloud workflow service. Agents list, turn on, and turn off cloud and desktop flows through the Dataverse Web API, read and write any Dataverse table in the environment, export and import solutions, and call a flow's HTTP request trigger." url: https://flowrunner.ai/integrations/microsoft-power-automate date_modified: 2026-09-04T14:52:04-07:00 --- # Microsoft Power Automate [Productivity](https://flowrunner.ai/integrations/category/project-management-productivity) Microsoft Power Automate is Microsoft's cloud workflow service. Agents list, turn on, and turn off cloud and desktop flows through the Dataverse Web API, read and write any Dataverse table in the environment, export and import solutions, and call a flow's HTTP request trigger. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 16 actions · OAuth · available [Microsoft Power Automate website](https://contoso.crm.dynamics.com/) · [Platform Documentation](https://learn.microsoft.com/en-us/power-automate/web-api) · Capability data verified 2026-08-24 1. A weekly estate review starts, or a change request asks to promote a flow into production 2. List Solutions returns the containers the environment holds, and List Flows reads the cloud flows inside them 3. Get Flow pulls each flow's full definition and its connection references out of the \`clientdata\` column 4. The agent compares the source environment's definitions against the destination and lists what would change 5. Get Who I Am confirms the connection is pointed at the environment the change request names, not a similarly named one 6. The diff reaches the platform owner with the flows affected, the connection references they carry, and the customizations at risk 7. The platform owner approves the promotion, and only then does the agent call Import Solution against production ## What This Integration Enables Power Automate has no management API of its own. Microsoft's own reference for managing cloud flows with code documents the Dataverse Web API, because a cloud flow is a row in the Dataverse `workflow` table. Everything this connector does for flow management is an OData call against that table, which has two consequences worth stating plainly before anyone builds on it: only flows that live in a solution can be managed this way, and the environment has to have Dataverse behind it. Where neither holds, Call Flow Trigger still works, because it posts to a flow's own generated HTTP URL and needs no Dataverse and no connection credentials at all. That constraint is also the opportunity. FlowRunner agents list solutions and flows, read and write flow definitions, turn flows on and off through the `statecode` column, export and import whole solutions, and read or write any Dataverse table in the environment. In other words, a FlowRunner agent can hold an inventory of an existing Power Automate estate and act on it. This is the shape [Orchestration as a Service](https://flowrunner.ai/concepts/orchestration-as-a-service) is meant for: FlowRunner does not ask a company to throw away the automation it already runs, it sits above that estate, keeps a record of it, and puts a person in front of the changes that reach production. Every action is built and verified against the Dataverse Web API that Microsoft publishes for this purpose. ### Without FlowRunner **An estate nobody has a list of**: Flows accumulate across environments and departments with no current inventory of what runs where **Promotion by hand**: Moving a flow between environments is a manual export, download, and upload with no record of what changed **Silent divergence**: Somebody edits a flow directly in production, and the next promotion quietly reverses their work ### With FlowRunner **A living inventory**: An agent reads solutions, flows, and definitions on a schedule and writes the estate to somewhere people can read it **Promotion with a diff**: The export, the comparison, and the change list are produced before anyone is asked to approve anything **Overwrites are a named decision**: The one call that discards hand made changes in production waits for the person who owns that environment ## Use Case Scenarios ### The inventory nobody has time to build On a schedule, the agent calls List Solutions to enumerate the containers in the environment, then List Flows to read the cloud flows inside them. Because that same table also holds classic Dynamics workflows, dialogs, business rules, and business process flows, the read is filtered to modern cloud flows rather than returning everything and hoping. Get Flow pulls each definition and its connection references. The result lands in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) or a table in [Airtable](https://flowrunner.ai/integrations/airtable), with owner, state, and last modified alongside each flow. A digest posts to [Microsoft Teams](https://flowrunner.ai/integrations/microsoft-teams) naming what was added, what was turned off, and what nobody has touched in a year. Nothing changes in the estate. The point of the sweep is that somebody can finally answer the question. ### A flow that stopped, handled as an exception rather than a ticket When monitoring shows a business process has gone quiet, the agent reads the relevant flow with Get Flow and checks its state. A flow that has been switched to Draft is a different problem from one that is running and failing, and the agent says which. Where the correct fix is to bring the flow back, Set Flow State is a single `statecode` write and the agent proposes it. Where the flow is running but its underlying rows are wrong, the agent reads and repairs those directly with List Records and Update Record against the Dataverse table involved, then posts the before and after into the [Slack](https://flowrunner.ai/integrations/slack) thread where the incident is being worked. The recovery and the record of the recovery are the same act. ### FlowRunner as the layer above an existing estate A workflow that starts in FlowRunner reaches a step that an existing Power Automate flow already does well. Instead of rebuilding it, the agent calls Call Flow Trigger against that flow's own HTTP request trigger and carries on. This is worth being precise about: that URL carries its own signature in the query string, so it is a secret in its own right, and anyone holding it can start the flow. Treat it as a credential, not as an address. The value of the pattern is that a company with years of Power Automate work behind it can put FlowRunner's judgment steps and [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gates around that work without a migration project. ## Human-in-Loop Highlight Import Solution is the operation that earns this page's gate. It writes into the destination environment, and its Overwrite Unmanaged Customizations option discards changes people made there by hand. Those changes are usually the fixes somebody applied in production during an incident, and they are frequently not written down anywhere else. So the promotion agent does the whole job up to that call and then stops. It exports the source solution, reads the destination's current flows and definitions, and posts to the platform owner: "Promoting solution 'AP Intake v4' into Production. Six flows change definition, two gain new connection references, and one flow in the destination was modified by hand on August 19 and is not in the source. Overwrite unmanaged customizations, or promote without overwrite and leave that flow alone?" The platform owner answers, and the agent makes exactly the call that was approved. What made the promotion safe was not the agent's diffing. It was that the write into production had a named owner. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 16 actions ### Flows 7 - **List Flows** Returns cloud flows from the environment's Dataverse \`workflow\` table. Defaults to modern cloud flows, because that table also carries classic Dynamics workflows, dialogs, business rules, and business process flows. - **Get Flow** Returns one flow by its workflow id. Its \`clientdata\` column holds the whole definition and its connection references, which is what a backup or a promotion between environments needs. - **Create Flow** Creates a cloud flow from a definition. Dataverse stores that definition serialized into a single column, so the connector handles the stringification rather than making a workflow do it. - **Update Flow** Changes a flow's name, description, or definition, and asks Dataverse for the updated row back so a workflow can read what it just wrote. - **Set Flow State** Turns a flow on or off. There is no route for this in the API; it is a \`statecode\` write, and that is the entire mechanism. - **Delete Flow** Deletes a flow's definition, and it cannot be undone. Turning the flow off with Set Flow State is almost always the intent, so a workflow that reaches for this one should be deliberate about it. - **Call Flow Trigger** Calls a flow's own HTTP request trigger by posting to its generated URL. It does not use the connection's credentials, because that URL carries its own signature and is a secret in its own right. ### Solutions 3 - **List Solutions** Returns the solutions in the environment. Only flows that live in a solution can be managed through this API at all, so this is where a workflow finds which container it is allowed to work in. - **Export Solution** Exports a solution as a base64 encoded archive. This is the supported way to move a set of flows between environments wholesale. - **Import Solution** Imports a solution into an environment. It changes the destination, and its overwrite option discards hand made customizations there, which is why this page's human gate sits in front of it. ### Dataverse 6 - **List Records** Reads rows from any Dataverse table in the environment. The table is named by its OData entity set name, which is the plural logical name. - **Get Record** Reads one Dataverse row by its primary key. - **Create Record** Creates a Dataverse row, including lookups, which are set through the binding syntax rather than with a plain id. - **Update Record** Changes a Dataverse row. A Dataverse update is an upsert by default, so an id that does not exist creates a row rather than failing, and workflows should be written knowing that. - **Delete Record** Deletes a Dataverse row. - **Get Who I Am** Returns the signed in user's Dataverse identity, business unit, and organization id. The cheapest way for a workflow to confirm it is pointed at the environment it thinks it is. ## Frequently Asked Questions ### What can FlowRunner do with Microsoft Power Automate? FlowRunner agents can run List Flows, Get Flow, and Create Flow in Microsoft Power Automate, plus 13 more actions. ### Does connecting Microsoft Power Automate to FlowRunner require OAuth? Yes. Microsoft Power Automate connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials. ### Can Microsoft Power Automate trigger a FlowRunner workflow automatically? Microsoft Power Automate doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Microsoft Power Automate?** This integration exposes Microsoft Power Automate to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/microsoft-power-automate. Site index: https://flowrunner.ai/llms.txt