This page explains what AL objects are, why they exist, and how they collectively form the structure of Business Central extensions. It does not teach how to code individual objects in detail—that is handled in the upcoming dedicated pages (Tables, Pages, Codeunits, Reports, etc.).
The goal of this page is to help learners understand the object-based nature of AL, so they can:
• Choose the correct object type
• Avoid mixing responsibilities
• Read AL codebases with clarity
• Design clean, upgrade-safe extensions
Think of this page as the mental map of AL development.
What Are Objects in AL?
In AL, everything is an object.
You never write free-floating code like in general-purpose programming languages. Every piece of logic, data, or UI must belong to a specific object type.
An AL object is:
• A structured container
• With a defined responsibility
• Interpreted by the Business Central runtime
• Managed and deployed as part of an extension
Objects are how Business Central enforces discipline, predictability, and upgrade safety.
Why AL Is Strictly Object-Based
Business Central is an ERP system that manages:
• Financial data
• Inventory quantities
• Customer transactions
• Regulatory information
Allowing unrestricted code execution would be dangerous.
By enforcing an object-based model, AL ensures:
• Clear separation of concerns
• Controlled execution flow
• Predictable system behavior
• Safe upgrades across versions
This is why choosing the correct object is one of the most important AL skills.
Objects vs Extensions
AL objects do not exist independently at runtime.
They are always packaged inside an extension (app) .
An extension:
• Groups multiple objects together
• Acts as the deployment unit
• Controls versioning and upgrades
• Is the only thing published to Business Central
You never deploy “just a table” or “just a page”—you deploy an extension containing objects.
High-Level Categories of AL Objects
All AL objects can be grouped into five conceptual categories:
1. Data storage objects
2. User interface objects
3. Business logic objects
4. Processing and output objects
5. Security and integration objects
Each category exists to solve a specific ERP problem.
1. Data Storage Objects
These objects define what data exists and how it is stored.
Examples:
• Tables
• Table Extensions
• Enums
Their responsibility is:
• Storing structured business data
• Enforcing data integrity
• Acting as the foundation for all other objects
Data objects do not control UI behavior or business processes directly.
2. User Interface Objects
These objects define how users see and interact with data.
Examples:
• Pages
• Page Extensions
• Control Add-ins (UI-focused)
Their responsibility is:
• Displaying data from tables
• Allowing controlled interaction
• Guiding users through processes
UI objects do not store data themselves and should contain minimal business logic.
3. Business Logic Objects
These objects define how the system behaves.
Examples:
• Codeunits
• Event subscribers
• Interfaces
Their responsibility is:
• Calculations
• Validations
• Automation
• Process orchestration
Business logic objects should not handle UI layout or data storage directly.
4. Processing and Output Objects
These objects define how data is processed or produced.
Examples:
• Reports
• Report Extensions
• XML Ports
• Query objects
Their responsibility is:
• Printing documents
• Batch processing
• Data import/export
• Optimized data retrieval
These objects often execute in the background and may not involve direct user interaction.
5. Security and Integration Objects
These objects define who can do what and how Business Central connects to other systems.
Examples:
• Permission Sets
• Permission Set Extensions
• APIs
• Interfaces
Their responsibility is:
• Enforcing access control
• Exposing controlled integration points
• Supporting extensibility without breaking security
Why Object Responsibility Matters
A common beginner mistake is putting logic in the wrong object:
• Business logic inside pages
• UI behavior inside tables
• Data manipulation inside reports
While AL technically allows some of this, it leads to:
• Hard-to-maintain code
• Unexpected behavior
• Upgrade risks
Professional AL development depends on respecting object boundaries.
How Objects Work Together (Conceptual Flow)
A typical Business Central flow looks like this:
• Tables store data
• Pages display and edit that data
• Codeunits process business logic
• Events connect standard and custom behavior
• Reports / Queries / XML Ports process or expose data
• Permission Sets control access
Each object plays a role in the same transaction, but with clearly separated responsibilities.
Object IDs and NamingEvery AL object:
• Has a numeric ID
• Has a name
• Must follow extension ranges
Object IDs:
• Prevent conflicts
• Support multi-extension environments
• Are part of long-term upgrade safety
Naming should:
• Be descriptive
• Reflect business purpose
• Avoid technical noise
Business Central upgrades:
• Replace standard objects
• Preserve extensions
• Rebind events and extensions
Because AL objects:
• Do not modify base code
• Extend behavior through defined mechanisms
They survive upgrades with minimal risk.
This is why understanding objects is more important than memorizing syntax.
Summary
Objects are the building blocks of AL development. They define how data is stored, how users interact with the system, how business logic runs, and how Business Central remains secure and upgrade-safe.
Understanding objects at a conceptual level is essential before learning to create or extend any specific object type.
Practical check: Separate new objects from extensions in a requirement map
A company wants a new inspection record linked to Item, a list page, a posting check, one summary report, and a field displayed on the existing Item Card.
Steps and evidence to inspect
- Assign new storage to a table and new interaction to a page; put reusable checking logic in a codeunit.
- Use a report for printable/analytical output and a page extension only for the field on the existing Item Card.
- List the permission objects and automated tests needed before deployment.
Expected result
The design does not misuse a page as storage or copy the Item table merely to add one field. Each object can be reviewed and tested by responsibility.
If the result is different
If the same rule appears in page, report, and API paths, it belongs lower in the design. If an extension is proposed for an object AL cannot extend, use events or composition instead.
Version and implementation boundary
Object availability and extensibility evolve by runtime. Confirm the target version and extension points before finalising the design.
Authoritative reference: Microsoft Learn — AL development environment reference overview. The scenario and interpretation above are original to ScrutnLearn.