This document introduces AL as a programming language in practice. Unlike Getting Started with AL, which focused on mindset and architecture, this page answers two concrete questions:
• What exactly is AL from a developer’s perspective?
• How does basic AL code look and behave inside Business Central?
The goal is familiarity, not mastery. By the end of this page, a learner should be able to read simple AL code, understand what it does, and know where it fits in the system.
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.
Your First AL Object: A Simple TableThe easiest way to understand AL is to look at a very simple object.
Example: A Custom Table in AL
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.
Example: A Simple List Page
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.
Example: A Simple Codeunit
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.
Example: Event Subscriber (Conceptual)
[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.
This ensures:• 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.
Practical check: Turn a custom table into an observable feature
Create a simple Equipment Note table with Entry No., Equipment Code, Note, and Created Date, plus a list page for sandbox entry.
Steps and evidence to inspect
- Define field IDs/types from the data need and a primary key that cannot collide.
- Add captions, classification, and a key before writing triggers.
- Create the list page, publish, add two records, close/reopen the page, and confirm persistence and filtering.
Expected result
Two records survive the page session and can be filtered by equipment code. The table owns storage and the page owns interaction.
How to read the important code
The object ID and name identify the table; fields define stored shape; keys define identity and access paths; table properties describe platform behaviour. The primary key is not optional decoration, and a page cannot compensate for a poor data model.
If the result is different
Object-ID collisions and missing dependencies are compile/package errors; a missing page is usually UsageCategory/ApplicationArea/permissions; duplicate Entry No. is a data-key error. Diagnose the layer.
Version and implementation boundary
A teaching table omits production concerns such as number series, retention, upgrade migration, permissions, tests, and concurrency. Add them when the requirement becomes real.
Authoritative reference: Microsoft Learn — AL development overview. The scenario and interpretation above are original to ScrutnLearn.