power-automate-documentation

You are producing a technical reference document for a Power Automate solution export: what each flow does, in plain English, and every place it reaches outside itself to read, write, or delete data. The source of truth is always the JSON inside the solution zip, never the flow's display name or your assumptions about what a flow "probably" does.

Inventory before you narrate. The failure mode to avoid: skimming a flow's JSON, writing a plausible-sounding summary, and closing with a note that "a fuller audit would require deeper parsing." If you ever find yourself about to write a sentence like that, it means you skipped the inventory step below — go back and do it, don't disclose the shortcut instead of taking it. Every action in every flow gets listed and accounted for; there is no partial-credit version of this task.

Solution Zip Anatomy

An unpacked solution zip has this shape:

• solution.xml — SolutionManifest: UniqueName, Version, Managed (0 = unmanaged, 1 = managed), Publisher.
• customizations.xml — a <Workflows> element listing every flow in the solution, and a <connectionreferences> element. WorkflowId and Name are always attributes on <Workflow>; everything else (JsonFileName, Category, StateCode, StatusCode, ...) appears as attributes in compact/hand-built exports but as child elements in full Dataverse exports (e.g. via pac solution unpack or a live environment export) — read whichever form is present. When StateCode/StatusCode are present, 0/1 means the flow is Draft (off) and 1/2 means it's Activated (on) — worth a one-line note per flow. <connectionreferences> is often empty even when flows use connectors — the connection is then resolved through the flow JSON itself (see below). Real Dataverse exports may instead ship one file per connection reference under a top-level connectionreferences/ folder — check for that folder too, and treat it as the same information as an inline <connectionreferences> entry.
• Workflows/*.json — one file per flow, keyed at properties.definition.triggers and properties.definition.actions, using the standard Logic Apps workflow-definition schema. Full exports also carry properties.connectionReferences — see below.

If more than one solution zip is provided in the same request, treat each as an independent solution for the per-flow steps below, but pool their flow-ID maps before resolving child-flow calls, so a call in one zip can resolve to a flow shipped in another.

Resolving connection references

A connector action's inputs.host.connectionName (e.g. "shared_sharepointonline") is not itself the declared connection reference — it's a short key into the flow's own properties.connectionReferences block: