Three channels now answer three different questions

Microsoft's August 25, 2026 post moves Dynamics 365, Power Platform, and Dataverse roadmap content into the AI at Work roadmap, alongside Microsoft 365, Copilot, and custom agents. The post says new capabilities begin publishing there in September 2026, Release Planner retires by November 15, 2026, and the twice-yearly release wave model gives way to always-on publishing. Message Center stays the tenant change channel and Microsoft Learn stays the documentation home. That is three channels, and the practical question for a platform owner is which one a given planning decision should be read from.

Our read is that most teams have been using one channel for everything. The release plan on Learn doubled as the portfolio view, the test calendar, and the configuration reference, because it arrived twice a year and everyone read it once. With the waves gone, that habit breaks. Each decision needs a named channel, and the type of decision picks it.

Build, buy, or wait decisions belong to the roadmap

The decision that sits in a design review, whether to build something custom now or wait for a platform feature, is a roadmap decision. The post describes filtering by products and cloud environments, status values of In Development, Rolling Out, and Launched, search by feature ID, and export to CSV. That answers the question a solution architect actually asks, which is whether Microsoft is working on this and how far along it is. The cloud environment filter matters here, because a feature rolling out in one cloud says nothing about a sovereign or government tenant.

What the roadmap does not tell you is when the feature reaches your tenant. A status of Rolling Out is a portfolio fact. The desk would treat it as permission to pause a custom build, and would keep it out of the project plan as a date. If your steering committee wants a date from this channel, the honest answer is a status and a range, with a note that the range is not tenant-specific.

Test cycle and change window decisions belong to Message Center

The decision about whether next month needs a regression cycle, a note to the service desk, or a freeze around quarter end is a Message Center decision. The post keeps Message Center as the source for tenant-relevant change notifications. A roadmap item can sit in Rolling Out for a long time. The Message Center post is the one that says the change is coming to this tenant and gives the operator something to act on.

Our sibling piece on the boundary between public roadmap signals and tenant change notices goes deeper on where that line falls. For planning purposes the rule is short. Nothing enters the change calendar from the roadmap. It enters from Message Center, with a named owner and a test environment attached.

Configuration and build decisions belong to Learn

Once a feature is in the tenant, how to configure it, what the admin setting is called, and what the connector limits are, those are documentation decisions and the post keeps them on Microsoft Learn. The post also says existing release plans with public preview or general availability dates of June 1, 2026 or later move to the new roadmap, and earlier content stays on Learn for reference. Anyone who bookmarked a release plan page as an implementation guide should check which side of that date it falls on.

The trap we would watch for is a Learn page being read as a planning signal. Documentation lands when a feature is real enough to document, which is usually after the decision to adopt should already have been made. Reading Learn to find out what is coming means finding out late.

The wave calendar was doing planning work nobody had named

The retired wave model gave every Microsoft business applications team a free planning rhythm. Two dates a year, a published plan, a predictable window for the budget conversation and the environment refresh. The post says there is no September 2026 release wave 2 announcement, so that rhythm ends this month. Nothing in the post replaces it. The cadence has to come from the team now.

The practical move is to give the planning meeting its own calendar rather than borrowing one from the vendor. Our piece on turning a release announcement into a readiness calendar covers the Salesforce version of that problem, and the shape is the same here. Pick a monthly slot, read the filtered roadmap RSS feed for build-or-wait items, read Message Center for change window items, and keep the two lists apart. The question of which solutions get their own test environment before a change lands is covered in our Power Platform environment strategy guide.

One filter, three owners

The sibling piece on why a single destination still needs local release ownership makes the ownership case. The channel mapping makes it concrete. The architect owns the roadmap filter and the build-or-wait list. The tenant admin owns Message Center and the change calendar. The maker or delivery lead owns the Learn reading once a change is confirmed. When one person holds all three, which is common in a small team, the discipline is to keep three lists rather than one inbox.

The post mentions a Release Communications MCP Server for custom workflows, and the desk's guess is that teams will try to automate the sorting there first. Before wiring an agent to it, we would settle the three-owner mapping on paper, because an agent that files every roadmap item into the change calendar recreates the original problem at higher speed. Take the intake reading from our governance hub with you, and take one question into the next planning meeting. For each item on the list, which channel did it come from, and who owns the decision it belongs to?