Microsoft’s vision for the Power Platform has always been about enablement. “Low-code, no-code” has enabled many makers to build business applications without writing traditional code. It’s an attractive idea—why rely on scarce pro-dev resources when we can empower citizen developers to build what they need?
But then, there’s the reality. And reality often doesn’t align with the marketing slide decks.
With the introduction of Power Platform Low-Code Plugins, Microsoft is making a push to bring more low-code automation into Dataverse without requiring full-scale C# development. This is positioned as a way for makers and consultants to extend Dataverse business logic without writing actual “code.” Instead, Power FX—the formula language familiar from Canvas Apps—is now the tool of choice for defining business logic inside Dataverse.
Sounds great in theory. But in practice? Well…
Power FX was originally designed as an Excel-like expression language for Canvas Apps. It made sense in that context—business users working with familiar formula structures to manipulate data and UI elements. But introducing Power FX into the Dataverse backend, for things like plugins and actions and custom API’s? That’s where I’m starting to become more skeptical.
The biggest challenge? Documentation and consistency.
Power FX has been evolving rapidly, and Microsoft’s documentation often lags behind its features. Unlike C#, which has decades of well-documented patterns, Power FX still feels like a moving target. That’s a serious problem when you’re expecting makers to build business-critical logic with it.
Another issue? Limited debugging and developer tools. If you’ve worked with C# plugins in Dataverse, you know there are well-established debugging workflows, ALM processes, and mature developer tooling. Power FX inside low-code plugins lacks much of this maturity, leaving makers and consultants with trial-and-error debugging experiences that feel more like “guess-and-check” than actual software development.
A common argument for low-code plugins is that they enable a new breed of “semi-devs”—makers who aren’t full-blown pro developers but need more control than what business rules offer. But instead of making things easier, Power FX in low-code plugins risks creating a knowledge gap that is harder to bridge:
The result could be a language that neither no-coders nor pro-devs fully embrace.
Low-code development has its place. But if the goal is to reduce friction in extending Dataverse, introducing Power FX for backend logic might not be the answer. Instead of making things easier, it risks:
The dream of empowering non-developers to build business applications is a good one. But Power FX for low-code plugins feels like a compromise that benefits neither no-coders nor pro-devs. It’s yet another Microsoft experiment in bridging the gap between citizen developers and traditional software engineering—and I am going to wait a moment before jumping on any train.
For now, the best approach? For me personally, I am going to stick to the pro-code approach. My reason: knowing that what I do will most likely work without interruption for the next years. Sometimes there is no obvious right or wrong, but you have to commit to your decision knowing the potential consequences.
Original Post https://crmkeeper.com/2025/02/18/power-platform-low-code-plugins-a-step-forward-or-sideways/