Almanac

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

feature-coe-starter-kit.mdv1 · history
CurrentApplies to AllUpdated last monthSource Microsoft Learn

What it does

A set of Microsoft-published solutions — Dataverse tables, cloud flows, canvas apps and Power BI reports — that build a tenant-wide inventory of Power Platform resources and layer governance, compliance and adoption tooling on top of it. It ships as a template you install and own, not as a service Microsoft runs for you.

Key facts

  • Modular. Core components carry the inventory and the sync flows; governance, audit log, nurture and innovation backlog components are installed separately as needed.
  • The foundation is a Dataverse data model plus scheduled flows that walk every environment in the tenant and record apps, flows, connectors, makers, connections and environments.
  • Governance components include the admin compliance detail request process — it iterates the inventory, checks apps and agents against thresholds you set, and prompts owners for a business justification when something is non-compliant.
  • The Compliance and adoption dashboard surfaces orphaned apps and flows, non-compliant resources and suspended flows.
  • Audit log collection has moved over time. The custom connector approach is deprecated; current guidance covers the Office 365 Management API and Microsoft Graph API routes.
  • Power BI dashboards join the inventory with organisational data so you can slice by department, city or country.
  • It's a template you're expected to modify. Microsoft documents how to extend and customise components.

When to use / skip

Install it when the client has enough Power Platform to have lost track of it — several environments, makers outside IT, and a real question about who owns what. The inventory alone justifies the effort at that scale. Skip it for a client with one or two environments and a known set of makers, where a PowerShell script and a spreadsheet will tell them the same thing without the running cost. The kit is genuinely useful and genuinely a product you now have to operate.

Configuration decisions

  • Which components you install. Core inventory first, always; governance and audit log only when someone will act on the output.
  • Which account or service principal owns the sync flows, and how you keep that identity alive across staff changes.
  • Which environment hosts the kit, and whether it gets Managed Environments, backup and the same change control as production.
  • Whether inventory runs the cloud flow way or the data export route, given the volume of API calls a large tenant generates.
  • Who reads the compliance dashboard and what happens when it says something. A dashboard with no owner is a slow way to build a backlog.

Gotchas

  • The maintenance cost is the story nobody tells. Microsoft ships updates regularly, and upgrading a customised installation is real work every time.
  • Inventory flows are heavy. On a large tenant they consume meaningful Power Platform request capacity and can trip throttling, which then leaves you with a partial inventory that looks complete.
  • If the setup account leaves, the whole kit stops. Use a service principal or a properly managed service account from the first install.
  • Audit log setup involves permissions in Microsoft 365 or Entra that the Power Platform admin may not hold. Budget the approvals separately.
  • The compliance process emails makers asking for justifications. Send that live without warning the business and you'll generate a support queue rather than compliance.

Consultant notes

  • Position the kit as a product the client will operate, with a named owner and a maintenance slot. Clients who receive it as a deliverable and nothing else have a broken installation within two release cycles.
  • Install core components first and let the inventory run for a few weeks before turning on anything that emails people. The first look at the real numbers usually changes the client's governance plan.
  • Resist customising early. Every change you make to the shipped components is a change you re-apply at every upgrade.
  • It's community-supported, not a supported Microsoft product. Say that out loud in the kickoff so nobody raises a Microsoft ticket in six months expecting an SLA.

Check for a new kit release before any governance workshop — the components move quickly.

Was this accurate?