Pages in AL

What Is a Page in AL?

A page in AL is a user interface object that displays data from one or more tables and allows users to interact with that data in a controlled way. Pages act as a bridge between stored business data and human interaction.

A page defines:

• What data is shown to the user
• How data is grouped and laid out
• Which actions users can perform
• When records can be created, modified, or deleted

A page does not:

• Store data
• Own business rules
• Control posting logic

Those responsibilities belong to tables and codeunits.

Why Pages Exist in Business Central

Business Central is designed to be used by non-technical users. Raw database tables are not suitable for direct interaction. Pages exist to:

• Present business data in a readable format
• Guide users through correct data entry
• Enforce UI-level rules before data reaches the table
• Reduce errors through layout, visibility, and enablement

Pages allow the system to be user-friendly without compromising data integrity.

Relationship Between Pages and Tables

Every page is bound to a data source, usually a table. This relationship is defined using the SourceTable property. Pages never create their own data model; they only reflect and manipulate data defined elsewhere.

Because of this:

• A page cannot exist meaningfully without a table
• Multiple pages can exist for the same table
• Different pages can present the same data differently for different roles

This separation ensures that data structure remains stable even if UI changes.

Common Types of Pages in AL

Pages are designed around user intent rather than technical structure. Each page type serves a specific interaction purpose.

Card pages are used to view and edit a single record in detail. They are commonly used for master data such as customers, vendors, and items.

They allow:

• Full visibility of all related fields
• Structured grouping of information
• Detailed editing of a single entity

page 50110 "Customer Feedback Card"
{
    PageType = Card;// change this as per your type, whether it is card part, list part, list, factbox, standard dialogue etc.
    SourceTable = "Customer Feedback";
    ApplicationArea = All;
    UsageCategory = Administration;

    layout
    {
        area(Content)
        {
            group(General)
            {
                field("Entry No."; "Entry No.")
                {
                    ApplicationArea = All;
                }

                field("Customer No."; "Customer No.")
                {
                    ApplicationArea = All;
                }

                field("Feedback Text"; "Feedback Text")
                {
                    ApplicationArea = All;
                }

                field("Created Date"; "Created Date")
                {
                    ApplicationArea = All;
                    Editable = false;
                }
            }
        }
    }
}

    

List pages display multiple records in a tabular format. They are typically used for searching, filtering, and selecting records.

They support:

• Sorting and filtering
• Quick overview of many records
• Navigation to card or document pages

Document pages represent business documents with a header–line structure, such as sales orders or purchase invoices.

They are designed to:

• Guide users through transactional workflows
• Separate header information from line details
• Support posting and document lifecycle actions

Worksheet and journal pages are used for batch entry and processing, especially in finance and inventory.

They support:

• Rapid data entry
• Validation across multiple lines
• Posting or processing in bulk

Structure of a Page in AL

A page definition typically consists of:

• Page properties
• Layout definition
• Actions
• Optional triggers

Each part serves a different purpose and should be kept cleanly separated.

Page properties define overall behavior of the page. They control:

• Page type
• Data source
• Editability
• Insert, modify, and delete permissions
• Visibility and application scope

These properties are evaluated before any code runs and should be the first tool used to control page behavior.

The layout section defines how data is presented visually. It controls:

• Grouping of fields
• Ordering of information
• Whether data appears as a list, card, or document

Layouts should be designed to:

• Follow business logic
• Reduce cognitive load
• Prevent incorrect data entry

Layout decisions have a major impact on usability.

Actions represent things users can do from a page. These include:

• Creating records
• Navigating to related data
• Running processes
• Posting or validating information

Actions should:

• Be clearly named
• Be enabled or disabled based on context
• Guide users toward correct system usage

Pages should guide behavior, not just react to errors.

Sample example:

actions
{
    area(Processing)
    {
        action(ShowCustomer)
        {
            ApplicationArea = All;
            Caption = 'Open Customer';
            Image = Customer;

            trigger OnAction()
            var
                CustomerRec: Record Customer;
            begin
                if CustomerRec.Get("Customer No.") then
                    Page.Run(Page::"Customer Card", CustomerRec);
            end;
        }
    }
}

    

Pages support triggers such as:

• OnOpenPage
• OnAfterGetRecord
• OnNewRecord

These triggers should be used sparingly and only for:

• UI initialization
• Calculated display values
• Context-sensitive behavior

Business rules and validations should not live primarily in page triggers.

Role of Pages in Upgrade Safety

Pages are among the most frequently customized objects, but direct modification of standard pages is not allowed. Instead:

• Standard pages remain untouched
• Custom behavior is added using page extensions (next topic)
• UI customizations remain upgrade-safe

This design allows Microsoft to evolve the UI without breaking partner solutions.

Common Beginner Mistakes With Pages

Developers new to AL often:

• Put business logic in page triggers
• Use pages to enforce data integrity
• Overuse actions instead of workflow
• Treat pages as data owners

These mistakes lead to fragile solutions and should be avoided.

Summary

Pages in AL define how users interact with business data, not how data is stored or processed. They act as a controlled interface layer that balances usability with data integrity.

A well-designed page:

• Makes correct behavior easy
• Prevents common errors
• Reduces training effort
• Keeps logic where it belongs

Understanding pages properly is essential before learning how to extend or customize them.