Table Extensions in AL

Overview of Microsoft Dynamics 365 Business Central

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

AL

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;
        }
    }
}
    
Understanding the Components

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 Extensions

Extended 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 Extensions

Just 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

AL

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

AL

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

AL

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

Next Steps in Business Central