Enums in AL are used to define a fixed, named set of values that represent business states, categories, or options in a clear and maintainable way. They replace the older Option data type and provide a much safer, extensible, and upgrade-friendly approach to handling controlled values in Business Central.
This page explains what enums are, why they exist, how they are used, and how they are extended using Enum Extensions. The goal is to help learners understand enums not just as a data type, but as a business modeling tool.
What Is an Enum in AL?
An enum (enumeration) is an AL object that defines a named list of possible values. Each value represents a meaningful business state rather than a technical number or string.
An enum:
• Represents a controlled set of values
• Is strongly typed
• Can be reused across tables, pages, and codeunits
• Can be extended safely (if designed to allow it)
Enums are used where values are finite, known, and meaningful.
Why Enums Exist in Business Central
Earlier versions of Business Central used the Option data type, which had several problems:
• Values were position-based
• Extensions could not safely add new values
• Changes could break existing logic
• Code readability was poor
Enums exist to solve these issues by providing:
• Named values instead of numeric positions
• Upgrade-safe extensibility
• Clear intent in code
• Better long-term maintainability
Enums are now the preferred and recommended approach.
The following example defines an enum representing the status of customer feedback.
Example: Basic Enum Definition
enum 50180 "Feedback Status"
{
Extensible = true;
value(0; Open)
{
Caption = 'Open';
}
value(1; Reviewed)
{
Caption = 'Reviewed';
}
value(2; Closed)
{
Caption = 'Closed';
}
}
This enum:
• Defines a controlled set of states
• Uses readable names
• Is marked extensible for future expansion
Example: Using Enum in Table
//Enums are commonly used as field types in tables.
field(10; Status; Enum "Feedback Status")
{
DataClassification = CustomerContent;
}
This ensures:
• Only valid enum values can be stored • Data remains consistent • Code referencing the field is type-safe
Using an Enum in AL Code
Enums improve code readability and safety.
if Feedback.Status = Feedback.Status::Open thenMessage('Feedback is still open.');
This is far clearer and safer than numeric or text-based comparisons.
When to Use Enums
Enums should be used when:
• Values are limited and predefined
• Each value has clear business meaning
• The value affects logic or behavior
• You want readable, self-documenting code
Typical examples include:
• Status fields
• Types or categories
• Processing states
• Workflow stages
What Is an Enum Extension?
An enum extension allows you to add new values to an existing enum without modifying the original enum object. This is critical for:
• Extending standard enums
• Adding customer-specific values
• Preserving upgrade safety
Enum extensions follow the same philosophy as table and page extensions.
The following example extends the previously defined enum.
Enum Extension Example
enumextension 50181 "Feedback Status Extension" extends "Feedback Status"
{
value(10; Escalated)
{
Caption = 'Escalated';
}
}
This extension:
• Adds a new enum value
• Does not affect existing values
• Survives upgrades safely
Using Extended Enum Values in Code
Once extended, the new values behave like native enum values.
if Feedback.Status = Feedback.Status::Escalated thenMessage('Feedback requires immediate attention.');
No special handling is required.
Extensible vs Non-Extensible Enums
Not all enums should be extensible. It is the property of this object which prevent Enum to be extensible or not.
• Extensible = true
o Designed for customization
o Common in framework or standard enums
• Extensible = false
o Closed set of values
o Logic depends on complete control
Choosing extensibility is a design decision, not a technical default.
Enum vs Option (Important Concept)
Enums:
• Are named and typed
• Support extensions
• Are upgrade-safe
• Improve readability
Options:
• Are legacy
• Are position-based
• Should be avoided in new development
Enums should always be preferred.
Common Beginner Mistakes With Enums
Developers often:
• Use enums where free-text is required
• Forget to mark enums extensible
• Hardcode enum values instead of using names
• Change enum value IDs after release
Enum values should be treated as stable contracts.
Using Extended Enum Values in Code
Enums in AL provide a clean, readable, and upgrade-safe way to represent business states and controlled values. Enum Extensions allow these values to be expanded without breaking standard logic or upgrades.
A well-designed enum:
• Models business meaning clearly
• Uses stable value IDs
• Is extensible when appropriate
• Improves code clarity and safety
Understanding enums and enum extensions completes the business-state modeling layer of AL development.
Practical check: Model a customer follow-up status as an enum
Create New, Contacted, and Closed values for a follow-up record. Give each value a stable numeric ID and a user-facing caption.
Steps and evidence to inspect
- Define the enum and decide deliberately whether Extensible is true.
- Use it as the table field's data type and display it on a list page.
- Create one record per state, filter the list, and verify stored values survive a caption change.
Expected result
Users choose only allowed states, filters are predictable, and code compares named values instead of unexplained integers or text.
If the result is different
Duplicate IDs, missing values, or incompatible assignments fail at compile time. When upgrading, never recycle a shipped value ID for a different meaning.
Version and implementation boundary
Removing or renumbering published enum values can break stored data and dependent apps. Use obsolete-state planning for lifecycle changes.
Authoritative reference: Microsoft Learn — Extensible enums. The scenario and interpretation above are original to ScrutnLearn.