Testing D365 After Customisation: How to Validate ISV Extensions, Custom Fields, and Modified Workflows Without Starting Over
Every D365 implementation is customised. Custom fields capture industry specific data. Modified workflows enforce unique approval hierarchies. ISV extensions add specialised functionality. Power Apps components embed within D365 forms. Power Automate flows connect to external systems.
These customisations are what make D365 fit the organisation's specific needs. They are also what make D365 testing genuinely difficult.
The standard testing challenge is well understood: validate that core D365 processes work correctly. The customisation testing challenge is harder: validate that your modifications work correctly, that they continue to work after D365 updates, and that they do not break the standard functionality they extend.
Most D365 teams handle this poorly. They either test customisations in isolation without verifying the impact on standard processes, or they test standard processes without covering customised behaviour, or they attempt comprehensive testing and run out of time before achieving either.
There is a structured approach that solves this problem. It starts with understanding what makes customisation testing different and builds toward a sustainable automated strategy.
Why Customisation Testing Breaks Standard Approaches
Three characteristics of D365 customisations create testing challenges that standard approaches struggle to address.
The Moving Target Problem
Customisations exist in a system that Microsoft updates continuously. Wave releases arrive twice a year. Monthly quality updates roll out between them. Hotfixes address specific issues on shorter cycles.
Each update can interact with customisations in unpredictable ways. A Wave release that modifies a standard form might conflict with a custom field extension. A quality update that changes approval workflow behaviour might break a modified routing rule. A hotfix to a posting profile might affect how a customised financial dimension is processed.
Testing must validate not just that customisations work today, but that they continue to work after every update. This creates a maintenance requirement that scales with the number of customisations in the environment.
The Surface Area Mismatch
Customisations typically affect 20 to 30 percent of the D365 testing surface. But the impact is not evenly distributed. A single custom workflow modification might touch multiple modules. A custom field added to the sales order form might affect reporting, integration, and GL posting. An ISV extension that modifies the AP invoice process might interact with matching policies, approval workflows, and payment processing.
The testing surface area for customisations is often larger than the customisations themselves because of these cross cutting impacts. Testing the custom field is straightforward. Testing everything the custom field affects is the real challenge.
The Knowledge Gap
Customisation testing requires understanding both the standard D365 behaviour and the intended custom behaviour. A standard regression test validates that the system works as Microsoft designed it. A customisation test validates that the system works as your organisation modified it.
This means the test author needs to know: what the standard behaviour is, what the customisation changes, why it was changed, and what the expected behaviour should be after the modification. This knowledge often exists only in the heads of the consultants who built the customisation, making test creation dependent on institutional knowledge that may not be documented.
A Framework for D365 Customisation Testing
The practical approach separates customisation testing into four layers, each building on the previous one.
Layer 1: Standard Process Baseline
Before testing any customisation, establish a baseline that confirms standard D365 processes work correctly in your environment. This baseline serves two purposes: it validates that core functionality is intact, and it provides a comparison point for detecting when customisations introduce unintended side effects.
Build automated tests for your core standard processes: Order to Cash, Procure to Pay, month end close, inventory management, and master data management. Run these tests in an environment with your customisations applied. If any standard test fails, the failure indicates that a customisation is affecting standard behaviour and needs investigation.
Composable testing accelerates baseline creation. Pre built test components for standard D365 processes can be imported and configured for your environment, providing immediate coverage of the 70 to 80 percent of D365 that is not customised.
Layer 2: Customisation Specific Tests
For each significant customisation, build targeted tests that validate the modified behaviour.
For custom fields, test that the field appears on the correct forms, accepts the correct data types, enforces any configured validation rules, carries through to downstream processes (posting, reporting, integration), and survives form refreshes and navigation.
For modified workflows, test that routing follows the new rules, that each branch of the workflow logic is exercised, that escalation and timeout behaviours work as configured, and that the workflow interacts correctly with standard D365 approval mechanisms.
For ISV extensions, test that the extension functions as documented, that it does not interfere with standard processes that it does not intend to modify, and that it handles D365 update scenarios gracefully. ISV vendors typically provide release notes indicating compatibility with D365 Wave releases, but testing is the only way to confirm that compatibility in your specific environment.
For Power Apps components embedded in D365, test that the component renders correctly, that data flows between D365 and the Power App accurately, that the component responds to D365 events appropriately, and that the embedded experience works across supported browsers.
Layer 3: Integration Impact Tests
Build tests that validate the intersection of customisations with standard processes.
These tests follow the complete business process flow including the customised steps. An Order to Cash test that includes a custom credit approval workflow step, a custom field on the sales order that affects pricing logic, and a custom posting profile that routes revenue to a non standard GL account is an integration impact test. It validates that the customisation works correctly within the broader process context.
Integration impact tests are the most valuable and the most frequently missing from D365 test suites. They catch the failures that arise not from the customisation itself but from the interaction between the customisation and the standard system.
Layer 4: Update Survival Tests
Build a regression suite specifically designed to run after every D365 update. This suite includes the standard baseline tests from Layer 1, the customisation specific tests from Layer 2, and a selection of the integration impact tests from Layer 3.
The purpose is to answer a single question after every update: did this update break anything in our customised environment?
Self healing makes this suite sustainable. Without self healing, every D365 update that modifies interface elements breaks existing tests and creates a maintenance backlog. With approximately 95% self healing accuracy, the update survival suite adapts automatically, providing immediate confidence that the update is safe.
Handling ISV Extension Updates
ISV extensions follow their own update cycles, independent of D365 Wave releases. This creates a two dimensional update challenge: D365 updates that might affect the ISV extension, and ISV updates that might affect D365 standard processes.
Build separate test branches for ISV update validation. When the ISV releases a new version, run your customisation specific tests and integration impact tests against the new ISV version before deploying to production. When D365 releases an update, run the same tests to verify ISV compatibility.
Document which tests cover which ISV extensions. When an ISV announces a breaking change or a D365 Wave release notes indicate changes to areas where ISV extensions operate, you know exactly which tests need attention.
The Modular Testing Approach
The key to sustainable customisation testing is modularity. Build tests as composable components that can be assembled, reconfigured, and extended as customisations evolve.
A modular Order to Cash test might consist of six components: customer creation, sales order entry, order confirmation, fulfilment, invoicing, and payment. If your customisation adds a credit approval step between order entry and confirmation, you insert a new component into the sequence without rebuilding the entire test.
This modularity matters because customisations change. Requirements evolve, new ISV extensions are added, existing workflows are modified. A monolithic test that covers the entire customised process must be rebuilt whenever any customisation changes. A modular test only requires updating the specific component that is affected.
Virtuoso's composable architecture supports this modular approach natively. Pre built components cover standard D365 steps, and custom components can be created using natural language authoring for the modified portions. StepIQ accelerates custom component creation by autonomously suggesting test steps based on the customised interface. When a customisation changes, only the affected component needs updating while the rest of the test journey remains intact.
The Cost of Ignoring Customisation Testing
Organisations that underinvest in customisation testing pay the price in three ways.
Update paralysis: Teams delay D365 updates because they cannot confirm that updates will not break their customisations. This creates a growing gap between the organisation's D365 version and Microsoft's current release, accumulating technical debt and missing new features.
Production surprises: Untested customisation interactions cause failures that only manifest under specific conditions: a particular combination of customer type, order size, and payment method that was never tested. These failures surface in production and require emergency resolution.
Regression accumulation: Each new customisation adds untested interaction potential. Without systematic testing, the number of untested interactions grows exponentially over time, making the environment increasingly fragile.
The structured approach described here prevents all three. It provides the confidence to adopt D365 updates promptly, catches interaction failures before production, and maintains a comprehensive test suite that scales with the organisation's customisation footprint.
Frequently Asked Questions
How much of a typical D365 environment is customised?
Customisations typically affect 20 to 30 percent of the testing surface area. However, the impact radius of those customisations often extends further because modifications to one area can affect downstream processes, reporting, and integrations.
What is the biggest risk of not testing D365 customisations after updates?
Update paralysis. Teams delay D365 updates because they cannot confirm compatibility with their customisations. This creates growing technical debt, missed features, and increasing divergence from Microsoft's supported release path.
How do you test custom fields that affect downstream D365 processes?
Build end to end tests that trace the custom field's data from entry through every process it touches. If a custom field on the sales order affects pricing, GL posting, and reporting, the test must validate all three downstream impacts, not just the field entry itself.
Can self healing handle customised D365 interfaces?
Yes. Self healing uses multiple identification techniques that work for both standard and customised interface elements. When a customisation modifies a form layout or adds new elements, self healing adapts to the modified interface structure using visual analysis, DOM structure, and contextual data.
How should ISV extension updates be tested separately from D365 updates?
Build a test branch specifically for ISV validation. When the ISV releases a new version, run customisation and integration impact tests against it before production deployment. Maintain documentation mapping which tests cover which ISV extensions for efficient update planning.
What is the difference between customisation testing and regression testing?
Regression testing validates that existing functionality still works after a change. Customisation testing validates that modifications work correctly and do not introduce unintended side effects. In practice, a comprehensive approach combines both: testing that customisations function correctly and that they have not broken anything else.
How do you test Power Apps components embedded in D365?
Automated tests validate that the Power App renders within the D365 form, that data flows correctly between D365 and the Power App, that the component responds to D365 events, and that the embedded experience functions across supported browsers. Combined UI testing handles both the D365 interface and the embedded Power App component.
What is a modular testing approach and why does it matter for customisations?
Modular testing builds tests as composable components that can be assembled and reconfigured. When a customisation changes, only the affected component needs updating while the rest of the test remains intact. This is critical because customisations evolve frequently, and monolithic tests require complete rebuilds with every change.
How does composable testing handle the standard vs custom split?
Pre built composable components cover the 70 to 80 percent of D365 that is standard. For the 20 to 30 percent that is customised, teams build additional components using natural language authoring. The modular architecture allows standard and custom components to be assembled into complete end to end tests.
Should customisation tests run after every D365 monthly update?
Yes. Monthly quality updates can affect customisations even though they are smaller in scope than Wave releases. An update survival regression suite that runs after every update provides continuous confidence that customisations remain functional.
How does StepIQ help with testing new D365 customisations?
StepIQ analyses the customised D365 interface and autonomously suggests test steps based on the modified UI elements, application context, and user behaviour patterns. This accelerates custom test component creation for new modifications, reducing the time between customisation deployment and test coverage.
Does Virtuoso support testing of D365 environments with heavy customisation?
Yes. Virtuoso's combination of composable testing for standard processes, natural language authoring for custom test creation, self healing for update stability, and StepIQ for autonomous step generation makes it particularly suited to heavily customised D365 environments where traditional coded frameworks struggle with maintenance.