It’s time to Enumify your Options

In this video, I demonstrate how you can “upgrade” your Option fields to Enums in Microsoft Dynamics 365 Business Central. I show how to can get rid of some of the bad patterns we have accepted with option fields.

https://youtu.be/s-bccwTRKuM

In this video, Erik demonstrates how to convert Option fields to Enum types in AL for Business Central. He walks through a practical example using a “Rainbow” app, showing the conversion process, its benefits, the seamless deployment experience, and when you might still want to use Options.

The Problem with Option Fields

Erik starts by showing a Business Central app called “The Rainbow” — a simple app that tracks the colors of the rainbow. There’s an immediate problem: the original developer only included six colors (Red through Indigo) and forgot Violet, the seventh color of the rainbow.

Because the Color field is defined as an Option type, there’s no way for someone to create an extension that adds the missing value. This is one of the key limitations that Enums solve — they are extensible, while Options are not.

The Headaches of Passing Option Values

Beyond extensibility, Erik demonstrates the practical pain points of working with Option fields in code. Consider an Add procedure that accepts a color parameter. With Options, you have to repeat the option members every time you declare a parameter or variable of that type:

If you define a procedure parameter as an Option with its own member list, you now have the option values defined in multiple places — on the table field, on the procedure parameter, and potentially on any local variable that needs to reference them. Each repetition is an opportunity for error.

Even worse, if you accidentally reorder the option members in one of these declarations, the names become misaligned with their underlying integer values. For example, if you swap “Red” and “Orange” in the parameter definition, then passing Orange would actually resolve to a different integer than expected, silently resulting in the wrong color being stored. As Erik puts it: “That’s like an impossible bug to find.”

In practice, most developers end up just passing raw integers — 1 for Orange, 2 for Yellow — which is confusing and error-prone.

Converting to Enum

The conversion process is straightforward. First, create the Enum object:

enum 54800 RainbowColors
{
    // Red,Orange,Yellow,Green,Blue,Indigo,Violet
    value(0; Red) { }
    value(1; Orange) { }
    value(2; Yellow) { }
    value(3; Green) { }
    value(4; Blue) { }
    value(5; Indigo) { }
    value(6; Violet) { }
}

Note that the Enum includes Violet — the missing seventh color — which can now be added directly. If you wanted this to be added by a third party instead, you could make the enum extensible and use an enumextension object.

Then, update the table field to reference the Enum instead of using the Option type:

table 54800 "Rainbow Component"
{
    fields
    {
        field(1; Layer; Integer)
        {
            Caption = 'Layer';
        }
        field(2; Size; Decimal)
        {
            Caption = 'Size';
        }
        // field(3; Color; Option)
        // {
        //     Caption = 'Color';
        //     OptionMembers = Red,Orange,Yellow,Green,Blue,Indigo;
        // }
        field(3; Color; Enum RainbowColors)
        {
            Caption = 'Color';
        }
    }
    procedure Add(_Layer : Integer; _Size : Decimal; _Color : Enum RainbowColors)
    begin
        Rec.init();
        Rec.Layer := _Layer;
        Rec.Size := _Size;
        Rec.Color := _Color;
    end;

    procedure Test() : List of [Text]
   begin
        Add(10,1000,RainbowColors::Indigo);
    end;
}

No Schema Update Required

One critically important point Erik emphasizes: this conversion does not require a schema update. Behind the scenes, both Option and Enum fields are stored as integers in the database. The change from Option to Enum is a logical update on the application side, not a physical database change.

This means:

  • No forceSchemaUpdate setting is needed in launch.json
  • The deployment is fully upgradable — it works in the cloud
  • The conversion is even reversible — you can switch back to Option and the data remains intact (though any values beyond the original option range will appear blank)

From the user’s perspective, the dropdown looks and behaves exactly the same way. The only visible difference is that Violet is now available as a selection.

The Benefits of Enum in Code

With the Enum in place, the Add procedure’s parameter is now strongly typed as Enum RainbowColors. This means you can pass enum constants directly:

Add(10, 1000, RainbowColors::Indigo);

There’s no need to declare a separate variable, no need to repeat option member lists, and no risk of integer misalignment. The enum is defined once and referenced everywhere by name. You can also use a variable if needed:

var
    MyColor: Enum RainbowColors;
begin
    MyColor := RainbowColors::Blue;
    Add(10, 1000, MyColor);
end;

Both the Variable::Value syntax and the EnumName::Value syntax work, giving you flexibility in how you write your code.

The Page Remains Unchanged

The page definition doesn’t need any modifications at all. It simply references Rec.Color, and the framework handles the rest:

page 54800 "The Rainbow"
{
    Caption = 'Rainbow';
    UsageCategory = Administration;
    ApplicationArea = all;
    SourceTable = "Rainbow Component";
    PageType = List;
    layout
    {
        area(Content)
        {
            repeater(rep)
            {
                field(Layer; Rec.Layer)
                {
                    ApplicationArea = all;
                }
                field(Size; Rec.Size)
                {
                    ApplicationArea = all;
                }
                field(Color; Rec.Color)
                {
                    ApplicationArea = all;
                }
            }
        }
    }
}

When Should You Still Use Options?

Erik acknowledges that Options still have a place. He sees them as a “quick and dirty enum” — best used when the scope is limited to a local variable inside a single procedure. For example:

procedure DoSomething()
var
    Operation: Option Insert,Delete,Modify;
begin
    case Operation of
        Operation::Delete:
            // do something
            ;
        Operation::Insert:
            // do something else
            ;
    end;
end;

In this scenario, the option is purely a control variable within a procedure. It will never be extended, never stored in the database, and never passed across boundaries. Creating a full Enum object for this would be overkill. Options serve as “enum light” or “enum local” — fast to type and requiring no additional objects.

But for anything that touches table fields, procedure parameters, or needs to be extensible, Enum is the way to go.

Summary

Converting Option fields to Enums in AL is straightforward, safe, and reversible. The key takeaways are:

  • No schema update required — both types store integers in the database
  • Enums are extensible — partners and customers can add values via enumextension
  • Strongly typed parameters — no more repeating option member lists or passing raw integers
  • Users see no difference — the UI experience is identical
  • Options still have a role — as lightweight, procedure-scoped control variables

It’s time to “enumify” your Option fields. As Erik says — that’s a word now.

Picture of hougaard

hougaard