PowerDocu turns Power Platform exports into technical documentation

The problem with documenting low code artefacts by hand

Power Platform work accumulates quickly and quietly. A flow is built in Power Automate, a canvas app in Power Apps, an agent in Copilot Studio, and each one grows connectors, triggers, actions, data sources and screens. The README states the problem plainly: after you have built any of these, you may want to document it so that others can better understand how it works, to keep a record of a specific configuration somewhere else, or for other reasons, and manually documenting the technical implementation can be quite time consuming.

That last clause is the whole justification. A flow is a graph of actions, and describing it by hand means reading the designer and writing down the same information twice, once for the person who built it and once for whoever inherits it.

PowerDocu answers with a Windows GUI executable that performs the documentation automatically. The artefact types it covers are Cloud Flows, Canvas Apps, Model-Driven Apps, Copilot Studio Agents, AI Models and Solutions, with a solution covering all the components it contains. The output can be a Word document, HTML, or Markdown, and the README suggests Markdown specifically for hosting on GitHub or Azure DevOps, which tells you who the tool is aimed at: teams whose documentation already lives in a repository next to the code.

The project is MIT licensed, built on .NET 10, and the last push to the repository was on 2026-08-06. The most recent releases are v3.0.1 on 2026-03-25, v3.0.0 on 2026-03-18 and v2.5.0 on 2026-02-26, so the 3.x line is a recent major step and the project is moving.

A solution file with one documenter project per artefact type

The repository layout explains how the tool is put together, and it is a clean answer to a question that is otherwise awkward. Instead of one program with a switch statement, PowerDocu is a Visual Studio solution with a separate project per artefact type.

There is PowerDocu.FlowDocumenter for flows, PowerDocu.AppDocumenter for canvas apps, PowerDocu.AppModuleDocumenter for app modules, PowerDocu.AgentDocumenter for Copilot Studio agents, PowerDocu.AIModelDocumenter for AI models, and PowerDocu.SolutionDocumenter for solutions. Two more cover the flows that are not the ordinary cloud flow kind: PowerDocu.ClassicWorkflowDocumenter and PowerDocu.DataflowDocumenter, plus PowerDocu.DesktopFlowDocumenter for the desktop flow variant and PowerDocu.BPFDocumenter. The GUI itself is PowerDocu.GUI, and the whole set is tied together by PowerDocu.sln.

The reason this shape pays off is that a solution documenter can delegate. When you document a solution, the README lists what you get: documentation for each canvas app inside it, for each cloud flow, for each model-driven app, for each agent, for each AI model, plus details of the solution itself including a list of all components and the documented Dataverse tables. The solution documenter composes the per-type documenters rather than reimplementing them.

The repository also carries a modules directory alongside a .gitmodules file, which indicates that some parsing code is pulled in as git submodules rather than vendored into this tree. There is a compile.md for building from source, a roadmap.md, a softwarereferences.md listing the external tools whose formats are being read, and a CLAUDE.md recording the conventions used when working on the code with AI assistance.

What a generated flow document contains

The README spells out the document structure per artefact type, and the flow document is the most detailed, so it is the clearest way to judge the depth of the output.

A Cloud Flow or Agent Flow document contains a generated Word document, HTML or Markdown with sections on the general information of the flow, the connectors it uses, the trigger that starts it, the actions it performs, and both a high-level and a detailed diagram of the flow. The diagrams are additionally produced as PNG and SVG renditions.

That list is worth pausing on. The connectors section is the part that answers the question people actually ask about a flow they did not build, which is what it talks to. The trigger and actions sections are the readable form of the design canvas, and the two diagram levels serve different readers, with the high-level view for someone who wants the shape and the detailed view for someone who has to change it.

The PNG and SVG output is a practical choice rather than a decorative one. SVG scales, which matters for a document that will be viewed at different sizes, and having both formats means the diagram can go into a Word document and into a repository README without a conversion step.

For a flow, then, the generated artefact is a description of structure and configuration: what triggers it, what it calls, what it does. It says nothing about why any of that is the way it is, which is the boundary of the tool and the boundary of the output.

Apps, agents and solutions have their own document shapes

Each artefact type gets a document designed for what that artefact actually contains, rather than one generic template.

