This document provides a structured overview of all major AL object types used in Business Central development. It explains what each object is responsible for, when it should be used, and how objects work together to form a complete ERP extension.
The goal is not to teach how to write each object in detail, but to help learners build a correct mental map of the AL object ecosystem before diving into syntax, properties, and methods.
Why AL Is Object-Based
AL development is built entirely around objects, not free-floating code. Every piece of logic, data, or UI element must belong to a defined object type. This design enforces discipline, predictability, and upgrade safety.
Each AL object:
• Has a clear responsibility
• Participates in the ERP execution flow
• Interacts with other objects in controlled ways
Understanding object roles is essential before writing real-world AL solutions.
Core AL Object Categories
AL objects can be grouped into five core functional categories:
1. Data objects
2. User interface objects
3. Business logic objects
4. Output and processing objects
5. Extension and integration objects
Each category serves a distinct purpose.
Data Objects
TablesTables define how data is stored in Business Central. They represent structured ERP entities such as customers, items, documents, and ledger entries.
A table:
• Defines fields and data types
• Enforces primary keys
• Controls data integrity
• Serves as the foundation for all other objects
Tables do not contain UI logic. They represent business data, not screens.
Table ExtensionsTable extensions allow developers to add fields or logic to standard tables without modifying them.
They are used when:
• Additional data must be stored for standard entities
• Custom logic must react to standard table events
Table extensions are the primary mechanism for safe customization.
User Interface Objects
PagesPages define how users view and interact with data. They are the primary UI objects in Business Central.
Pages:
• Are always bound to a table or query
• Control layout, actions, and interaction
• Do not store data themselves
AL separates data storage (tables) from presentation (pages), which ensures consistency across the system.
Page ExtensionsPage extensions modify existing standard pages by:
• Adding fields
• Adding actions
• Hiding or rearranging UI elements
They allow UI customization without rewriting standard pages.
Business Logic Objects
CodeunitsCodeunits contain business logic and procedures. They are where calculations, validations, and automation live.
Codeunits:
• Do not store data
• Operate on records
• Are often triggered by events or actions
They act as service layers inside the ERP system.
Event SubscribersEvent subscribers allow custom logic to react to standard system events.
They are used to:
• Extend standard behavior
• Validate data
• Trigger automation
• Integrate with external systems
Event-driven design is central to upgrade-safe AL development.
Output and Processing Objects
ReportsReports are used for:
• Document printing
• Batch processing
• Data aggregation
Reports can:
• Generate output (PDF, Excel)
• Perform background processing
• Combine data from multiple sources
They are not limited to printing.
QueriesQueries provide optimized data retrieval for:
• Reporting
• Integrations
• Performance-sensitive scenarios
They define how data is selected, not how it is stored or displayed.
Extension and Integration Objects
Extensions (Apps)All AL objects live inside an extension. An extension is the deployment and versioning unit in Business Central.
Extensions:
• Package AL objects together
• Enable upgrade-safe deployments
• Support version control and lifecycle management
Developers never deploy individual objects—only extensions.
APIsAPIs expose Business Central data and logic to external systems.
They are used for:
• System integrations
• Data synchronization
• External applications
APIs are defined using AL objects but follow REST standards.
How AL Objects Work Together (Conceptual Flow)
A typical flow looks like this:
• Data is stored in tables
• Pages allow users to interact with that data
• Codeunits execute business logic
• Events trigger custom behavior
• Reports and queries process or expose data
• Extensions package everything safely
Each object plays a specific role. Misusing objects leads to unstable solutions.
Choosing the Right Object Type
One of the most important AL skills is choosing the correct object.
Examples:
• Storing data → Table
• Showing data → Page
• Calculating values → Codeunit
• Reacting to system behavior → Event Subscriber
• Printing or batch work → Report
Correct object choice keeps solutions clean and maintainable.
Summary
AL objects define the structure, behavior, and presentation of Business Central extensions. Understanding the role of each object type is essential before writing real-world AL code.
Once this object-level understanding is clear, learning syntax and advanced techniques becomes significantly easier.
Practical check: Plan a tiny extension before writing syntax
A team wants to record a customer follow-up category and display it on the Customer Card. Design the extension on paper before coding.
Steps and evidence to inspect
- Choose a table extension for storage, an extensible enum for controlled values, and a page extension for display.
- Decide whether any reusable validation belongs in a codeunit or table-level logic.
- Build, publish to a sandbox, enter a value, reopen the customer, and uninstall only after recording the data-upgrade implications.
Expected result
Each object has one clear responsibility, the package deploys as an extension, and the value persists through normal page use.
If the result is different
If the field compiles but is absent, inspect app dependencies, ApplicationArea, placement anchor, permissions, and whether the correct tenant/app version received the package.
Version and implementation boundary
This workflow overview does not replace object-specific reference material or automated tests. Object IDs, dependencies, runtime, and target version must match the deployment pipeline.
Authoritative reference: Microsoft Learn — Developing Business Central apps with AL. The scenario and interpretation above are original to ScrutnLearn.