The Danger of EnumExtensions

In this video I discuss the potential dangers and pitfalls when using the EnumExtensions in Business Central.

https://youtu.be/047ASfI6QW4

In this video, Erik explores the potential dangers and challenges that come with using enum extensions in AL for Microsoft Dynamics 365 Business Central. While enum extensions are a powerful feature that allows developers to extend base application enums without modifying the original code, the reality is that the existing codebase may not be fully prepared to handle new enum values gracefully.

What Are Enum Extensions?

Enum extensions are a relatively new capability in Business Central’s AL language. They allow developers to add new values to existing enums defined in the base application or other extensions — all without modifying the original object. This is a huge step forward from the old days of Dynamics NAV, where adding a new option to a field like the Sales Line Type required direct modification of base objects.

Here’s a simple example of an enum extension that adds a new value to the Sales Line Type enum:

enumextension 50123 "My Sales Line Type" extends "Sales Line Type"
{
    value(6; Thingie)
    {
        Caption = 'My Thingie?';
    }
}

This is clean, straightforward, and — at first glance — exactly what you’d want. Customers frequently ask for custom line types on sales orders to handle subtotals, special transaction types, or other business-specific needs. With enum extensions, you can now do this without touching the base app. That’s awesome.

The Problem: The Code Base Isn’t Ready

The challenge arises when you look at how the Sales Line Type field is actually used throughout the base application. Erik used Prism (a popular AL code analysis tool) to investigate, and the results are eye-opening.

1,250 References in the Base App

On Business Central version 17.4, the Type field from the Sales Line table is referenced 1,250 times across the base application. That’s 1,250 places where logic depends on the value of this field — and most of that logic was written with only the original enum values in mind (blank, G/L Account, Item, Resource, Fixed Asset, Charge).

Case Statements Without Else or Events

Erik filtered the results to find 22 places where case statements are used on the line type. Many of these case statements handle each known type explicitly but have no else clause and no integration event that would allow an extension developer to inject logic for a new type.

For example, logic around deferral codes checks for G/L Account, Item, and Resource — but if your new enum value also needs deferral code handling, there’s simply no place to hook in. The same pattern appears in intercompany partner logic, unit of measure validation, and many other areas.

Some of these case statements do include events at the end, which means you could subscribe and handle your custom type. But this is the exception, not the rule.

“Different From” Logic Is Dangerous

Beyond case statements, there are many places in the code that use negative/exclusive logic — checking if the type is different from a specific value. For example:

  • Reservation entries: “If type is different from Item, then clear the item number” — probably fine for your custom type, but maybe not.
  • Get Default Bin: “If type is not Item, then exit” — too bad if your custom type also needs bin logic.
  • Tax line calculation: “Calculate on anything that’s not a Comment” — your new type will suddenly be included in tax calculations, which may not be correct.
  • Page property expressions: Fields are enabled or disabled based on specific type values. Your new type won’t be accounted for in these expressions.

This “different from” pattern is particularly dangerous because adding a new enum value silently changes the behavior of these conditions. Your new type gets swept into logic paths that were never designed for it.

The Ripple Effect Beyond the Base App

The danger doesn’t stop at the base application. If you install other apps from AppSource that also reference the Sales Line Type field, those apps may break or behave unexpectedly when they encounter your custom enum value. A third-party app that uses a case statement without an else clause — or uses “different from” logic — could crash or produce incorrect results.

Best Practices for Developers

Erik shared an important practice he’s adopting in his own apps: converting all exclusive (“different from”) logic to inclusive logic. Instead of writing:

// Dangerous: will include unknown future enum values
if Type <> Type::Item then
    exit;

The safer approach is to explicitly list the types you want to act on:

// Safer: only includes the types you explicitly handle
if Type in [Type::Item, Type::"G/L Account", Type::Resource, Type::"Fixed Asset", Type::"Charge (Item)"] then
    // do something

This way, if someone else adds an enum extension to a field your app uses, your logic won’t accidentally include that unknown type.

Conclusion

Enum extensions are a fantastic feature in Business Central’s AL language — they represent a significant improvement over the old approach of modifying base objects. However, they come with a significant caveat: the existing code base is not fully prepared for new enum values. When extending an enum like Sales Line Type, you’re taking on the responsibility of ensuring your new value is handled correctly across potentially hundreds of code paths — many of which currently offer no events or extension points to hook into.

Before adding an enum extension, especially to a widely-used field, take the time to analyze how that field is used throughout the base app and any installed extensions. Tools like Prism can help you understand the scope of the impact. And in your own code, favor inclusive logic over exclusive logic to protect against enum extensions added by others. The feature is powerful, but it demands careful, thorough consideration.

Picture of hougaard

hougaard