ADVERTISEMENT
AL Objects and Extensibility

Table Extensions in AL

Learn about table extensions in AL and how to extend existing tables in Business Central. Understand adding fields, modifying keys, and best practices for table extensions.

What you will accomplish

Use a table extension to add fields, secondary keys, field groups, and limited extension logic to an existing table. It preserves the base table's identity and data while keeping custom schema in an app.

Before you start

Understand the base table, field ID range, data classification, upgrade lifecycle, and whether the value truly belongs on that entity.

Expected learning result

You should be able to add one persistent field, validate it through normal entry paths, expose it on a page, and plan what happens to its data during app upgrades or uninstall.

Table Extensions in AL
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:

AL code
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

ADVERTISEMENT

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.

ADVERTISEMENT

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.

Practical check: Add a governed customer reference field

Add an optional external service reference to Customer. It must be searchable, length-limited, classified, and visible on the Customer Card.

Steps and evidence to inspect

  1. Choose a unique field ID and a Code/Text length based on the external system's real constraint.
  2. Set Caption and DataClassification, add validation only for a documented business rule, and expose it with a page extension.
  3. Enter, filter, export/configuration-test, upgrade the app version, and confirm the value persists.

Expected result

The value is stored on Customer, available to supported consumers with permission, and remains isolated from Microsoft's base source.

If the result is different

Duplicate IDs fail compilation; missing values after republish can indicate app identity/version or destructive schema handling; poor filters may point to an unnecessary key or unsuitable field type.

Version and implementation boundary

Adding schema has data-upgrade and uninstall consequences. Back up and migrate extension data deliberately; never repurpose a shipped field ID for unrelated meaning.

Authoritative reference: Microsoft Learn — Table extension object. The scenario and interpretation above are original to ScrutnLearn.

Stay Updated

Get the latest tutorials, tips and resources delivered to your inbox.