Table Extensions in AL
This page explains what table extensions are, why they exist, and how they are used to safely customize standard Business Central tables. It builds directly on the Tables in AL topic and answers a critical ERP question:
If tables define all business data, how do we customize them without breaking upgrades?
The answer is Table Extensions.
Why Table Extensions Exist
In Business Central, standard tables are never modified directly. Microsoft delivers new versions frequently, and direct modifications would:
• Be overwritten during upgrades
• Break compatibility
• Make maintenance impossible
Table extensions exist to solve this problem.
A table extension allows you to:
• Add new fields to standard tables
• Add keys and field groups
• Add limited logic through triggers
• Do all of this without touching the base table
This is the foundation of upgrade-safe customization.
What Is a Table Extension?
A table extension is an AL object that extends an existing table by adding new elements to it.
Key characteristics:
• It does not create a new table
• It does not replace the original table
• It becomes part of the table at runtime
• It survives upgrades safely
From the user’s perspective, extended fields behave exactly like standard fields.
When You Should Use a Table Extension
You should use a table extension when:
• You need to store additional business data
• The data logically belongs to an existing standard table
• Configuration alone is not sufficient
• The requirement must persist long-term
Examples:
• Adding a “Customer Category” to Customer
• Adding “Warranty Expiry Date” to Item
• Adding “Internal Reference” to Sales Header
When You Should NOT Use a Table Extension
A table extension should not be used when:
• The data is temporary or calculated
• The requirement belongs to a separate business entity
• The data is purely UI-related
• The logic can be solved using setup tables instead
In such cases, creating a new custom table is often the better choice.
Basic Structure of a Table Extension
A table extension is defined using the tableextension object.
Simple Table Extension Example
tableextension 50101 CustomerExtension extends Customer
{
fields
{
field(50100; "Customer Category"; Code[20])
{
DataClassification = CustomerContent;
Caption = 'Customer Category';
}
field(50101; "Preferred Delivery Day"; Option)
{
OptionMembers = Monday,Tuesday,Wednesday,Thursday,Friday;
DataClassification = CustomerContent;
}
}
}
Extends Clause
extends Customer
This tells Business Central:
• Which table is being extended
• Where the new fields will appear
The extension becomes part of the table at runtime.
Field Numbers in Table ExtensionsExtended fields must:
• Use numbers in your assigned range
• Never conflict with standard fields
• Remain stable across versions
Changing field numbers later can cause data loss.
DataClassification in ExtensionsJust like standard tables, extended fields must declare DataClassification.
This ensures:
• Compliance
• Consistency
• Proper data handling during export or audit
Adding Keys in a Table Extension
Table extensions can add secondary keys.
Example: Adding Secondary key in Table Extension
keys
{
key(CategoryKey; "Customer Category")
{
}
}
Why this matters:
• Improves filtering performance
• Supports reporting scenarios
You cannot change the primary key of a standard table.
Adding Field Groups (High-Level)
Field groups control how fields appear in lookups.
Example: Using FieldGroup
fieldgroups
{
fieldgroup(DropDown; "Customer Category")
{
}
}
This improves usability without UI code.
Triggers in Table Extensions (Important Guidance)
Table extensions support triggers such as:
• OnValidate
• OnInsert
• OnModify
However, use them sparingly.
Example: Simple Validation
field(50102; "Credit Rating"; Integer)
{
trigger OnValidate()
begin
if "Credit Rating" < 0 then
Error('Credit Rating cannot be negative.');
end;
}
Best practice:
• Use properties first
• Use triggers only for true data rules
• Avoid complex logic here
Upgrade Safety and Table Extensions
During an upgrade:
• Standard tables may change
• Table extensions are reapplied
• Data in extended fields is preserved
This is why table extensions are mandatory for modifying standard behavior.
Common Beginner Mistakes With Table Extensions
• Using wrong field number ranges
• Putting heavy business logic in triggers
• Extending tables unnecessarily
• Forgetting DataClassification
• Treating table extensions like new tables
Avoiding these mistakes leads to stable extensions.
Summary
Table extensions are the only supported way to add custom data to standard Business Central tables. They allow developers to extend the data model safely, predictably, and upgrade-proof.
A well-designed table extension:
• Adds only necessary fields
• Uses correct ranges
• Minimizes triggers
• Preserves data across upgrades
Understanding table extensions is essential for real-world Business Central development.
Hot Topics in Business Central