Building Custom Extensions for Business Central

Business Central is built to be extended. Instead of changing Microsoft's code, you add your own in separate extensions that survive every update. This guide explains how extensions work, how they connect Business Central to other systems through APIs, and what a well-run extension project looks like for a UK business.

How the extension model works

An extension is a package, an .app file, that adds to Business Central without editing the base application. Its manifest, app.json, sets the name, publisher, version and the other apps it depends on. Because the base code is untouched, Microsoft can update your environment and the extension keeps working, provided it is maintained.

Extensions add new objects, such as tables, pages, reports and codeunits, and extend existing ones with table extension and page extension objects. A wholesaler that wants an Organic flag on items, for example, adds the field with a table extension and shows it on the Item Card with a page extension.

Key PointKey point: Extensions change behaviour through events. Your code subscribes to events that Microsoft's code raises, which is why it keeps working when the base application is updated.

Building an extension with AL

Extensions are written in AL, the language of Business Central, in Visual Studio Code with Microsoft's AL Language extension. The tools give you code snippets, compiler checks and a way to publish straight to a sandbox for testing. Microsoft's developer overview is the best starting point.

Small changes do not always need code. Designer lets a user add or move fields on a page in the client and save the result as an extension, which is useful for quick layout changes before a developer takes over.

• Per-tenant extensions are built for one customer and installed only in that customer's environment.
• AppSource apps are published on Microsoft AppSource after Microsoft's validation, and any customer can install them.

Pro TipPro tip: Always develop and test against a sandbox, never production. A sandbox with a copy of production data shows how the extension behaves with your real records.

Business Central API integration

Most integration work uses APIs. Business Central publishes standard REST APIs, version 2.0, for common records such as customers, items, sales orders and journals. An external system calls them with OAuth authentication through Microsoft Entra ID, so no passwords are shared between systems.

When the standard APIs do not expose what you need, an extension can add custom API pages and API queries. That keeps the integration inside a versioned, upgrade-safe package rather than a fragile export file. The API v2.0 reference lists every standard endpoint.

Extensions can also call out of Business Central. The HTTP client in AL lets your code send data to another system's API, for example to pass an order to a warehouse platform as soon as it is released.

Watch OutWatch out: Plan for failure. An integration should log every call, retry sensibly and tell someone when a record does not arrive, rather than failing silently.

What a good extension project looks like

• Start with a written description of the business process, not the screen.
• Keep extensions small and focused, so each one can be tested and updated on its own.
• Keep the code in source control. Microsoft publishes its own system modules openly on GitHub.
• Test every extension against each major Business Central release before it reaches production.

Microsoft ships two major releases a year, and extensions need checking against each. Our guide to Business Central upgrades explains how to plan for that, and our extensions roadmap shows the kind of tools we build.

Amplio Solutions builds Business Central extensions and delivers custom development for UK businesses. If you need Business Central to talk to another system, get in touch to talk through the integration.