Microsoft Dynamics 365 Testing
D365 Finance & Operations and D365 Business Central are common in NZ mid-market and manufacturing. Learn the D365 module landscape, Regression Suite Automation Tool (RSAT), and Power Automate integration testing.
1 The Hook
A Christchurch manufacturer migrated from MYOB to D365 Business Central. The project ran on time, the UAT was signed off, and they went live on a Monday. By Wednesday the production manager was on the phone to the CFO.
The inventory valuation method had been set to FIFO (First In, First Out) instead of Weighted Average by mistake — a single configuration field on the Item Card, set once during setup. Three months later, when the finance team compared Cost of Goods Sold to the prior year figures, the numbers were so different that the auditors flagged it. The correct method was Weighted Average, as the company had always used. The remediation required a manual inventory revaluation and restated management accounts for an entire quarter.
The test team had run process tests — they created items, raised purchase orders, received stock, raised sales orders, and invoiced customers. Every process worked. Nobody had ever tested the configuration settings screen that set the inventory valuation method. One field, never checked. One quarter of wrong financial data.
2 The Rule
In D365, always test the CONFIGURATION FIRST. Run a configuration checklist before any functional testing begins. A wrong setting propagates errors through every downstream transaction — and D365 does not warn you that the setting is wrong. It just processes everything consistently according to the wrong value.
Senior engineer insight
The most dangerous D365 defects are the ones that look like correct behaviour — a 3-way match that passes because tolerances are set too wide, a Power Automate flow that runs and completes but posts to the wrong Dataverse table, or a financial dimension that defaults silently from the wrong master record. These bugs do not throw errors. They ship clean test results and then corrupt reporting for months. What changed my thinking on D365 testing was realising that the application is almost never broken — it does exactly what it is configured to do. Your job is to verify the configuration intent, not just the process flow.
Most common mistake: teams treat the configuration checklist as a one-time setup task done by the implementation consultant, then never revisit it during SIT. In NZ government D365 F&O deployments, configuration drifts between environments — a setting corrected in UAT that was never promoted to production is the most common cause of go-live incidents.
From the field
A NZ central government shared services agency running D365 F&O for accounts payable across six Crown entities assumed that financial dimension defaulting would work identically across all entities because they shared a single legal entity structure. During SIT, the team tested AP scenarios for the largest Crown entity and signed off the dimension defaulting logic. What they discovered in parallel UAT runs was that two smaller entities used a different cost centre hierarchy — the dimension rules that defaulted correctly for the main entity silently defaulted to the wrong cost centre for the others, because the vendor master records had been imported with the main entity’s dimension values. The invoices posted, the GL balanced, and nobody noticed until the monthly management report showed cost centre allocations that did not match the appropriations. The lesson: in shared services D365 environments, always test financial dimension defaulting for every entity in scope, not just the primary one, using entity-specific vendor and cost centre combinations.
3 The Analogy
D365 is like a Lego set — modules snap together through the Power Platform.
Finance, Supply Chain, Sales, and HR are individual modules (bricks) that snap together. Power Automate flows are the connectors between them. Test each module, then test the connections. A Lego connection that looks right but is misaligned causes structural failure later — not when you make it, but when you put weight on it. In D365, that weight is a month-end close or a high-volume purchase order run.
Configuration is the foundation the bricks sit on. If the foundation is wrong, all the bricks above it are in the wrong position, even if they look aligned to each other.
4 Watch Me Do It
Here is a complete 3-way match test case for D365 Finance & Operations Accounts Payable — the most commonly tested scenario in any D365 F&O implementation:
Scenario: Vendor invoice 3-way match (PO → Receipt → Invoice)
Steps:
1. Create Purchase Order (PO) for 100 units @ $50 NZD = $5,000 total
2. Confirm PO → verify status = “Confirmed”
3. Product receipt: receive 95 units (partial receipt, deliberate)
4. Verify product receipt journal created in GL
5. Create vendor invoice for 100 units @ $50 = $5,000
6. Verify system flags quantity mismatch (invoice qty 100 > receipt qty 95)
7. Verify invoice goes “on hold” per the over-receipt tolerance policy
8. Adjust invoice qty to 95 units → verify 3-way match status = “Passed”
9. Post invoice → verify AP subledger journal entry created
10. Verify GL account codes on the AP posting match the item group configuration
Expected: 3-way match enforced; tolerance rules applied correctly;
GL correctly updated with right account codes from item group setup.
Failure modes: invoice posts without mismatch detection; wrong tolerance applied;
GL account codes wrong (config issue); hold not released after adjustment.
5 Decision Tool
RSAT (Regression Suite Automation Tool) is Microsoft’s purpose-built automation tool for D365. It is not always the right choice:
| Situation | Use RSAT | Use manual testing |
|---|---|---|
| Stable, repeatable end-to-end business processes run frequently | Yes — RSAT records and replays D365 task recordings natively | Only for initial test design |
| Configuration verification (field values, setup screens) | Limited — RSAT does not easily assert configuration values | Yes — use a configuration checklist |
| Testing new functionality in early SIT | No — scripts will need to be re-recorded as the build stabilises | Yes — manual first, automate once stable |
| Power Automate flow testing | No — RSAT does not cover Power Automate flows | Yes, plus Power Automate run history review |
| Regression after a Microsoft update wave | Yes — highest value use of RSAT | Supplement with exploratory testing of changed areas |
6 Common Mistakes
🚫 Not resetting test data between RSAT runs
Why it happens: RSAT replays actions but D365 does not automatically rollback data between runs. The second run starts from where the first one left off.
The fix: Design RSAT scripts to be self-contained — each script creates its own data (new PO number, new vendor, new item) rather than relying on data left by a previous run. Alternatively, restore the D365 test environment from a known snapshot before each RSAT cycle. An RSAT run that fails because of data state is telling you about test design, not the application.
🚫 Missing the Power Automate flows that trigger on record creation
Why it happens: Power Automate flows are configured outside D365 in the Power Platform and are not visible during D365 testing without checking the flow run history.
The fix: After every key D365 record creation (sales order, invoice, customer record), check the Power Automate run history in the Power Platform admin centre. Verify that the expected flows triggered and completed successfully. A flow that fails silently means downstream systems (approval notifications, CRM updates, external APIs) did not receive the data they expected.
🚫 Testing without a full chart of accounts mirror from production
Why it happens: The test environment is set up quickly with a simplified chart of accounts, and functional testing proceeds without the full account structure.
The fix: The chart of accounts drives every financial posting. If the test environment has a simplified chart, configuration-related GL defects will not be found until production. Ensure the test environment mirrors the production chart of accounts before SIT begins. This is a go/no-go gate for starting financial process testing.
7 Now You Try
Paste or edit the prompt below, then click Run to get a real AI response.
Why teams fail here
- Signing off process tests without verifying the configuration values that drive them — the process passes because D365 is consistent, not because the configuration is correct.
- Testing RSAT scripts against a simplified chart of accounts in SIT, then hitting GL posting failures in UAT when the full production account structure is in place and the item group posting profiles do not match.
- Not checking Power Automate flow run history after key D365 record creations — flows that fail silently leave integration partners (CRM, external portals, approval systems) with missing or stale data that only surfaces days later.
- Treating D365 update waves as low-risk when RSAT scripts have not been re-validated — Microsoft bi-annual releases change UI layouts and field behaviour, and an RSAT script that passes on the old build can fail or silently write wrong values on the new one.
Key takeaway
In D365, the application rarely fails — it faithfully executes whatever configuration it was given, which means testing the configuration is not a preliminary step before real testing begins; it is the most important test you will run.
8 Self-Check
Click each question to reveal the answer.
Q1: What is 3-way match in D365, and what are the three documents being matched?
3-way match is the accounts payable control that verifies a vendor invoice against two other documents before allowing it to be posted. The three documents are: (1) the Purchase Order — what was ordered at what price; (2) the Product Receipt — what was actually received; (3) the Vendor Invoice — what the vendor is charging. D365 compares quantity and price across all three. If the invoice quantity exceeds the receipt quantity by more than the configured tolerance, the invoice is placed on hold. This control prevents paying for goods not received and is one of the most important AP configuration tests on any D365 implementation.
Q2: What is RSAT and how does it compare to Playwright for D365 testing?
RSAT (Regression Suite Automation Tool) is Microsoft’s purpose-built test automation tool for D365 Finance & Operations. It works by recording D365 task recordings (the same mechanism as help documentation), converting them into automated scripts that run in the D365 UI, and storing expected values in Excel. RSAT understands D365 natively: it handles D365’s dynamic UI elements, knows about D365 entity models, and integrates with Azure DevOps. Playwright is a general-purpose browser automation tool. It can test D365 but treats it like any other web application, which means selectors break more often on D365’s dynamic UI and it requires more maintenance. RSAT is the right tool for D365 F&O regression; Playwright is better for custom portal UIs built on D365 data.
Q3: How do you handle test data reset between D365 test runs when RSAT is being used?
D365 does not auto-rollback test data between RSAT runs. The two main strategies are: (1) Self-contained scripts — design each RSAT script to create its own unique test data (new PO number, new document reference) so it does not depend on data created by previous runs. This is the preferred approach for individual test cases. (2) Environment restoration — restore the D365 test environment from a known database backup or snapshot before each full regression cycle. This resets all data to a known state but takes time. For ongoing SIT, self-contained scripts combined with a clean environment for each regression round is the standard approach in NZ D365 programmes.
9 Interview Prep
Real questions asked in NZ QA interviews for D365 roles. Read the model answers, then practise your own version.
“What is RSAT and how does it compare to Playwright for D365?”
RSAT is Microsoft’s Regression Suite Automation Tool, purpose-built for D365 Finance & Operations. It records D365 task recordings and replays them as automated tests, storing expected values in Excel. Its advantage is that it understands D365 natively — it handles the dynamic UI, entity lookups, and D365 workflow states without custom selector maintenance. Playwright can automate D365 but it treats it as a generic web app, so D365’s dynamic element IDs and single-page architecture make selectors fragile and maintenance-heavy. I would use RSAT for core D365 F&O business process regression, and Playwright only for custom portals or external UIs that consume D365 APIs. For D365 Business Central, RSAT is not available — there you use test codeunits (AL language unit tests) or manual testing for functional regression.
“How do you handle test data reset between test runs in D365?”
D365 does not automatically rollback transactions between test runs, so test data management is a critical design decision. My approach is two-layered. For individual RSAT test scripts, I design them to be self-contained — each script creates its own unique test data, using unique document numbers or references, so it never depends on state left by a previous run. For full regression cycles, I work with the infrastructure team to restore the D365 test environment from a clean database snapshot before the cycle starts. This gives us a predictable baseline. I also maintain a test data catalogue — the specific master data (vendors, items, customers, account codes) that must exist in the test environment — so if the environment is refreshed we can quickly restore the master data without re-running every setup step manually.