Microsoft verifies D365. Who verifies your D365?

Microsoft is changing how organisations think about Dynamics 365.

In September 2026, Microsoft began retiring the traditional twice-yearly release-wave model for Dynamics 365, Power Platform and Dataverse, moving instead to an always-on roadmap where new capabilities are published continuously as plans are committed.

This doesn't mean Dynamics 365 has suddenly become continuously updated. Microsoft's One Version strategy has been moving customers towards an evergreen application model for years.

But it reinforces something important.

Enterprise applications are no longer changing in large, predictable upgrade projects every few years. Change is continuous. Assurance needs to become continuous too.

And that is a major reason we built deep Dynamics 365 knowledge into Virtuoso Touchstone.

Microsoft is Clear About the Customer's Responsibility

Microsoft tests Dynamics 365 extensively. Its own guidance also draws a clear line: after an update, customers need to verify that their solution still works as expected.

The reason is simple. Microsoft cannot test the combination that makes each customer's D365 unique:

• their data

• their configuration

• their extensions and customisations

• their integrations

• their business processes and requirements

So Microsoft recommends regression testing after every update, and recommends automating it because manual regression takes significant time and effort.

The Finance and Operations Update Calendar

For Dynamics 365 Finance and Operations, the calendar makes this urgent. Microsoft ships four service updates a year, in February, April, July and October. Customers must take at least two and can pause only one consecutive update. Under standard auto-update, the UAT sandbox is updated seven days before production. That is the window organisations have to validate their environment.

The wider D365 estate moves too. Power Apps and Dataverse run on their own update processes.

The old model of assembling a large team, running a regression pack by hand and signing off periodically does not survive this pace. Microsoft's guidance describes testing as a continuous cycle, not a one-time implementation activity, and recommends automation across functional, process, end-to-end and regression testing.

But automation alone leaves a bigger problem unsolved.

Automating a Test Doesn't Tell You Whether it is the Right Test

Imagine a D365 customer has 2,000 regression tests.

They automate all 2,000 and execute them successfully after an update.

Is the business assured?

Not necessarily.

Automation can tell you whether the tests passed.

It cannot, by itself, tell you whether those 2,000 tests are still the right tests, whether important scenarios are missing, whether the assertions are sufficient, or whether the tests genuinely prove the business outcomes that matter.

That distinction is becoming increasingly important.

Microsoft itself recommends that functional testing is mapped to business processes and requirements, uses realistic customer data, and verifies that configuration and customisation meet business requirements. This is where we believe AI changes testing fundamentally.

Why we built a Dynamics 365 knowledge base

Touchstone is designed to understand the application before it creates the test. For Dynamics 365, that means combining knowledge of how D365 works with the context of the customer's own environment. Think of it as four layers.

1. Dynamics 365 knowledge: How D365 is designed to operate: its processes, entities, workflows, roles, APIs, integrations and expected behaviour.

2. Implementation knowledge: How this organisation has configured D365: customisations, extensions, integrations, security model, data and business rules.

3. Business context: What the organisation is trying to achieve through each process.

4. Risk and control context: What must not go wrong: financial controls, authorisation rules, segregation of duties, regulatory obligations and internal policy.

Touchstone uses these layers together to decide what needs to be verified, instead of replaying whatever someone once decided to automate.

That changes the question. It stops being "Can I automate this journey?" and becomes "What evidence do I need to prove this business process still works as intended?"

Consider a simple accounts payable example

A traditional automated test might create a supplier, raise a purchase order, receive goods, enter an invoice and post it. If the journey completes, the test passes.

But what was the business trying to prove? Probably something like this: only legitimate, correctly authorised supplier invoices should create an accurate financial liability and, eventually, a payment.

That objective creates a much richer set of things to verify. Touchstone reasons from objective to risk, control, scenario, journey, assertions and evidence. In practice, that means asking:

• Can an invoice from an unauthorised supplier be processed?

• Can the same invoice be submitted twice?

• Is an invoice outside tolerance blocked or routed correctly?

• Does the right approval hierarchy apply above a financial threshold?

• Can someone approve spend beyond their delegated authority?

• Are tax, currency and accounting dimensions maintained correctly?

• Does the resulting journal reach the general ledger correctly?

• Does an integration failure leave the transaction in the wrong state?

• Is there a complete audit trail of who approved what, and when?

These are not more automated clicks. They are assertions about whether the business outcome is correct. Many of them are negative tests: proof that something that must not happen cannot happen.

Now Apply That to a Microsoft Update

Suppose Microsoft changes functionality affecting purchasing, approvals or financial posting.

The traditional response is to run the existing regression suite.

Touchstone's ambition is different.

It can understand the D365 capability affected, combine that with knowledge of the customer's configuration and business processes, identify the areas of potential impact, and determine what needs to be verified.

Then Virtuoso QA can execute those tests across the application and its integrations and produce evidence of the outcome.

The result is a move from:

Release → Regression Pack → Manual Analysis → Sign-off

towards:

Change → Understand Impact → Generate/Update Tests → Execute → Assert Outcomes → Evidence

That is what continuous assurance looks like.

The Economics Matter Too

Microsoft itself describes manual regression as time-consuming and labour-intensive, and says automation saves time and resources.

Take a modest regression estate. If 1,000 tests each need 10 minutes of human effort to execute and evidence, one cycle costs about 167 hours. Four cycles a year is roughly 667 hours, before test maintenance, environment preparation, defect investigation, retesting or the business specialists needed to validate outcomes. At 5,000 tests, a single cycle passes 830 hours.

Automation reduces execution cost. Touchstone targets the larger cost: the human effort to understand change, decide what to test, build and maintain tests, run them, analyse results and produce evidence.

The goal is not fewer testers. It is more assurance for every pound and every hour spent on testing.

There is Also a Quality Dividend

This may prove more valuable than the cost saving. Microsoft recommends finding defects as early as possible, because late defects waste time and money and erode confidence in the solution.

A test that runs fast but misses an important failure has little value. So the measure of a test estate cannot stop at how many tests are automated or how quickly they run. It should include:

This is the standard we intend to hold Touchstone to.

Microsoft Verifies Dynamics 365. Who Verifies Your Dynamics 365?

This is the question every D365 enterprise now needs to answer.

Microsoft can test its software. Your implementation partner can test the configuration it delivers. Your internal teams can test individual changes. But someone has to establish that the whole system still works together:

Dynamics 365, plus your configuration, customisations, integrations, Power Platform apps, ISV solutions, data, people, controls and business processes.

That combination is unique to every organisation.

That is why we built the Dynamics 365 knowledge base into Touchstone. Not to create more tests. Not just to run existing tests faster. To give an AI agent enough application and business understanding to keep deciding what needs to be verified, how to test it, what to assert and what evidence establishes confidence.

Microsoft describes Dynamics 365 service updates as continuous and touchless, and its roadmap is now always on. Enterprise assurance needs to make the same transition.

D365 has become evergreen. Testing hasn't. That is the problem we are building Touchstone to solve.