Rencore
Power Platform sprawl: the citizen-developer reality check
Five years into the citizen-developer pitch, the Power Platform estate in most tenants we scan does not match the original story. The good news is that the patterns are now well-understood, and the cleanup playbook is repeatable.
Power Platform sprawl is the accumulation of orphaned, unused, and under-governed Power Apps, Power Automate flows, and Power Pages sites across a Microsoft 365 tenant. Five years into the citizen-developer movement, most environments show the same pattern: a small number of business-critical apps, a larger middle layer of departmental tools, and a long tail of abandoned experiments. The original pitch underestimated the lifecycle cost of that long tail, and 2026 is the year IT teams are confronting the bill.
The citizen-developer pitch, every employee a maker, every workflow a candidate for automation, has been one of Microsoft’s clearest narratives for five years. The pitch was not wrong. The execution turned out to be more nuanced than the slideware suggested.
Across the Microsoft 365 environments we scan in 2026, the Power Platform estate tends to fall into three layers, and the governance work is layer-specific.
Layer one: the business-critical core (small, well-known)
Every tenant has a small set of Power Platform assets that genuinely matter. Apps that route customer requests, flows that reconcile finance data overnight, pages that serve as the internal directory for a particular function. These are usually well-known to IT because they break loudly when something goes wrong.
The governance question here is not discovery. It is resilience. Who owns this app? Where is the source-of-truth copy? What happens if the original maker leaves? Does the app meet the standards (sensitivity labels on the data, DLP policies, audit logging) the rest of the M365 estate has to meet?
The answer for most tenants is “partially.” The business-critical layer is small enough to govern by hand. Most teams do, badly, because the documentation is in a OneNote somewhere and the resilience plan is “we will figure it out if it breaks.”
Layer two: departmental tools (medium, partly known)
The middle layer is where the citizen-developer story actually delivered. Forms, approval flows, simple data-entry apps that replaced shared Excel files. These tools are useful, they make work better, and they are usually built well enough.
The problem is volume and ownership decay. A tenant with 5,000 seats might have several thousand departmental Power Apps and Power Automate flows. Each was built by someone. Each is currently owned by someone. The match between the two changes constantly as people change roles.
The governance task here is keeping ownership current and the resources within policy. Sensitivity-label inheritance, connector restrictions (no production data flowing into personal accounts, for example), DLP boundaries between business and consumer connectors. The tooling has improved in Power Platform admin centre, but the operating discipline still has to come from somewhere.
Layer three: the abandoned experiments (long tail, unknown)
The long tail is where the citizen-developer narrative breaks. Apps built for a one-off campaign, flows that automated something for two weeks, pages launched and forgotten. The vast majority of Power Platform resources in mature tenants fall into this layer.
Each individual abandoned app is low risk. The aggregate is not. Three reasons:
Credential debt. Each abandoned flow holds credentials for one or more connectors. Each credential is a potential exposure if the flow itself is compromised or the connected service is breached. Multiplied across thousands of forgotten flows, the credential surface is real.
Data-source leakage. Abandoned apps point at SharePoint sites, Dataverse tables, or external connectors that may have been re-permissioned over time. The app does not know. If anyone runs it, it gets whatever it can.
Cost noise. Most abandoned resources cost little individually. Some do not. Premium connectors, Dataverse capacity, Power Pages anonymous access, can accumulate spend that nobody is watching.
The cleanup playbook that works
The honest framing for Power Platform in 2026 is that “every employee a maker” needs to be paired with “every resource has a lifecycle.” Three steps.
Inventory by layer. Tag each resource as business-critical, departmental, or experimental, using a combination of usage signals, owner activity, and policy compliance. Rencore inventories Power Apps, Power Automate flows, Power Pages sites, and Dataverse environments with that classification context built in.
Apply lifecycle policy by layer. Business-critical resources get the full review treatment, named owner, documented resilience, label compliance. Departmental tools get periodic ownership reaffirmation and connector-policy checks. Experimental resources get an automatic decay clock, 90 days inactive, archive with notification; 180 days inactive, delete.
Make the platform owner a real role. Power Platform sprawl is not solved by tooling alone. Someone needs to own the operating model, set the policy, and run the cycles. In tenants where governance is working, that is a named role with a defined remit, not a part-time responsibility on top of someone’s day job.
The citizen-developer pitch was never wrong. It was incomplete. The 2026 work is finishing the sentence.
See how Rencore governs Power Platform alongside the rest of M365, or book a Power Platform review.
