Business Central AL development: extension code, upgrades and tests

What Business Central AL development involves

AL is an object-based language. A developer declares tables, pages, reports, codeunits, queries and enums. To change an object, the developer adds a table extension or page extension. Microsoft's code stays as it is. Business logic hooks into the base application through events and subscribers. So nothing in the base application is overwritten. That keeps updates safe.

Each extension is a project with an app.json manifest. It names the dependencies, the version and the ID range. The AL Language extension for Visual Studio Code downloads symbols from a sandbox, compiles the project and publishes the app. That keeps the edit and test loop short.

When AL code is the right answer

Writing AL makes sense when configuration, personalization, Power Automate and existing add-ons have all been considered. A real gap must remain. Typical cases are an industry calculation or a validation rule tied to your own data. Another is a document flow that the standard product handles in too many clicks. Code is the last step.

It is also the right tool for retiring older customizations. Companies moving from NAV often carry changes made directly in base objects. Those have to be redesigned as extensions. That is a good moment to drop the ones nobody uses. We then rewrite the rest cleanly.

Our Business Central AL development workflow

Every extension lives in a Git repository from the first commit. Developers work on branches and open pull requests. Another developer reads each change before it merges. Code analyzers such as CodeCop and UICop run in the editor and in the build. So style and upgrade problems show up early.

We automate builds with pipelines, commonly AL-Go for GitHub or Azure DevOps. The pipeline compiles the app and runs test codeunits in a container. It then produces a build artifact. Nobody installs anything in production by hand from a laptop. Because of that, every release traces back to a commit.

What you receive with each extension

You own the source code. At handover, you receive the repository and the compiled app file. You also get a short technical note on the objects and events used. A user note explains what changed on screen. Permission sets for the new objects come too, so administrators can assign access straight away. It is yours to keep.

Extensions that change data structures come with upgrade codeunits. These move existing data safely when a new version installs. The tests we write stay in the repository. You can run them again whenever Microsoft publishes a new release. That makes each update a routine check instead of a fresh risk.

Pitfalls that make extensions hard to maintain

The usual problems are not clever bugs. They are extensions with no tests and object names with no prefix, which later clash with another app. Others place logic in page triggers, where an integration skips it. Heavy loops are another cause. They slow a posting routine for every user. Each one is avoidable.

Another pitfall in Business Central AL development is to ignore obsoletion warnings. Microsoft marks fields and procedures as obsolete a few releases before it removes them. The compiler reports it. A team that reads those warnings has an easy update. A team that does not finds out when the app stops installing. Reading the warnings takes little time.

Business Central AL development questions

What is AL in Business Central?

AL is the programming language used to build extensions for Business Central. It replaced the older C/AL language from Dynamics NAV. Developers write it in Visual Studio Code. They package their work as apps that install on top of the base application. Because the base stays untouched, Microsoft can update it while your extensions keep working in most cases.

Will Business Central AL development break at the next update?

Extensions are built to survive updates, because they do not change Microsoft's code. Problems arise only when an extension relies on something that Microsoft later removes. To find those cases early, we compile against the next version in a sandbox before the update. Then we fix what the compiler reports. Your users see a normal update, not a surprise.

What is the difference between a per-tenant extension and a published app?

A per-tenant extension is built for one company and uploaded to its environment. A published app goes through Microsoft's technical validation. It is then offered to many customers through the marketplace. Most custom work for a single business is a per-tenant extension. If you plan to sell an app, we write it to pass that validation from the first commit.

Can you take over AL code written by another developer?

Yes, provided the source code is available. We read through the repository and compile it against the current release. Then we note the risks and agree with you what to fix first. If the source is missing, the features usually have to be rebuilt. We tell you that early, before you plan around code that cannot be changed.

Do you develop directly in our production environment?

No. Development and testing happen in sandbox environments or local containers. An extension reaches production only after it has passed its tests. Your key users must also try it in a sandbox that holds a copy of your data. After that, we publish it at a time that suits your team.

Related development services

Business Central AL development connects to several neighboring services. These pages cover general development, extension upkeep, automated testing and build pipelines. Together they keep custom code healthy across releases. If you have a gap that code might close, use the contact page to talk with our developers about Business Central AL development. For the product detail, see Development in AL, overview on Microsoft Learn.