What Is AL in Business Central? Extensions Explained

AL is the programming language used to build extensions for Dynamics 365 Business Central. If you have heard of C/AL from Dynamics NAV, AL is its successor, with a different development model: instead of editing the base application, you write extensions that sit on top of it. This article explains the moving parts with a small working example.

From C/AL to AL

In Dynamics NAV and early Business Central versions, developers edited the application directly in the Development Environment using C/AL. That made upgrades painful, because every change to Microsoft's code had to be merged again. AL replaced it, and with it came a rule: you never modify the base application. You extend it.

AL is written in Visual Studio Code using Microsoft's AL Language extension, and the result of a project is a package (an .app file) that is published to a Business Central environment.

What an extension is made of

An AL project contains an app.json file and a set of .al files. app.json declares the extension's identity (name, publisher, version), the platform and application versions it targets, the object ID ranges it may use and any dependencies on other extensions. Each .al file defines one or more objects. The commonly used object types are:

• Table and table extension: define or add data fields.
• Page and page extension: define or adjust the user interface.
• Codeunit: holds business logic, as procedures.
• Report and report extension: data sets and layouts for printing and export.
• Query and XMLport: data access and file import or export.
• Enum and interface: extensible option lists and contract-based polymorphism.
• Permission set: what users may do with your objects.

A small example

Suppose finance wants to warn users when a new sales amount would take a customer over their credit limit. Put the logic in a codeunit:

codeunit 50110 "CE Credit Checks"
{
    procedure IsCreditLimitExceeded(CustomerNo: Code[20]; NewAmountLCY: Decimal): Boolean
    var
        Customer: Record Customer;
    begin
        if not Customer.Get(CustomerNo) then
            exit(false);

        if Customer."Credit Limit (LCY)" = 0 then
            exit(false); // 0 means no limit

        Customer.CalcFields("Balance (LCY)");
        exit(Customer."Balance (LCY)" + NewAmountLCY > Customer."Credit Limit (LCY)");
    end;
}

Then add a field to the customer card through extension objects, without touching the original table or page:

tableextension 50110 "CE Customer Ext" extends Customer
{
    fields
    {
        field(50110; "CE Credit Note"; Text[100])
        {
            Caption = 'Credit Note';
            DataClassification = CustomerContent;
        }
    }
}

pageextension 50110 "CE Customer Card Ext" extends "Customer Card"
{
    layout
    {
        addlast(General)
        {
            field("CE Credit Note"; Rec."CE Credit Note")
            {
                ApplicationArea = All;
                ToolTip = 'Internal note about this customer''s credit arrangement.';
            }
        }
    }
}

Three things are worth noticing. The logic is in a codeunit, not in the page, so it can be tested and reused. The new field lives in a table extension, so the base Customer table is untouched. And the object IDs come from the range declared in app.json.

Events: how extensions hook into Business Central

Extension objects add things. To change what happens (for instance during posting), AL uses events: Microsoft's code raises an event at defined points, and your code subscribes to it. That pattern is the heart of upgrade-safe customization, and it has its own article: AL event subscribers explained.

Tools that keep extensions healthy

• Code analyzers: CodeCop, UICop, AppSourceCop and PerTenantExtensionCop flag rule violations and upgrade risks during the build.
• Test codeunits: automated tests for logic that matters, such as calculations and posting behaviour.
• The AL debugger: attach to a sandbox session, set breakpoints and inspect variables.
• Telemetry: Application Insights integration to see errors and slow operations after release.

Common beginner mistakes

• Putting business logic in page triggers, where it cannot be reused or tested.
• Hard-coding values such as account numbers or user names.
• Looping over large tables without filters or keys, causing slow pages.
• Ignoring permissions, so users cannot access the new objects.
• Skipping DataClassification on fields, which matters for privacy handling.

Where to go from here

If you are a business looking for custom functionality, see our AL development and customization services. If you want to learn AL yourself, our Business Central technical training covers the language, tools and real-world scenarios, and the guide on starting a career as a Business Central consultant explains how the pieces fit together.