A customer operations team opens its usual September release plan and finds no new wave to review. That is not a missed publication. Microsoft is retiring the twice yearly Release Plans model and moving Dynamics 365, Power Platform and Dataverse updates into the AI at Work roadmap.
The practical answer is to replace the old twice yearly review meeting with a smaller continuous change watch. Use the public roadmap to spot possible changes, Message Center to understand what applies to your tenant, Microsoft Learn to confirm how a feature works, and an internal change log to record the decision, owner and evidence.
This is a communication change, not a new deployment method. A roadmap date is still an estimate, and a roadmap item is not proof that a feature is active in your environment.
What Microsoft changed
Microsoft announced that new Dynamics 365, Power Platform and Dataverse capabilities begin publishing continuously to the AI at Work roadmap from September 2026. There is no September 2026 release wave 2 announcement. Existing Release Plans on Microsoft Learn remain available as historical references.
- 1Filter the scopeWatch only the products, clouds and customer processes your team actually uses.
- 2Capture the signalSave the feature ID, status, source, target dates and last modification.
- 3Confirm relevanceMatch the public item with tenant notices and current implementation guidance.
- 4Prove the impactTest representative customer work, permissions, failure and human recovery.
- 5Record the decisionName the owner, release choice, evidence and next review date.
Items with public preview or general availability dates on or after June 1, 2026 are expected to move between September and November. Release Planner is due to retire by November 15, 2026. Microsoft says product release schedules, deployment processes, Message Center notifications and product documentation do not change because of this move.
The new roadmap follows an item through states such as In Development, Rolling Out and Launched. It also supports filters, CSV exports, RSS updates, direct links and feature IDs. That makes it easier to follow one capability, but it removes the old calendar event that reminded everyone to review changes together.
Build one change watch instead of a new release ritual
Start with scope. List the Microsoft products, cloud environments and customer processes your team actually depends on. A contact center may care about Dynamics 365 Customer Service, Power Automate, Dataverse and Copilot Studio, but not every product in the combined roadmap. A narrow saved filter is more useful than a long export nobody owns.
Give one person responsibility for collecting new and updated items on a fixed rhythm. Weekly suits a fast changing AI program. Monthly may be enough for a stable service operation. The collector is not the approver. Their job is to bring a small evidence packet to the people who own customer risk, security, data, training and the affected workflow.
For each serious item, save the feature ID, current status, target cloud, preview or rollout date, last modified date and source link. Then name the business process that could change. If a proposed feature touches conversation assignment, capture where ownership currently appears in your team inbox. If it changes a flow or connector, identify the corresponding automation and its recovery path.
Do not turn RSS into automatic approval. A new feed entry starts triage. It should not create production work until an owner has checked the tenant message and implementation guidance.
Treat each roadmap item as a signal
The public roadmap answers what Microsoft currently plans to release. Message Center answers what Microsoft is telling your tenant. Microsoft Learn explains product behavior and configuration. Your own change record answers why your team decided to test, defer, reject or adopt the item.
| Evidence source | What it is good for | Action to take | Important limit |
|---|---|---|---|
| AI at Work roadmap | Discovering upcoming capabilities and watching status changes | Filter by product and cloud, then save the feature ID | Dates and scope can change |
| Message Center | Tenant relevant notices and transition messages | Link the notice to the affected environment and owner | It does not replace implementation testing |
| Microsoft Learn | Current setup, limits and supported behavior | Verify prerequisites and the exact configuration path | Documentation alone does not prove your tenant is ready |
| Internal change log | Decision, evidence, owner and next review | Record adopt, test, defer or reject with a date | It must be maintained by a named person |
This separation prevents a common failure. Someone sees Launched and assumes every user can rely on the feature. Availability can still depend on cloud, geography, language, license, administrator settings or rollout timing. Treat the status as a reason to verify, not permission to switch.
Test only what can affect customers
Not every roadmap item needs a project. Triage it against four questions. Does it alter customer data, permissions, an automated action or a representative's way of handling live work? If none apply, record it and move on. If one applies, create a small proof in a nonproduction environment or a controlled pilot.
Test a representative case from start to finish. For AI or automation changes, check the allowed action, the denied action, failure visibility and human recovery. Review the same controls your team uses for customer service AI, the developer surface and security. These links describe DripTell's own product boundaries; they do not imply that DripTell configures Microsoft tenants.
Keep screenshots or exports only when they prove a decision. More evidence is not automatically better. A useful packet shows the source item, tenant relevance, test result, accountable owner, release decision and next review date.
Keep the record useful after launch
Continuous publishing means the review does not end when a feature launches. Recheck items that were postponed, restricted to preview, or missing in your cloud. Close a record only when the team has either adopted the change with working evidence or rejected it with a reason that still holds.
If a Microsoft change affects how customer conversations move between people, channels or automated actions, map that impact before changing production. DripTell can help teams document their current conversation workflow and decide what should remain under human control. Talk to the team when that broader operating review is the real task.
Frequently Asked Questions
Is Microsoft ending Dynamics 365 release schedules?
No. Microsoft says the transition changes how upcoming capabilities are communicated. Established product release schedules and deployment processes continue.
Will there be a Dynamics 365 release wave 2 plan for September 2026?
No. Microsoft's partner announcement says there will not be a September 2026 release wave 2 announcement. New capabilities move to continuous roadmap communication.
Can we keep using old Release Plans?
Yes, as historical references. They will not be the place for newly published capabilities from September 2026 onward.
What should replace our twice yearly review meeting?
Use a recurring review built around saved product and cloud filters, RSS or exported changes, Message Center notices, implementation documentation and one owned internal decision log.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
