Dynamics 365 Finance & Operations is a service that Microsoft updates several times a year. That is good news: new features and fixes arrive without big upgrade projects. But it also means every customisation you add must keep working as the platform underneath it changes. Here is how to build so that updates stay routine.
Understand the update rhythm
Microsoft releases regular service updates to all customers on the same version, an approach often called One Version. You can pause or move an update within limits, but you cannot stay on an old version indefinitely. Treat updates as a normal, recurring event in your calendar, not an exception.
Rule 1: extend, never modify
In older versions of Dynamics, developers could change Microsoft’s code directly. In Dynamics 365 Finance & Operations that is no longer possible for Microsoft’s models: all custom code lives in your own models as extensions. The main techniques are:
- Chain of Command (CoC): wrap a standard method to add logic before or after it, while still calling the original.
- Event handlers: react to events raised by standard code, such as data events on tables or pre/post events on methods.
- Table, form and enum extensions: add fields, controls and values without touching the original objects.
- Extensible classes and delegates that Microsoft provides at known extension points.
Extensions are what make your changes survive updates, so a good partner will push back on any request that can only be met by fighting the platform.
Rule 2: keep customisations small and justified
Every extension is code you will need to test after each update. Before building:
- Check whether standard functionality already covers the need, including features that a recent update may have added.
- Look at Feature management, where new capabilities often appear before becoming standard.
- Consider configuration, workflows or the Power Platform for needs that sit outside core finance and operations logic.
The best customisation is often the one you don’t build.
Rule 3: write code that respects the platform
A few habits prevent most update problems:
- Always call
nextin Chain of Command methods unless you have a documented reason not to. - Avoid relying on Microsoft’s internal or private methods, which can change without notice.
- Keep business logic in classes rather than forms, so it is easier to test and reuse.
- Follow best-practice checks and fix compiler warnings, not just errors.
- Document why each extension exists. It makes future clean-up much easier.
Rule 4: test every update before production
Make testing a repeatable routine:
- Apply the update to a sandbox environment first, ideally using Microsoft’s early access options for the next update.
- Run your automated regression tests. The Regression Suite Automation Tool (RSAT) lets business users record test cases that can be replayed after every update.
- Have key users spot-check their most important processes.
- Only then schedule the update for production.
Automated tests feel like extra work at first, but they turn a stressful update weekend into a predictable checklist.
Rule 5: use proper source control and builds
Keep all code in source control (Azure DevOps or GitHub), build it with an automated pipeline and deploy packages through your environments in the same order every time. This makes it obvious what changed between versions and prevents “it works on my machine” surprises.
A simple checklist for every update
- Read Microsoft’s release notes for changes affecting your modules.
- Apply the update to a sandbox.
- Rebuild and redeploy your extensions; fix any warnings.
- Run automated regression tests.
- Get key-user sign-off on critical processes.
- Schedule the production update and communicate the downtime.
Where we can help
We build and review Dynamics 365 Finance & Operations extensions with upgrade safety as the default. We also set up regression testing and update routines, and take over support of existing customisations. If your last update was stressful, we’re happy to review your code and process.