Power Platform adoption tends to be reported in one figure: how many people are using it. Makers this quarter, apps created, flows running. The number goes up, the programme is declared a success, and the next budget is approved on the strength of it.
Microsoft’s own adoption maturity model says that is the wrong measure. In its words, a common misconception is that adoption relates primarily to usage or the number of users. Adoption is about using the technology effectively, and Microsoft concedes immediately that effectiveness is harder to define and measure.
That concession is the useful part. A usage figure is easy to produce and easy to grow, including in ways that make an estate worse. A maker community of two thousand people building apps nobody supports is a large usage number and a growing operational liability.
The model is a profile, not a score
The maturity model has five levels, and it is built on the Capability Maturity Model used widely in software and IT.
| Level | Name | Broadly |
| 100 | Initial | Ad hoc, driven bottom-up by business areas |
| 200 | Repeatable | Vision and goals defined, some structure emerging |
| 300 | Defined | Strategies, roles and processes established |
| 400 | Capable | Measured, managed, with a dedicated team |
| 500 | Efficient | Embedded in the organisation’s strategy and culture |
The levels apply separately to nine capability areas: strategy and vision, business value, security, governance, support, community, responsible AI, automation, and fusion teams.
Microsoft’s stated purpose for the model is to let an organisation decide the level it wants to achieve for each dimension, and the timeline. Not a single target. The model is designed to be uneven on purpose, and an organisation that sets out to reach 500 everywhere has misread it.
Microsoft also says there is no formal end to adoption efforts. That matters for how the work is funded. Adoption is not a project with a completion date, which is an argument this programme has made before about anything that has to be held rather than delivered.
Community is the dimension that outruns the others
Of the nine areas, community is the one that grows fastest without anyone pushing it, and that is exactly what makes it dangerous.
Look at the level 100 state for governance: environments creatable by all, no data policies, no sharing limits. Now look at the level 100 state for support: makers support their own apps, with no application lifecycle management. And community at 200 already has makers becoming ambassadors across their departments and evangelising the capabilities.
Put those together and you have the most common shape of Power Platform adoption, and the most common structural failure we see across enterprise tenants. A community at 200 or 300, with active Teams channels, lunch and learn sessions and eager makers, sitting on governance and support still at 100. Organisations evangelise maker activity before they have an intake process, application lifecycle management or tiered support. The usage number looks excellent. Underneath it is a growing set of apps built in the default environment, supported by the person who built them, with nobody else able to maintain them.
The defaults that produce that shape are covered in how Power Platform governance starts with a setting nobody chose.
What happens when a maker leaves
This is the moment the imbalance becomes visible. At support level 100, the only person who can maintain an app is its maker. When that person changes role or leaves, the app has no owner, often no documentation, and frequently a business process depending on it.
Microsoft’s level 300 answer is a defined risk profile that decides how much support a solution receives: IT supported, IT blessed, or maker supported. That classification is the thing that stops a personal productivity app and a business-critical process being treated identically. Most estates we see have no such classification, so central IT learns that an app is business-critical only when it breaks: after an unannounced platform change, an expired connection, or a leaver’s account being disabled. The model does not expect orphaned resources to be identified systematically until governance reaches level 400, which is why an estate at 100 finds them this way.
The last of those is the most abrupt. Microsoft’s troubleshooting guidance states that when the account that created a connection is deleted or disabled, the connection becomes invalid and affects every user who shares it. Anything built on that connection can stop working the same day.
An app nobody knew was critical
One engagement shows the whole sequence. At a mid-sized healthcare and logistics provider, central IT assumed the default environment held only personal productivity helpers. In fact a regional operations coordinator had built a canvas app on a personal SharePoint list to run daily temporary staff scheduling and site dispatch across eight facilities.
When the coordinator left, their Entra account was deactivated under standard offboarding. By the next morning dispatch had stopped completely, and a production P1 incident was open. IT spent three hours tracing the app’s dependencies, locating the orphaned list and moving ownership to a service account.
Offboarding did what it was designed to do. What was missing was any record that a business process depended on one person’s account, and a support tier that would have brought the app to IT’s attention before that account was switched off. The recovery route exists, since a Power Platform admin can set a new owner for an app when the original owner is unavailable, but by then the incident has already happened.
How common it is
In the unmanaged enterprise estates we assess, roughly 25% to 35% of canvas apps and cloud flows have no active, licensed owner: the maker has changed role, lost their licence or left. And 10% to 15% of the apps in the default environment are de facto business critical, running daily operational or departmental work with no application lifecycle management and no backup routine. That is the same share we found when looking at the governance defaults.
Not every orphaned app fails the morning after its maker leaves, as that one did. The immediate failures are the ones that depend on a connection created by the leaver’s account, which stops working on day one. The delayed failures are apps that depend on data in the maker’s personal OneDrive, such as an Excel table the app reads and writes. Those run quietly, and in our engagements they typically break 60 to 90 days after the maker departs. Microsoft’s lifecycle for a leaver’s storage explains the window: once a licence is removed, the OneDrive account becomes read-only after 60 unlicensed days and is archived after 93, at which point neither admins nor users can reach the content without an admin action.
Champions are usually found, not recruited
Microsoft’s guidance on champions contains one idea that runs against how most programmes start.
Champions are usually not asked to become champions. Microsoft describes them being identified by the CoE from what they are already doing, frequently answering questions in internal discussion channels or turning up to lunch and learn sessions. It goes further: someone might be acting as a champion without knowing it or receiving any formal recognition. And private invitation by the CoE is described as more common than asking people to self-identify.
It also offers a practical shortcut. Even before an organisation adopts Power Platform, it likely already knows who its champions are: the Excel, Access and SharePoint experts, the people who push boundaries and learn new things first.
That reframes the work in most organisations. The people who actually move adoption are the ones colleagues already ask, and the job is to notice them. In decentralised or technology-forward businesses we find them faster from tenant telemetry than from any announcement, starting with the top 5% of makers by run counts and shared apps. They are already building, and usually already helping colleagues.
Where a volunteer call works better
The exception is cultural, and common enough to plan for. In siloed, hierarchical or regulated organisations, such as the public sector, banking and traditional manufacturing, an open call for volunteers with explicit manager sign-off often works better than waiting to be noticed. In those environments organic makers frequently keep their tools out of sight, because they expect to be told to stop, or to have informal responsibilities added to the day job without recognition. An official, sponsored invitation makes the interest legitimate.
Microsoft’s guidance leaves room for both. It asks the CoE to choose which route to take, and to get manager approval where it is needed.
Two further points from the guidance are worth keeping. Champions are business representatives, not a support team, so a programme that quietly turns them into unpaid first-line support will burn them out. And champions can act as satellite members of the CoE, with genuine influence on environment strategy and on which connectors are available. That influence is a better reward than a badge, and Microsoft lists alternatives that matter to makers directly, such as a premium licence or an environment of their own.
The sequence Microsoft suggests
For building the community itself, Microsoft sets out seven steps:
- Define community purpose and goals
- Define core team roles and responsibilities
- Promote the community and establish partnerships
- Identify and support champions
- Onboard new community members and makers
- Celebrate successes
- Organise hackathons
Note where champions sit. Fourth, after purpose, roles and promotion. And note what is absent from the list entirely: support. The community sequence does not include deciding who maintains what gets built. That lives in a different capability area, and it is the one that most needs to move in step with community.
Microsoft’s model recommends a retired tool, twice
One contradiction is worth stating, because it will catch anyone using the model as a checklist.
At community level 300, the maturity model lists adopting the CoE Starter Kit Nurture module. At business value level 400, it lists adopting the Business Value toolkit, which is a feature of the same kit. Microsoft’s own CoE Starter Kit page states that the kit is no longer actively maintained.
So an organisation following the model literally would adopt a component its vendor has stopped maintaining in order to reach level 300. We would not do that. The capability the model describes is still right; the tool it names is not the way to get there. What the CoE Starter Kit retirement means in practice covers what replaces it and where the gaps are.
Our position: never let community run ahead of support
In our view the single most useful rule in Power Platform adoption is that the community dimension should not be allowed to get ahead of the support dimension.
The reason is what happens to makers when it does. When they hit connection throttling, a data policy block or a deployment problem and there is no support path, they either abandon the platform or send the service desk tickets it has not been trained to resolve.
In practice that means treating them as a pair. Moving community to 300, with a champions network and a training strategy, should not happen until support is also at 300, with a risk profile that decides which apps get IT support and which remain the maker’s responsibility. Governance needs to be at least at 200 alongside them, so the default environment is covered by data policies before the community starts filling it.
We would rather see an organisation at a steady 200 across community, support and governance than at 400 on community and 100 on the other two. A steady 200 means basic data policies, an intake process, support routing and environment boundaries advancing in step with maker training. It is slower and it holds. The lopsided profile produces a strong usage number for about a year, then operational debt and audit exposure nobody planned for, and then a remediation programme.
That also changes what gets reported. Replace monthly active makers and total apps built with two operational health measures. Support tier coverage is the percentage of high-usage apps assigned to a defined support tier. Verified active ownership is the percentage of production resources mapped to an active, monitored service account or a named business owner. Those figures move more slowly, and they describe whether the adoption is effective, which is the thing Microsoft says actually matters.
Where this connects
Business value is the dimension that tends to lag longest. Microsoft does not expect a formal business value assessment until level 300, where pain points are quantified before a project starts and compared after it finishes. That is the before and after measurement covered in why Power Apps ROI rests on a baseline most teams never capture.
Where to start
Score your estate honestly on three of the nine dimensions: community, support and governance. Use Microsoft’s level descriptions as written rather than a sense of how it feels.
If community is ahead of the other two, stop investing in growing it and close the gap first. Classify existing apps by support tier, starting with anything a business process depends on, and find the apps and flows whose owner has already left.
Then find your champions. In most organisations that means looking rather than asking: check who answers questions in your internal channels, who your Excel and SharePoint experts are, and who your most active makers are. In a hierarchical or regulated organisation, run a sponsored call for volunteers with manager sign-off instead. Either way, give champions influence rather than a support rota, and start the community from them.
Veratas delivers Power Platform programmes, including the governance and support model that keeps adoption effective rather than just large.
If your adoption report is a user count that keeps going up, talk to our team. It is worth knowing what is underneath it.
Frequently asked questions
How should Power Platform adoption be measured? Microsoft’s adoption maturity model states that adoption is about using the technology effectively rather than the number of users, while acknowledging effectiveness is harder to measure. More useful indicators are support tier coverage, the share of high-usage apps with a defined support tier, and verified active ownership, the share of production resources mapped to an active service account or a named business owner.
What are the levels of the Power Platform adoption maturity model? Five levels: 100 Initial, 200 Repeatable, 300 Defined, 400 Capable and 500 Efficient. They apply separately to nine capability areas, including strategy and vision, business value, security, governance, support, community, responsible AI, automation and fusion teams.
Should we aim for level 500 across the board? No. Microsoft describes the model as a way to decide the level you want for each dimension and the timeline. It is designed to produce an uneven profile, and the priority is keeping dependent dimensions such as community, support and governance in step.
How do we find Power Platform champions? In most organisations, by noticing who is already doing the work: who answers questions in internal channels, the existing Excel, Access and SharePoint experts, and the most active makers. Microsoft describes private invitation as more common than asking people to self-identify. In hierarchical or regulated organisations, a sponsored call for volunteers with manager sign-off often works better, because makers there tend to keep their tools out of sight.
Are champions part of the support model? No. Microsoft describes champions as business representatives rather than a support team. Support is a separate capability area, and at level 300 it uses a defined risk profile to decide whether a solution is IT supported, IT blessed or maker supported.
What happens to Power Platform apps when the maker leaves? Anything that depends on a connection created by the leaver’s account can fail as soon as that account is disabled, because Microsoft states the connection becomes invalid for every user who shares it. Where the dependency is data in the maker’s personal OneDrive, such as an Excel table, failure comes later: in our engagements typically 60 to 90 days after they leave, in line with Microsoft making an unlicensed OneDrive read-only after 60 days and archiving it after 93. An admin can assign new owners to orphaned flows and apps, but without a support tier the estate usually discovers the app through the incident.
Does the maturity model still recommend the CoE Starter Kit? It does, at community level 300 and through the Business Value toolkit at level 400, even though Microsoft states the CoE Starter Kit is no longer actively maintained. The capabilities described remain valid, but the named tooling should not be adopted as written.
Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.