Speaker A
Nobody wants to document old flows by hand. If you've ever opened a five-year-old flow somebody else built, you know the feeling.
Learn 3 AI-powered methods to bulk document Power Automate flows with SharePoint integration using Flow Studio MCP and Copilot Studio.
Key Takeaways
- Automating flow documentation saves significant manual effort and improves maintainability.
- Using AI agents combined with Flow Studio MCP enables bulk processing and consistent output.
- Direct SharePoint site page creation requires specific permissions, but fallback options exist.
- Microsoft 365 Copilot tools can generate documentation in various formats but have some limitations.
- Security and permission scoping are critical when automating SharePoint writes.
Summary
- The video addresses the challenge of manually documenting old and complex Power Automate flows.
- It introduces three AI agent-based paths to automate documentation, producing consistent output with a SharePoint inventory list and per-flow documentation pages or files.
- Path 1 uses a developer AI coding agent with Flow Studio MCP and a SharePoint service principal for direct page creation, offering the fastest runtime.
- If service principal permissions are restricted, Path 1 can fallback to using Power Automate helper flows for SharePoint writes.
- Path 2 operates fully within Microsoft 365 using a Copilot Studio agent with Work IQ SharePoint Preview and Flow Studio MCP, outputting Word, PDF, or Markdown files instead of site pages.
- Path 2 is simpler but limited by Work IQ’s inability to create SharePoint site pages and render Mermaid charts inline.
- Path 3 combines the Copilot Studio agent with a Power Automate dispatcher flow that performs controlled SharePoint REST operations, enabling site page creation without broad write permissions.
- All paths use a consistent documentation spec with an inventory list and detailed per-flow sections including basics, process, flow chart, and appendix.
- The video emphasizes security considerations, such as scoped permissions and signed-in user access for SharePoint writes.
- The presenter demonstrates prompts used to pilot and batch documentation generation, highlighting iterative validation before full execution.
Full Transcript — Download SRT & Markdown
Speaker A
For one complex flow, it's already possible that you can export the JSON, paste the definition into ChatGPT, and ask it to explain what the flow does.
Speaker A
But that still means I have to feed the flow in one by one, and that's exactly the manual work I'm trying to avoid.
Speaker A
What I want from an agent is a bulk version. Read every flow, write one document per flow, and register each one in a list I can search without me spoon-feeding it.
Speaker A
And so I built that three ways. Let me show you the output first, and all three produce the same thing.
Speaker A
So I used the same documentation spec across all three solutions. There are two pieces: one inventory SharePoint list, and one SharePoint page per flow.
Speaker A
The inventory list is one row per flow with six essential fields. It works like a quick lookup library, so I can jump either to the flow itself or to the documentation page.
Speaker A
The per-flow doc is the drill-down with seven sections that cover the details. They are on screen: the basics first, then the process, then the flow chart, and then the appendix.
Speaker A
A list with pages, that's the spec. You will see the same spec produced three ways.
Speaker A
One more thing, the agent doesn't need a pre-built template page. It builds every documentation page with the same structure from one prompt.
Speaker A
You will see the prompt in a minute. Okay, Path 1. Path 1 is the developer path, an AI coding agent inside an IDE, such as Claude Code, GitHub Copilot, that kind of thing. You need Flow Studio MCP to read the flows,
Speaker A
and you need a write path into SharePoint. In my first version, that write path is a SharePoint service principal, scoped with Sites.Selected to one site. If your tenant cannot grant that, the fallback is to have the agent call helper flows that create pages and update list items.
Speaker A
It is more setup, but the agent can create the helper flows and do most of the heavy lifting.
Speaker A
And output goes straight onto SharePoint Site Pages. This is the fastest of the three at runtime.
Speaker A
The environment I tested has 46 flows, and this is the prompt I gave the agent.
Speaker A
Document every flow in the Flow Studio Demo environment. Create a SharePoint list called FlowDocsInventory with these six columns. For each flow, create a site page with these seven sections, add an inventory row, and group similar flows so I can sanity-check three before you batch the rest.
Speaker A
I asked the agent to run three flows first, so I could check the output before letting it continue with the remaining 43. The agent picks three flows, drafts a document page for each, registers them in the inventory list. I read those three pages, decide whether the section spec is
Speaker A
producing what I want, and only then do I tell it to batch the remaining 43. The agent uses Flow Studio MCP to list environments, list flows, and read each flow definition.
Speaker A
Then it writes pages and inventory rows to SharePoint through Microsoft Graph. The second half is where the service principal comes in. The agent is not signed in as me.
Speaker A
It is an Azure app registration. It is scoped with one permission, Sites.Selected, granted on one SharePoint site. It can read and write to that one site and only that site.
Speaker A
What gets created in SharePoint is exactly what I asked for in the prompt. I asked it to document three flows, and it produced three Site Pages and added three inventory rows.
Speaker A
Each row links to the site page URL and the underlying flow URL. Now look at the pages. Same template is being used no matter how complex the flow.
Speaker A
The complex flow has more actions and longer descriptions, and the simple one only has a few actions, but the template structure is the same. If the app registration grant is blocked, you can swap the write side for a Power Automate dispatcher flow. That fallback
Speaker A
matters because not every organization will approve a service principal writing to SharePoint. In that case, an agent calls a Power Automate flow, and the flow does the SharePoint write.
Speaker A
Though, the direct service principal route is the quickest, and the fastest setup is to ask the agent to do the Azure work for you. So you can tell the agent: create a service principal with Sites.Selected scope so you can manage the site for me. Use Azure CLI to create it.
Speaker A
Your agent may need you to sign in to az once. After that, it can create the app registration, scope it, and save the secret for the project. I worked through that pattern in an earlier post.
Speaker A
The link is below. That is Path 1, fastest with service principal. Still workable with the dispatcher fallback. On to Path 2.
Speaker A
Path 2 is completely under Microsoft 365. You need one Copilot Studio agent with two tools added to the agent. The spec is the same.
Speaker A
The output can be Word documents or MD files or PDFs in a SharePoint document library. It cannot produce Site Pages.
Speaker A
The first tool is Work IQ SharePoint Preview. You can add it to the agent via Add a tool, search it, connect, create an authenticated connection, and add the tool.
Speaker A
And this is the Microsoft preview SharePoint tool for Copilot Studio agents. It can create documents in SharePoint, but not Site Pages at the moment.
Speaker A
The second tool is Flow Studio MCP. The same one I used in Path 1. So the same pattern: click Add tool, select Model Context Protocol, give it a server name, use mcp.flowstudio.app/mcp as the URL with API key.
Speaker A
Add the header name as x-api-key, create a connection with your Flow Studio MCP token. It is free to obtain from mcp.flowstudio.app.
Speaker A
So now the agent can use Work IQ to read the SharePoint site, create files in the document library, and write rows to the inventory list.
Speaker A
And it can use Flow Studio MCP to read the flow definitions within the Copilot Studio surface.
Speaker A
The trade-off is the output format, as Work IQ does not support page creation. And this path is relatively simple as long as you have an M365 Copilot license.
Speaker A
And the prompt I have here is similar to Path 1. Document the flows in the Flow Studio Demo environment. For each flow, create a Word document with these seven sections.
Speaker A
Save it into a library called CopilotDoc. And then add a row to FlowDocsInventory2 with these six fields.
Speaker A
Start with three flows for the pilot. And the agent goes through it step by step.
Speaker A
list_live_environments, list_live_flows, get_live_flow on each. Then Work IQ to write the documentation. Then Work IQ to add the inventory row. So the outcome is we got three Word documents and three inventory rows.
Speaker A
You can see the tool calls in the test pane. This is easy to audit. But here is the wall.
Speaker A
In my setup, Work IQ SharePoint gave me file and list operations, not the site page write path.
Speaker A
It writes Word documents and list items, not SharePoint Site Pages. And another trade-off is the Mermaid chart.
Speaker A
It is not rendered as raw text in Word. And if you want it rendered on the site page with a diagram visible inline, we have Path 3.
Speaker A
And one security note: we created a write-capable agent. And the Work IQ action follows the signed-in user's access.
Speaker A
So consider the security before you share the agent broadly. Now on to Path 3.
Speaker A
For Path 3, we use the same Copilot Studio agent in Path 2. It already has Work IQ SharePoint Preview to handle writing to the inventory list and Flow Studio MCP to read the flow definitions.
Speaker A
What we are adding is a Power Automate helper flow. We call it the dispatcher for site page writes.
Speaker A
The agent calls the flow, and the flow does the writes. It picks an action from a closed list.
Speaker A
The flow routes to the right SharePoint REST endpoint. The write happens inside the flow.
Speaker A
So it has eight operations. List, read, create, checkout, modify, publish, discard, recycle. So this flow is added to the agent as a tool.
Speaker A
And the agent does not get open-ended SharePoint write access. It gets exactly eight named operations.
Speaker A
So if you want it to publish a page, it calls Create, Checkout, Modify, Publish.
Speaker A
If you want it to soft-delete, it calls Recycle. This is a slightly complex flo...
Speaker A
I had the agent build the dispatcher flow itself using Flow Studio MCP. If you want your agent to build this for you, just send the blog post in the link with a screenshot for the flow actions to your agent.
Speaker A
Your agent can build this. The flow build may not be perfect in one go, but just as with a human developer, you ask your agent to test run it with all the actions and inspect the flow run history,
Speaker A
input and output. Your agent can debug and fix with minimal input from you. You will need to remember to ask the agent to add this flow to a solution so the flow can be discovered in Copilot Studio.
Speaker A
And here I want to add more details on the wiring, as it took me some time to get it right.
Speaker A
Wiring the dispatcher into Copilot Studio took more manual configuration. The input tool config is important, as we need to add inputs one by one and define the details.
Speaker A
The blog post has it explained in detail. The key is that you need to create a closed list for the eight actions in the flow for the action input property.
Speaker A
And for the remaining optional inputs such as page ID, page name, etc., expand Advanced settings and set How many reprompts to Don't repeat.
Speaker A
And Action if no entity found to Set variable to empty, no value. And more importantly, you have to toggle Should prompt user to on, save it, and toggle off and save again.
Speaker A
These steps ensure the agent will not come to ask for information that's optional. You would also want to add one line in the agent instructions.
Speaker A
The details are in the blog post. These details matter, especially the input save cycle.
Speaker A
Make sure you go through the details. And now with the same prompts, we see three Site Pages on MCP Demo, page IDs 11, 12, 13.
Speaker A
Three matching inventory rows, verified end-to-end. All three pages were created through the dispatcher flow, and the three inventory rows were added through Work IQ.
Speaker A
That is Path 3. This is the most controlled pattern. It is the easiest to govern, but the hardest to set up the first time.
Speaker A
Okay, so which one do you actually pick? Now we see the three paths. They share the same spec but have different trade-offs.
Speaker A
Path 1, the IDE agent. You need a developer in the room. This is the fastest setup with a service principal. It still works with the dispatcher flow if Azure is blocked.
Speaker A
Path 2, Copilot Studio agent plus Work IQ. This is the easiest if your team lives inside M365.
Speaker A
The constraint is the output, as it cannot generate Site Pages. Path 3 is the same Copilot Studio agent with the dispatcher flow. It is the most controlled version.
Speaker A
It produces real Site Pages, does not require app registration, and writes pages through the flow connection.
Speaker A
If one of these paths fits your tenant, I wrote up the full build details in three blog posts.
Speaker A
One article per path, links are below. Subscribe if you want more practical ways to use AI agents with Power Automate.
Topics:Power AutomateFlow Studio MCPAI agentsSharePoint documentationMicrosoft 365 CopilotPower Automate flowsautomationservice principalFlow documentationPower Automate helper flows