For a Canvas App, the document covers the general information of the app and its properties, the global variables and collections used in the app together with the controls that use them, the data sources used, the resources used, an overview of the screens and the controls inside them, and a detailed list of all controls with all their properties. That last item is the expensive one to write by hand, since a canvas app's value is in its controls and their properties, and that inventory is what an inheritor needs.

For a Model-Driven App, the sections are general information and metadata, security roles and permissions, a site map visualisation, associated tables and views, custom pages, and app settings and resources. The site map visualisation and the security roles section are the two that carry the most institutional knowledge in a model-driven app, since they are usually the parts nobody reconstructs from memory.

For a Copilot Studio Agent, the document covers agent metadata, description and instructions, knowledge sources, tools, actions and connected services, topics, triggers and activation methods, entities and variables, and flow graphs for each topic together with data flow diagrams across topics.

An AI Model gets a much smaller document with the model metadata and configuration, which is proportionate. A solution document is the aggregation described earlier, adding the list of components and the documented Dataverse tables.

The four step workflow, from download to output folder

The getting started section describes a GUI workflow with four steps, and the details matter because two of them are easy to miss.

The first step is to download the latest release from the Releases page, with a choice between the version that requires .NET installed and a standalone package that includes everything. That choice is the difference between a small download and a large one, and it is a decision about whether the target machine has the runtime.

The second step is running PowerDocu.exe and going to the Settings tab, where you select the output format, Word, Markdown, HTML or all of them, and adjust the documentation options as needed. The button to save the current configuration as default is what makes the tool usable in a repeated workflow, because otherwise every run starts from the same defaults. The settings.md document in the repository holds the full list of options.

The third step is the one people skip. There is a green download icon in the Other Options section that updates connector icons, and its purpose is to ensure the documentation includes the latest connector icons. Skipping it means the generated document shows stale or missing artwork for the services your flow depends on, which is exactly the kind of detail a reader notices and distrusts.

The fourth step is generation: click Next, then select the exported file, whether an exported Flow as a .zip, a Canvas App as a .msapp, or a Solution as a .zip, and the documentation appears in a subfolder next to the source file.

That last point defines the architecture. PowerDocu works from exported artefact files, not from a live connection to a tenant, which is what makes the standalone package a realistic option and why the export step, documented in installation.md, is a prerequisite rather than an afterthought.

Windows, .NET 10 and a tool that is still moving

The constraints are visible in the packaging. This is a Windows GUI executable, the badge names .NET 10.0, and the installation is either a self-contained package or a version that needs the runtime. For a team whose documentation pipeline runs on a build agent, that means a Windows runner, which is a real constraint even if the tool itself is straightforward.

The release line is worth tracking. Version 3.0.0 landed on 2026-03-18 and 3.0.1 followed a week later on 2026-03-25, after 2.5.0 in February. A major version arriving means the output format and the options can change between versions, so documentation generated with 2.x is not guaranteed to match documentation generated with 3.x, which matters if you diff generated documents over time or publish them on a schedule.

The last push was on 2026-08-06, and the repository is not archived. The presence of a roadmap.md is a signal that the author is planning further work, and the open invitation at the end of the README is specific: bugs go to issues, improvement suggestions go to discussions, and code contributions come as pull requests.

The examples directory is the fastest way to judge the output before running anything. It holds a generated app document, a generated flow document for a flow that emails a list of upcoming calendar events, and a solution export, with examples.md tying them together. Those are the artefacts to read first, because they show the real shape of a generated document rather than a description of one.

Editorial conclusion

PowerDocu fits a Power Platform team whose artefacts have grown past the point where anyone remembers what a flow or a canvas app does, and who need a Word or Markdown record of the connectors, triggers, actions, controls and tables involved, generated from the artefacts themselves rather than from memory. It is the wrong choice for a team that wants documentation with narrative, since the output describes structure and configuration rather than intent, and it is the wrong choice on anything but Windows, because the deliverable is a GUI executable. Before adopting it, export one representative flow and one app and read the generated document against your own understanding of the artefact, check the connector icon update step so the output is not missing artwork, and treat the version you pin as the version your documentation pipeline depends on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. modery/PowerDocu on GitHub
4. README
5. Releases