Why extensions, not modifications
In Dynamics NAV, customisations were written straight into the base code. Every upgrade meant finding each change, merging it by hand and testing everything again, which is why so many NAV systems were left versions behind.
Business Central online does not allow that. Every change is an extension written in AL, installed alongside the base application. It adds to Microsoft's tables and pages and reacts to published events, but never edits them. When the April and October release waves arrive, Microsoft updates the base and your extension carries on, provided it was written to the rules.
The pieces most Business Central customers end up needing.
Fields, tables & pages
Table and page extensions add the fields your process needs to customers, items, orders and ledger entries, shown where people actually work.
- βTable and page extensions
- βNew setup and document pages
- βRole Centre tiles and cues
- βPermission sets for every new object
Business rules & workflows
Event subscribers enforce your rules at posting, release and approval time without touching base code.
- βValidation on posting and release
- βPricing, discount and credit rules
- βApproval workflow responses
- βJob queue tasks that run overnight
Reports & documents
Report extensions and custom layouts for invoices, pick lists, statements and management reports, in Word, RDLC or Excel.
- βReport extensions
- βWord and Excel layouts
- βCustom document reports
- βScheduled report delivery
APIs & integrations
API pages and web services so other systems can read and write Business Central data safely, with Power Automate and Azure Logic Apps where they fit.
- βCustom API pages
- βInbound and outbound web services
- βPower Automate and Logic Apps flows
- βEDI, ecommerce and payroll feeds

How an extension goes from request to production.
- 1
Check the standard first
Before writing code we confirm the need is not already met by a setup option, an existing app on AppSource or a Power Automate flow. The cheapest extension is the one you never need.
- 2
Write the specification
A short document lists every field, page, rule and report, plus how it will be tested. You approve it and the price before development starts.
- 3
Develop and test in a sandbox
Code is written in Visual Studio Code with the AL language tools, kept in source control, and covered by automated test codeunits that run on every build.
- 4
Your team accepts it
Your users try the change in a sandbox copy of your company with real data and sign off before anything reaches production.
- 5
Release and watch
The extension is published to production outside working hours, and telemetry is checked afterwards so errors surface before users report them.
Per-tenant extension or AppSource app?
Business Central extension questions
Will an extension break when Microsoft updates Business Central?
Not if it follows the extension model: no base code edits, only published events and supported objects. We also test every extension against the preview of the next release wave, so obsolete calls are replaced before the update reaches you.
Can our old NAV customisations be moved to Business Central?
Yes. C/AL modifications are reviewed one by one. Many are no longer needed because the standard product now covers them; the rest are rewritten as AL extensions.
Who owns the code?
You do. The source is kept in a repository you can access, and the extension is installed under your tenant.
Do you also support extensions someone else wrote?
Yes. We review the existing code first and tell you in writing what is sound, what is risky and what we would change, before taking it over.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.
