Most UK companies that ask about Business Central development are really asking a different question: how far can the system be bent around the way we work, and what will that cost us later? The honest answer is that Business Central can be adapted a long way, but every step away from the standard product adds something to test, document and support. The skill lies in choosing the lightest tool that solves the problem.
This page sets out the three levels of customisation, the way Microsoft expects developers to work, what happens to your changes at each upgrade, and how to assess the person or firm you hand the work to.
Three levels of Business Central customisation
Think of customisation as a ladder. Start on the bottom rung and climb only when it fails you.
| Level | What it means | Who does it | Upgrade risk |
|---|---|---|---|
| Configuration | Setup, number series, posting groups, approval rules, page layouts | Consultant or trained key user | Very low |
| Existing extension | An app installed from Microsoft Marketplace | Consultant | Low, depends on the publisher |
| Bespoke extension | Code written for your business in AL | Developer | Moderate, managed by testing |
Level one: configuration
A large share of requests that arrive as "we need a custom module" turn out to be setup. Posting groups, dimensions, approval workflows, item tracking, user-specific page views and report layouts can all be shaped without a line of code. Configuration is also the level your own finance team can maintain, which matters when your accountant asks why a posting landed where it did.
The in-client Designer sits at the edge of this level. It lets you rearrange or add fields on a page by drag and drop and preview the result, so simple layout changes can be made without leaving the interface. If a change is only about what a user sees, begin here.
Level two: existing extensions
Online, Business Central is extended through apps, also called extensions, installed from Microsoft Marketplace. Microsoft also provides Connectivity Apps and Banking Apps pages that list applications for linking to external services, including the import of bank transactions. For a UK business, that is often the quickest route to a working bank feed.
The Shopify connector is a good example of what a mature app can do. It synchronises products, stock, customers, orders, shipments, transactions and payouts, supports several shops, and imports orders from online shops, Shopify POS and B2B. Synchronisation can run in the background through the job queue, with detailed logging for troubleshooting. If you sell online, this is a far better starting point than a bespoke integration. Our page on integrations and connectors goes further.
Buying an app is not free of obligation. Check who publishes it, how it is supported and whether the publisher keeps pace with each Business Central release.
Level three: bespoke extensions in AL
When the process is genuinely specific to you, such as an unusual costing method, a trade-counter workflow or a regulatory report, a developer writes an extension. The language is AL, written in Visual Studio Code. An extension can add or change tables, pages, codeunits and reports without modifying the base code, and it compiles to an .app file.
That separation is the whole point. Your code sits on top of Microsoft's rather than inside it, which is what makes upgrades practical.
How Business Central development should be done
Good practice is not mysterious. It is a short list of habits that good developers follow and poor ones skip.
Work in a sandbox
Sandbox environments are designed for development. The debugging endpoint is open by default and developers publish straight from Visual Studio Code. Outgoing HTTP calls from extensions are blocked in a sandbox until they are allowed extension by extension, which protects you from a test build contacting a live service by accident.
Production should receive only what has been built and proved in a sandbox. If a supplier proposes to code directly in your live environment, treat that as a warning sign.
Prefer the API over workarounds
Business Central exposes a REST API (version 2.0) for connecting to third-party solutions, and the APIs are enabled by default online. Two limits shape design decisions:
- Fields cannot be added to a standard API. The developer copies the AL code and creates a custom API.
- OData limits are applied per user: five simultaneous requests, one hundred connections and a sliding window of six thousand requests over five minutes. Beyond that the service returns HTTP status 429.
Microsoft recommends the API or OData rather than SOAP, which is expected to be deprecated. If a supplier proposes a new SOAP-based integration, ask why.
A Business Central environment can also be linked to a Power Platform environment of the same type, production or sandbox. The link is exclusive and becomes the default target for integrations with Power Platform and other Dynamics 365 products. Settle this before anyone builds a flow.
Stay close to the standard
Every customisation is something you own: you test it, you pay to change it and you carry it through each release. The most reliable rule is to keep the standard process unless the difference creates real value. Adopting a standard workflow often saves more than the bespoke one would ever return.
Document and test
Each extension should have a short document stating what it does, why it exists, which standard objects it touches, who approved it and how to test it. Without that, the knowledge sits in one developer's head. When that developer leaves, you are left with code nobody dares touch. Our requirements template guide helps you write down the need before any code is commissioned.
What customisation does to upgrades
Business Central online is updated regularly, and your version and edition determines how those updates reach you. Because well-built extensions do not alter the base code, an upgrade does not require rewriting your customisations. Three risks remain:
- An extension relies on a behaviour or object that Microsoft changes in a later release.
- A third-party app from Marketplace has not been updated by its publisher in time.
- Two extensions touch the same area and interfere with each other.
All three are caught the same way: install the new release in a sandbox, run your test scripts against the processes that matter, and fix problems before production. Whoever provides your support and maintenance should already do this as routine. If they do not, ask them to.
Customisation also affects how you migrate from an older system or version. Heavily modified legacy code is often the main reason a move takes longer than hoped, so the fewer bespoke objects you carry, the easier any later change becomes.
UK points that often drive customisation
Business Central is localised by Microsoft for the United Kingdom, so VAT handling and standard reports arrive in the product. That should be your starting point. Most UK-specific needs are then met by setup or by an existing app rather than by code.
Real customisation tends to appear in a few places:
- VAT and Making Tax Digital: the product and its extensions handle the submission route, but your own VAT schemes, partial exemption or sector rules may need extra reporting. See our guide to Making Tax Digital and your ERP.
- Payroll and RTI: payroll is commonly handled by a specialist package linked to the ledger, and the link is where development is usually needed. Read about payroll and RTI before commissioning anything.
- Sector processes: manufacturers, distributors and contractors often have costing or job rules the standard does not capture. Check the modules first, because the need may already be covered.
Ask your accountant to review any customisation that changes how entries post. A neat piece of code that posts to the wrong account is worse than no code.
How to evaluate a Business Central developer or integrator
The people who write your extensions shape your next several years, so choose with care. Put these questions to any candidate:
| Question | What a good answer sounds like |
|---|---|
| How do you decide between setup, an app and code? | They try configuration first and justify code in writing |
| Where do you develop and test? | In a sandbox, never directly in production |
| How do you document an extension? | A short, standard document handed over with each delivery |
| What happens at each Microsoft release? | A tested upgrade path and a named person responsible |
| Who supports it after go-live? | A clear support arrangement, not goodwill |
| Can you show similar work? | Descriptions of comparable projects, with references on request |
Be wary of anyone who never says no. A partner who accepts every request without challenge is building up cost for you. Our guide to choosing a Business Central partner covers the wider selection process, and the implementation page shows where customisation fits in a project. If a project has already gone wrong, an audit and project rescue can show which customisations are worth keeping.
On cost, see Business Central pricing for licence figures. Development effort is quoted by the integrator against your scope, so we do not publish a figure here.
Next step
If you are weighing up a customisation, write down the business outcome first, then ask two or three integrators how they would deliver it with the least code. Our service is free and puts you in touch with integrators suited to your project; the how it works page explains the process.
Frequently asked questions
What language is used for Business Central development?
Business Central is customised with extensions written in the AL language, developed in Visual Studio Code. An extension can add or modify tables, pages, codeunits and reports without touching the base application code, and it is compiled into an .app file that is installed on the environment.
Will a customisation stop me upgrading Business Central?
Not if it is built as an extension, because the base code stays untouched and the extension is installed on top of it. An upgrade can still expose a problem if the extension depends on something Microsoft has changed, which is why every extension should be tested in a sandbox before a new release reaches production.
Can I add a field to a standard Business Central API?
No. Fields cannot be added to a standard API. Your developer has to copy the AL code of the standard API and build a custom API from it. It is a small piece of work, but it is development, so it needs documenting and testing like any other extension.
Should I buy an extension from Microsoft Marketplace or have one built?
Look at the Marketplace first when the need is common, such as a connector to an online shop or a bank import. A built extension makes sense when the process is specific to your business and no existing app covers it. Either way, ask who maintains it and what happens when Microsoft ships a new release.
How do I judge a Business Central developer or integrator?
Ask how they separate configuration from code, whether they work in a sandbox before production, how they document each extension and who supports it after go-live. Ask to see how they handle UK requirements such as VAT and Making Tax Digital reporting. A good partner is as comfortable saying no to a customisation as building one.
Sources
- Microsoft Learn — Developing for Business Central
- Microsoft Learn — Environments in the admin centre
- Microsoft Learn — Business Central API v2.0
- Microsoft Learn — Extending Business Central with apps
- Microsoft Learn — About localisation
Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.