Station 9 of 10
Extensions and updates in Dynamics 365 F&O
What you leave this station with
Knowing where configuration stops and code starts, and building a regression checklist that runs at least twice a year.
Station eight stopped at the product’s limit in front of the state. This one is about its limit in front of you.
Start from the number that governs everything after it. Microsoft publishes the policy plainly: four service updates a year, auto-applied in February, April, July and October. A customer may take four, must take at least two, and may pause no more than one at a time. When the pause window ends, Microsoft applies the latest update automatically. The sandbox updates seven days before production.
So the question here is not “can I do this?” but “what happens to what I did, at least twice a year?”
The structural rule: extension, not overlayering
This is the most important architectural sentence in the product: Microsoft’s code is not edited.
Older generations allowed the original source to be overlayered and modified in place, and the price was that every upgrade became an expensive project. The cloud generation closed that door: customisation is written as an extension hung on published extension points, and never touches the original.
It reads as a restriction and it is a protection. What is built as an extension survives the update in the overwhelming majority of cases; what used to be built by overlayering broke at every upgrade. Resisting the model today means reinventing a problem that has been solved.
The four-rung ladder
| Rung | What is on it | Effect of an update |
|---|---|---|
| 1. Configuration | Posting groups, dimensions, matching policies, tax, number sequences | Always survives |
| 2. Platform tooling | Electronic reporting, workflow, workspaces, import and export | Survives, and is tested |
| 3. The Power Platform layer | Apps and flows over the data, without touching the product | Survives, and is tested |
| 4. X++ extensions and integrations | Code and external integration points | Yours, and tested every time |
Rung one is far wider than somebody arriving from smaller systems assumes. Most of what a typical Gulf project asks for — a different account under a condition, an extra approval level, a field on the invoice, a specific tax treatment — sits on rungs one and two.
The sentence that compresses the station: most of what gets requested as code is a setting nobody knew about.
Electronic reporting specifically — seen in station eight — is a complete formatting engine with no code. Master it and you can produce a document in any format an authority imposes without opening a development environment.
What this policy does to a running budget is in the Dynamics 365 Finance & Operations guide.
The regression testing tool — what separates a mature team
Microsoft publishes a free tool for automating regression testing, which records a scenario executed on screen and replays it against any environment after any update.
Its value does not show in year one. It shows in year ten.
Four updates a year against a product ten years into a customer’s life is forty test cycles. Automate the testing in year one and you pay once; leave it manual and you pay forty times, then shorten it under pressure, then find a fault in production.
The minimum worth automating: a full purchase cycle, a full sales cycle, a miniature close, an electronic tax invoice, and every live integration.
The forgotten layer: the Power Platform
Between configuration and code sits a whole layer most projects ignore, and it is usually the right answer.
Three cases it solves without touching the product.
- A simplified entry screen for one role. A rep needs two fields rather than forty: a small app over the data is simpler than customising the product’s screen, and it survives the update because it sits outside it.
- An alert or approval outside the system. A phone notification when a limit is breached, or an approval from a manager’s inbox.
- Joining a third system with no code. A ready-made flow instead of an integration that is built and then maintained.
What makes this layer safe: it reads and writes through published interfaces and does not modify the product. A product update does not break it, and what would break it is a change to the interface itself — which is far rarer.
The constraint to know in advance: this layer is separately licensed in some cases, and it is asked about on the quotation before a design is built on it. An excellent solution on an unpurchased licence is not a solution.
The update habit
Three steps, and they are what makes an update routine.
One: the release plan is read before it lands. Microsoft publishes each wave’s plan with preview and general availability dates. Read it beforehand and you plan; read it afterwards and you explain.
Two: the sandbox is tested in its window. That window is seven days, no more, because production updates automatically after it. Without automated testing, seven days cannot be used seriously.
Three: what changed and what needs training is documented. Most post-update user complaints are not faults, but a screen that moved with nobody told.
What you actually do in this station
- Take five realistic change requests and classify them on the four rungs. Four will land on one and two.
- Build a simple electronic reporting format with no code, and produce a document with it.
- Write the regression checklist for your cycles with steps and expected results.
- Read the current release plan and write half a page on what matters to a Gulf customer.
- Compute: how many test cycles does a customer need over ten years at a minimum of two a year? That number is your argument to any management refusing automation.
The three commonest mistakes
One: jumping to X++. Code gets written to solve what was configuration, adding permanent maintenance and a perpetual test cycle.
Two: manual testing in a seven-day window. It gets shortened under pressure, and the fault is found in production.
Three: ignoring the release plan. The change is learned from a user complaint, the most expensive way to find out something published free months earlier.
The acceptance test for this station
- State the update policy in numbers: how many a year, the minimum, and how many can be paused.
- Explain extension against overlayering and why the second was closed.
- Classify five change requests on the four rungs.
- Show the regression checklist you wrote.
- Explain why a seven-day window without automation is theoretical.
What comes next
You have the product and its limits. The last station turns it into income: certification and a first job — MB-310 with its duration, price, languages and annual renewal, and what an interview actually asks.