Power Platform is moving from release waves to an always-on delivery model

For years, many teams planned Power Platform around two release waves a year: read the summary, pick a few features, go quiet for six months. That rhythm is ending. This piece is about what replaces it inside a delivery team. The mechanics of the new roadmap itself are in a companion article.

Features no longer arrive alone

Microsoft's September 2026 update is a good example. Next to product news, it brings the generally available refresh of the model-driven app header and navigation, a display density preview, Power Pages security guidance, and new admin guidance for Dataverse Git integration, deployment pipelines, service principals, environment routing, connector policies and agent analytics.

Look at that mix. A single new agent capability can touch Dataverse security, connector permissions, capacity, ALM, licensing and training at once. Teams that only read the feature headline miss the work around it.

The roadmap also shows AI moving into the execution path: agent nodes in workflows, Dataverse as a native knowledge source, maker sharing controls, cost visibility during testing, and human approval before selected tool calls. An agent that reads data and calls tools is part of the application, not a smarter chatbot.

Triage instead of a wave meeting

What I suggest is a short, regular triage. Each candidate feature goes into one of four boxes:

• Adopt now — generally available, low impact, clear value.
• Pilot — promising, but needs a bounded test first.
• Watch — preview or planned; revisit next month.
• Reject — does not fit our data, users or support model.

Keep the result in a simple capability register so decisions are not made twice.

Questions before "pilot" becomes "adopt"

1. Which environments, solutions and data does it touch?
2. Which identity does it use, and which security roles change?
3. What does it do to licensing and capacity?
4. How is it deployed and rolled back?
5. Who supports it after go-live, and how will we measure success?

Pilot with non-production data and a representative scenario, then measure reliability, adoption, cost and support effort. Switching a feature on is not success.

Things that stay the same

Roadmap dates are estimates. Previews are not production commitments. AI-assisted development still needs source control, review, validation, approvals and an owner. And cost visibility during testing does not replace a real capacity model for production.

Finding out a feature exists is the easy part now. The hard part is deciding whether it belongs in our environment and whether we can support it after the demo. I would build that decision into normal governance rather than creating a separate "AI exception" process.

Try it this month

Take the next ten features your team is curious about and sort them into the four boxes. For each, note the environments, data, identities, deployment and success measure. Run the same review next month and see what moved.