What Is AL and How to Code in AL

What AL Is in Practical Terms

AL is a strongly typed, event-driven, object-based language designed specifically for Business Central. It is used to define ERP objects such as tables, pages, reports, and codeunits, and to extend existing standard objects safely.

Unlike general-purpose languages, AL is:

• Deeply aware of ERP concepts (items, customers, posting, documents)
• Built around Business Central’s data model
• Restricted by design to protect system stability and upgrades

In AL, developers do not write standalone programs. They write extensions that run inside Business Central’s execution model.

Core Building Blocks of AL Code

Every AL solution is composed of objects. Each object has a specific responsibility.

Common AL object types include:
• Tables (store data)
• Pages (display and edit data)
• Codeunits (business logic)
• Reports (output and processing)
• Extensions (modify standard objects)

You never “start with main()” in AL. You start by defining an object.

The easiest way to understand AL is to look at a very simple object.

table 50100 "Customer Feedback"
{
    DataClassification = CustomerContent;

    fields
    {
        field(1; "Entry No."; Integer)
        {
            DataClassification = SystemMetadata;
        }

        field(2; "Customer No."; Code[20])
        {
            DataClassification = CustomerContent;
        }

        field(3; "Feedback Text"; Text[250])
        {
            DataClassification = CustomerContent;
        }
    }

    keys
    {
        key(PK; "Entry No.")
        {
            Clustered = true;
        }
    }
}

    

This example shows several important AL concepts:
• Every object has an ID and name
• Fields are explicitly defined with data types
• Data classification is mandatory
• Primary keys must be declared
• The object represents structured ERP data, not arbitrary variables

Even at this basic level, AL enforces business discipline.

Pages: How AL Displays Data

Tables store data, but users interact with pages. Pages define how data is shown and edited.

page 50101 "Customer Feedback List"
{
    PageType = List;
    ApplicationArea = All;
    SourceTable = "Customer Feedback";

    layout
    {
        area(content)
        {
            repeater(Group)
            {
                field("Entry No."; "Entry No.") { }
                field("Customer No."; "Customer No.") { }
                field("Feedback Text"; "Feedback Text") { }
            }
        }
    }
}
    

• Pages are directly linked to tables
• AL separates data from presentation
• The layout section defines UI structure
• No manual UI rendering logic is needed

This reflects Business Central’s metadata-driven UI model.

Writing Logic in AL: Codeunits

Business logic in AL is written inside codeunits. Codeunits contain procedures that execute logic, validations, or automation.

codeunit 50102 "Feedback Management"
{
    procedure CreateFeedback(CustomerNo: Code[20]; TextValue: Text[250])
    var
        Feedback: Record "Customer Feedback";
    begin
        Feedback.Init();
        Feedback."Entry No." := Feedback.Count + 1;
        Feedback."Customer No." := CustomerNo;
        Feedback."Feedback Text" := TextValue;
        Feedback.Insert();
    end;
}
    

• AL procedures resemble structured business actions
• Records represent table data
• Insert, Modify, and Delete are controlled ERP operations
• Logic is explicit and readable

This is how ERP logic is encoded, not through free-form scripts.

Event-Driven Coding: A Core AL Concept

One of the most important aspects of AL is that developers rarely override standard behavior. Instead, they react to events.

[EventSubscriber(ObjectType::Table, Database::Customer, 'OnAfterInsertEvent', '', false, false)]
local procedure OnCustomerCreated(var Rec: Record Customer)
begin
    Message('Customer %1 was created.', Rec."No.");
end;
    

This shows how AL:

• Hooks into standard behavior
• Adds logic without changing base code
• Remains upgrade-safe

AL code runs:

• When users perform actions (open pages, post documents)
• When events are raised by the system
• When processes are triggered automatically

Developers do not control execution order freely. Business Central does.

• Predictable system behavior
• Controlled data integrity
• Stable upgrades

How to Think When Writing AL Code

When writing AL, developers should always ask:

• Does standard functionality already exist?
• Is configuration sufficient?
• Which object owns this behavior?
• Which event is safest to use?

AL rewards minimal, precise code, not large custom solutions.

Summary

AL is the language that allows Business Central to be extended in a safe, structured, and upgrade-friendly way. It is not a general programming language but an ERP-focused tool designed around business logic, data integrity, and controlled execution.

At this stage, learners should focus on understanding what AL code looks like and how it fits into Business Central, not on writing complex solutions.