Dynamics 365 Finance & Operations runs on Microsoft’s continuous update model, often called One Version. Service updates arrive on a fixed cadence, you can pause a limited number of them, and eventually each one is applied whether you tested it or not. Organisations handle this in one of two ways: they dread every release and re-test everything by hand, or they build a small, repeatable routine and stop thinking about it. This article is about the second way.
What an update wave can actually break
Standard functionality is tested by Microsoft before release and rarely breaks. What breaks is the layer that is specific to you:
- Extensions that depend on a method or data entity that changed
- Integrations built on undocumented tables or on entities whose fields moved
- Custom reports and Power BI datasets pointing at renamed fields
- Features that were enabled by default in the new release and change behaviour, such as a new validation on a posting form
That list is short, and it tells you where to test. You do not need to re-test the general ledger. You need to test your extensions, your integrations and your reports, plus the handful of processes the business cannot live without.
The routine, in five steps
- Keep a regression pack of twenty to forty scripts. Month-end close, purchase-to-pay, order-to-cash, payroll if you run it, every integration, every custom report. Written with data, steps and expected results, by the process owners, once.
- Apply the release to a sandbox first. Always. A sandbox that is a recent copy of production, so the data is real.
- Run the pack. Manually for scripts that run rarely, automated (Regression Suite Automation Tool) for the ones that run monthly or more.
- Read the release notes for feature changes. Microsoft lists features that are turned on by default. Decide for each whether to accept it or disable it in Feature management before production.
- Go or no-go, in writing. A one-page result: what passed, what failed, what was fixed, whether production can be updated. If no, pause the update and fix.
How long it takes once it is set up
For a typical single-entity organisation, a release cycle takes a day or two of effort spread over a week: sandbox update, test run, fixes, production update. The first time, building the pack takes longer; that is a one-time investment that also pays off at every change you make yourselves.
When to pause and when not to
Pause a release when the sandbox run finds a failure you cannot fix before the production date, or when the release lands in the last week of your financial quarter. Do not pause out of habit: the pause allowance is limited, and skipping several releases means a bigger jump later with more changes at once.
What goes into the regression pack
The pack is small on purpose. A good starting list for a finance and supply chain organisation:
| Area | Scripts |
|---|---|
| Finance | Journal posting, vendor invoice to payment, customer invoice to receipt, month-end close sequence, financial report |
| Purchasing | Requisition to purchase order with approval, goods receipt, three-way match |
| Sales | Sales order to pick, pack, ship and invoice; credit note |
| Inventory | Transfer order, counting journal, inventory close |
| Integrations | One end-to-end run of every interface with a known record |
| Custom | Every extension that changes a posting or a calculation |
Twenty to forty scripts cover most organisations. Each script names the data to use, so a tester can run it in the sandbox without preparing anything.
A release cycle, week by week
- Week 1: Refresh the sandbox from production, apply the release, read the feature change list.
- Week 2: Run the pack, log anything that fails, fix extensions and integrations where needed, re-run the failed scripts.
- Week 3: Go or no-go in writing, update production at a quiet time, run a short smoke test in production.
Spread across a month, this is manageable alongside normal work. Compressed into the last three days before the deadline, it is the thing everyone dreads.
The mistake to avoid
Treating the release as an IT event. The people who know whether the purchase order still behaves correctly are the buyers, not the administrators. Give process owners the scripts and an hour each; the quality of the result goes up and the time spent goes down.
Does every release mean days of re-testing? See our regression testing service or book a consultation.
Frequently asked
Can we skip Dynamics 365 updates?
You can pause a limited number of service updates per year, but not indefinitely. Microsoft eventually applies updates to stay within the supported window. A routine is cheaper than a pause strategy.
Do we need automated testing?
Not for everything. Automate the scripts that run monthly or more, keep the rest manual. Automating two hundred rarely-used scripts is how test suites die.
Who should own update wave testing?
A named person in your team, with support from whoever maintains your extensions and integrations. It is part of our standard support arrangement.