Business Central AL Page Design: Patterns That Age Well

A Business Central page is a task surface, not a database-table viewer. Good page design helps a user make a decision or complete work with the least ambiguity. Poor page design exposes implementation fields, runs expensive logic for every row, scatters actions, and becomes difficult to use on smaller screens or through accessibility tools.

AL provides page objects and page extensions for lists, cards, documents, Role Centers, dialogs, APIs, and other supported experiences. Start with the user's job and choose the page type that matches it.

Prefer extension over replacement

When standard Business Central already owns the record and workflow, use a page extension to add or modify the smallest necessary surface. A replacement page duplicates standard evolution and increases testing after every release. Create a new page when the task, source, or navigation is genuinely distinct.

Choose the page type deliberately

• List: scanning, filtering, selecting, and comparing multiple records.
• Card: maintaining one master or setup record.
• Document: header-and-lines business transactions.
• ListPart/CardPart: focused supporting content embedded in another page.
• Worksheet: repeated entry and processing across lines.
• RoleCenter: cues, navigation, and work entry points for a role.
• API: a machine contract; do not reuse a UI page for this purpose.

Organize around the decision

Put the fields required to identify and act on a record first. Group optional or infrequently changed setup separately. Use captions and tooltips that explain business meaning rather than restating the field name. Apply consistent promoted actions so users find the primary command where they expect it.

Microsoft's action-bar guidance follows familiar Microsoft 365 presentation principles. Avoid adding every action to the promoted area. Scope and importance should determine placement.

Keep list pages inexpensive

Microsoft warns that calculated fields, unnecessary page parts, heavy record triggers, and standard pages reused as lookup or web-service endpoints can add work. For large lists:

• remove fields the task does not need instead of only hiding them;
• avoid repeated calculations in OnAfterGetRecord;
• calculate expensive supporting values on demand or in a page background task when appropriate;
• use dedicated lookup pages rather than a full list with unrelated FactBoxes and triggers;
• filter early and load only required data.

Separate UI from business logic

An action trigger should validate the page state and delegate to a codeunit. The codeunit can then be used by a job queue, API, or test without pretending a user interface exists. Guard genuinely optional UI with the documented session checks rather than allowing messages or confirmations to break background execution.

Design for permissions and empty states

A page being visible does not guarantee that the user can execute every action. Define and test the extension's permission sets, then make errors explain the missing business prerequisite without leaking restricted data. Provide useful empty-state guidance when setup or data has not yet been created.

Design for responsive and accessible use

Use meaningful captions, tooltips, groups, and action names. Do not rely on color alone to communicate state. Keep field order and required inputs logical for keyboard navigation. Test at common desktop and narrow client sizes and with realistic translations, because a caption that fits in English may not fit elsewhere.

Test the page and the behavior separately

Use AL test pages when the layout interaction is important: field values, actions, subpages, navigation, and dialogs. Test the delegated codeunit directly for the underlying business rule. This avoids a brittle suite in which every calculation is tested only through the UI.

Page review checklist

1. The page type matches the task.
2. Standard pages are extended rather than copied without need.
3. Primary fields and actions reflect user priority.
4. Triggers do not perform repeated or external heavy work.
5. Business logic is callable outside the page.
6. Permissions, empty, error, and loading states are understood.
7. Keyboard, narrow viewport, translation, and test-page behavior are verified.

Bitta Apps can modernize inherited pages through AL development, investigate slow client experiences through Business Central support, and separate user workflows from integration contracts.