Station 9 of 10
Dynamics 365 Business Central customisation and extensions
What you leave this station with
Placing any customisation request on a known rung of the ladder, knowing its cost at an update, and building one extension and one approval workflow with your own hands.
At station eight you learned the limits that cannot be crossed. This station draws a limit of another kind: where configuration ends and code begins.
And every customisation in this product is measured by one question: does it survive both update waves?
Updates here are neither optional nor deferrable. Two waves a year, on a date the developer sets, and anything that does not survive them is not a customisation; it is a debt.
The ladder — six rungs and the cost of each
Place any request on this ladder before discussing it. The rule: do not climb a rung while you can stay below it.
| Rung | What it is | Who does it | Its cost at an update |
|---|---|---|---|
| 1. Personalisation | Arranging fields and columns for one user | The user themselves | Nothing |
| 2. Configuration and setup packages | Setting fields and lists and moving them between environments | The consultant | Nothing |
| 3. Document layouts | The shape of the invoice and the purchase order | The consultant | A visual review |
| 4. Approval workflows | Who approves what and at which threshold | The consultant | Almost nothing |
| 5. Automation outside the product | Alerts and flows between applications | A consultant or a developer | Testing the connections |
| 6. A written extension | New fields, screens and logic | A developer | Code review and redeployment |
Read the last column straight through once: four rungs out of six cost nothing at an update. Most of what gets asked for on projects falls in those four, and gets built on the sixth because nobody asked.
The first and second rungs — where most requests end
The difference between them is the difference between “me” and “the company”.
The first rung belongs to one user: hiding a field they never use, moving forward a column they use every day. Its effect goes no further than them, which is why it is never discussed at all — it is taught to the user in the first session and then never mentioned again.
The second rung belongs to everybody: which field must not be left empty, what the default value is, and what is hidden from the screen entirely.
The idea most trainees do not know: this product provides setup packages that carry configuration between environments. What was configured in a test environment moves to production as a file, rather than being re-entered by hand and then found to be missing an item nobody remembered.
Anybody moving configuration by hand between two environments moves nine items out of ten, and spends a week hunting the tenth.
The fourth rung — approval, and station five’s promise returning
At station five it was said that the credit warning warns and does not block. This is where the block gets built.
An approval workflow actually stops the document: it leaves a postable state for a state awaiting a decision, and does not move until whoever holds the right approves it.
| What is decided | Examples |
|---|---|
| On which document | A purchase order, a sales order, an invoice, a customer card |
| On which condition | Exceeding an amount, exceeding a credit limit, or changing a sensitive field |
| Who approves | The direct manager, or a named officer, or a chain of them |
| And what if they are away | A substitute approver, so work does not stop on one man’s leave |
The last row is the one that gets forgotten, and then discovered at the first annual leave when the company’s whole document flow stands still on one person’s absence.
This rung is entirely functional — with no line of code — and its control value is greater than most of what gets written in code.
Which is where the real rule gets measured: control is built with configuration first, and code is reached for only when configuration cannot do it.
The fifth rung — automation outside the product
What cannot be built inside the product may be built around it.
The companion platform from the same developer connects this product to the rest of the office tools: an email sent on a state, an approval arriving on a phone, a log written into a spreadsheet.
Judge it in two sentences:
It is faster than code, cheaper, and untouched at an update — because it sits outside the code base to begin with.
And it is weaker than code in one essential respect: it does not enforce a rule. Anything built outside the document notifies and does not prevent. Anybody building an accounting control out of an alert builds a control that is read too late.
The sixth rung — the extension, and station two’s promise returning
At station two you built one extension adding one field, and the purpose was to prove the chain works. Now you learn why that chain has that shape.
In its older form the product was edited from the inside: the consultant opened the developer’s code and wrote into it. The result was that every update was a merge project, and that companies stayed on an old release for years because upgrading cost more than standing still.
The current model inverts that: the developer’s code is not touched, and customisation lives in a separate layer that hangs onto it.
| The old model | The current model | |
|---|---|---|
| Where customisation is written | Inside the product’s code | In an independent layer |
| What happens at an update | A manual merge | Redeployment and testing |
| Who knows it exists | Whoever read the code | Registered and known |
That is a genuine architectural difference rather than a marketing description — and it is what makes two waves a year possible at all.
But read the middle row carefully: “not touched” is not “not tested”. An extension survives an update on condition that it stays compatible with what it was built on — and when what sits underneath it changes, it changes or it stops.
The contractual rule to write down: every extension has an owner committed to both wave dates. Anything with no owner is not deployed.
Where you buy rather than write
Between configuration and code sits a rung many people overlook: the ready application on the developer’s marketplace.
Most of what gets asked for in our region — e-invoicing, and the language package — falls here, not in code you write. That is what station eight set out at localisation and Arabic.
The three questions before installing any application: who publishes it, when it was last updated, and does it work alongside your other applications in the same wave?
Every application you install adds a link to a dependency chain that moves twice a year — and a chain breaks at its weakest link, not its newest.
The rule that gets said in a meeting
“Which rung does this request fall on?”
That sentence shortens a whole meeting. Anybody asking it turns a discussion about wishes into a discussion about cost, and anybody who does not leaves with a customisation list written entirely in code, three quarters of which could have been configured.
And the most dangerous sentence in a project: “that’s simple, we’ll write it.” Writing is faster than finding the setting, and its price is paid twice a year for ever.
What you actually do at this station
- Personalise a screen for yourself on the first rung, then open it as another user and prove the personalisation did not travel.
- Set a mandatory field and a default value on the second rung, and save the configuration into a setup package.
- Build a complete approval workflow on a purchase order exceeding an amount, with a substitute approver, and prove the document cannot be posted before approval.
- Edit an invoice layout by adding a statement your country requires, and print it.
- Build a fifth-rung alert on a document state, and write in one line why it is a notification and not a block.
- Extend station two’s extension: add the same field to a report or to another screen, and no more.
- Take five real customisation requests — from your work or from a written scenario — and place them on the ladder by number.
The three commonest errors
One: writing code for what a setting configures. It works from day one, and is paid for twice every year.
Two: building control out of an alert rather than an approval. It looks sufficient, and is read after the document has posted — a moment at which it is no use.
Three: an extension with no owner. It gets built on a project and the contract of whoever built it ends, and then the first wave arrives after they have gone.
What customisation discipline does to the real cost of ownership is set out in the Dynamics 365 Business Central guide.
The acceptance test for this station
- Write the ladder’s six rungs from memory, and the cost of each at an update.
- Build an approval workflow with a substitute approver and prove it objected on a real document.
- Explain the difference between blocking and notifying, and which of them suits an accounting control.
- Explain why the customisation model in this product changed, and what the price was before it.
- Place five requests on the ladder, and write for each why it does not fall on a higher rung.
What comes next
You know where configuration ends and code begins. The final station gathers the whole path into something that can be shown: certification, portfolio and a first job — with an exam that has a name, a number and a duration, and one of whose ironies is that it is available in Arabic while the product is not.