Business Central

Business Central customisation that survives the next update

Business Central gets two major updates a year, with smaller updates in between. Customisation that was not built with that in mind becomes a recurring cost, and sometimes the reason updates get postponed. You want extensions that simply keep working.

In Business Central, customisation runs as an extension written in AL, alongside the standard code rather than inside it. That is a big step forward, but not a guarantee. An extension that relies on internal objects, ignores events or depends on an app nobody maintains will still break. So the first question is not how something should be built, but whether it should be built at all.

When this fits

A process genuinely differs from the standard, and neither a setting nor an existing app solves it.
Updates are being postponed because nobody is sure what the customisation does.
You have extensions from a previous supplier, without source code or documentation.
You want an existing extension reviewed before you build further on it.

What the engagement covers

Writing code is the smallest part.

First the trade-off: standard functionality, a setting, an existing app, Power Automate or an extension of your own.
Design and build in AL, using events and subscribers, with no dependency on internal objects.
Code analysis with Microsoft's standard analysers (CodeCop, PerTenantExtensionCop and, where relevant, AppSourceCop).
Automated tests for the logic that matters.
Source code in a repository you own, with version control and a build pipeline.
A check of the extension against the preview of the next major update.

What you get

An extension you own, and that someone else can maintain.

The extension, with source code and rights held by you.
A short functional description: what it does, and why the standard was not enough.
Tests and a pipeline that run on every change.
An overview of dependencies on other apps.

What it is not

Not customisation that rebuilds standard functionality.
Not development of commercial apps for sale on AppSource.
Not changes to the standard code, on-premises included.
Not maintenance of C/AL code from NAV. That needs a migration decision first.

Frequently asked questions

What is AppSource hygiene, and why should it matter to me?

Even if your extension never goes near AppSource, the rules Microsoft applies there are a good yardstick: no dependency on internal objects, correct object ID ranges, tidy naming and scoped permissions. An extension that meets them behaves predictably through updates and can be handed to another developer.

Who owns the source code?

You do. I agree that up front. Source code that stays with the builder makes you dependent on that builder for every change.

We have undocumented customisation from a previous supplier. What now?

First, map what is running, what it does and what is still used. Part of it often turns out to be redundant. Then you decide per component: take it over, replace it with standard functionality, or rebuild it.

Could Power Automate do it instead?

Sometimes. For notifications, approvals and simple data flows it is often the quicker route. For logic that has to act on a posting or a document, an extension is more reliable.

More within this service

Need customisation in Business Central?

Describe what the standard does not do. I will tell you honestly whether an extension is the answer, or whether a setting or an existing app will do.

Book an intro call Send a message