Five mistakes when implementing Power Platform in a mid-sized company.
What we see in projects that stalled halfway: licensing, governance, dependency and scope.
Microsoft sells Power Platform on the argument that anyone can build applications without programming. It is half true, and the missing half is what makes projects fail. These are the five mistakes we find most often when we are called to rescue a stalled implementation.
The first is discovering licensing halfway through the project. Microsoft 365 licenses include a set of standard connectors, but premium connectors — external databases, third-party services, custom connectors — require additional per-user licenses. A flow designed on a premium connector without budgeting for it gets stuck in production. Licensing verification must be the first item of the design, not a surprise during implementation.
The second is proliferation without governance. When several people start building flows and apps on their own, a year later the company has forty automations with no inventory, no documentation and no owner. Some duplicate functions, others stopped working and nobody noticed. A Power Platform environment needs the same rules as any other asset: catalog, owner, test environment separate from production.
The third is building on someone's personal account. It is the most expensive mistake and the quietest: the application works perfectly until that person leaves the company, and then the flow stops because the connections were in their name. Connections must be on organizational service accounts, not individual ones.
The fourth is automating the wrong process. The ease of the tool invites you to start with what is easy to build rather than what saves the most. The result is elegant applications for marginal processes, while the activity that consumes three hundred hours a year is still done by hand.
The fifth is treating training as an event. Two hours of demonstration at project close is not knowledge transfer. Real adoption requires that at least two people on the internal team have built something with guidance, not merely watched something being built.
None of the five is a technical problem with the platform. All are project-management problems, which is precisely where a consulting firm adds value and where a software vendor normally does not go.