Page extensions in AL allow developers to customize the user interface of standard Business Central pages without modifying the original pages. They are the only supported way to add fields, actions, or UI behavior to existing pages while keeping the solution upgrade-safe.
This page explains what page extensions are, why they exist, and how they should be used correctly, with practical examples. It builds directly on the Pages in AL topic and prepares the reader for real-world UI customization scenarios.
Why Page Extensions Exist
Standard pages in Business Central are delivered and maintained by Microsoft. Modifying them directly would:
• Be overwritten during upgrades
• Break compatibility with future versions
• Create maintenance and support issues
Page extensions exist to solve this problem. They allow developers to extend UI behavior at runtime while the base page remains unchanged.
This design ensures:
• Upgrade safety
• Predictable behavior
• Clear separation between standard and custom UI
What Is a Page Extension?
A page extension is an AL object that extends an existing page by adding or modifying UI elements. The extension is applied on top of the standard page when the system runs.
A page extension can:
• Add fields to existing groups
• Add new groups or actions
• Modify visibility, editability, or captions
• Reorder UI elements
A page extension cannot:
• Change the source table
• Remove standard fields permanently
• Override core business logic
Basic Structure of a Page Extension
A page extension is defined using the pageextension keyword and references the page it extends.
Example: Page Extension Structure
pageextension 50120 CustomerCardExtension extends "Customer Card"
{
}
The extends clause identifies the standard page that will be customized.
Adding Fields to a Page (With Code)
The most common use of page extensions is exposing new or existing fields on a standard page.
Example: Adding Field
pageextension 50120 CustomerCardExtension extends "Customer Card"
{
layout
{
addlast(General)
{
field("Customer Category"; "Customer Category")
{
ApplicationArea = All;
}
}
}
}
This example:
• Adds a custom field to the Customer Card
• Uses layout modification instead of rewriting the page
• Keeps the base page intact
Controlling Field Behavior in Page Extensions
Page extensions can control UI behavior such as visibility and editability.
Example: UI Behaviour
field("Customer Category"; "Customer Category")
{
ApplicationArea = All;
Editable = true;
Visible = true;
}
These controls are UI-only and do not affect table-level rules.
Adding Actions to a Page (With Code)
Page extensions can also add actions to existing pages.
Example: Adding Action
actions
{
addlast(Processing)
{
action("View Feedback")
{
ApplicationArea = All;
Caption = 'View Feedback';
Image = View;
trigger OnAction()
begin
Message('Custom action executed.');
end;
}
}
}
Actions added through page extensions:
• Appear alongside standard actions
• Follow the same permission and role rules
• Should guide users, not bypass process flow
Modifying Existing Controls
Page extensions allow modification of standard controls using modify.
Example: Modify Standard Field
layout
{
modify("Phone No.")
{
Editable = false;
}
}
This changes UI behavior without touching the underlying table or logic.
Page Extension Triggers (When to Use Them)Page extensions support page-level triggers such as OnAfterGetRecord. These should be used only for UI-specific adjustments, not business rules.
Example: OnAfterGetRecord
trigger OnAfterGetRecord()
begin
// UI-only logic
end;
Business logic belongs in tables or codeunits, not in page extensions.
Where Page Extensions Fit in the Architecture
Page extensions sit between the user and the data, not between processes. Their role is to:
• Surface data already stored
• Guide user interaction
• Improve usability
They should never be used to:
• Enforce core validations
• Control posting logic
• Replace workflows
Common Beginner Mistakes With Page Extensions
Developers often:
• Put business logic in page extension triggers
• Overuse modify instead of add
• Hide errors instead of fixing data rules
• Treat page extensions as process controllers
Avoiding these mistakes leads to stable and maintainable UI customizations.
What This Page Does NOT Cover
To keep this page focused, it does not include:
• Page Parts or FactBoxes
• Role Center customization
• Advanced action patterns
• Event subscribers
Each of these topics is covered later.
Summary
Page extensions in AL provide a safe and structured way to customize standard UI in Business Central. They allow developers to enhance user experience while preserving upgrade safety and system integrity.
A well-designed page extension:
• Adds only what is necessary
• Uses properties before code
• Keeps logic out of the UI layer
• Survives platform upgrades
Practical check: Expose a table-extension field on the Customer Card
Add a 'Delivery Note Required' Boolean to Customer through a table extension, then place it near the relevant shipping controls on the Customer Card.
Steps and evidence to inspect
- Reference the existing source field rather than creating an unbound page variable.
- Set ApplicationArea and a clear caption, and choose addafter/addlast using a symbol-confirmed anchor.
- Publish, test read/edit/save/reopen, then view the card at desktop and narrow viewport widths.
Expected result
The value persists on the customer record and the control follows the page's existing responsive layout. The Base Application page remains unchanged.
If the result is different
A missing field can result from an invalid anchor, ApplicationArea, permissions, personalisation, or publishing the wrong app version. A visible but nonpersistent value is often bound to a variable instead of a table field.
Version and implementation boundary
Base-page controls can be renamed or moved. Compile and visually test against each supported major release and avoid assumptions based only on one profile.
Authoritative reference: Microsoft Learn — Page extension object. The scenario and interpretation above are original to ScrutnLearn.