Mandatory Fields in AL

What’s the story with those red asterisks? In this video, I take a closer look at how the mandatory fields work:

https://youtu.be/u0tpth1DNew

In this video, Erik explores the concept of mandatory fields in Business Central — those fields marked with a red asterisk that appear to require input but don’t always enforce it. He walks through the behavior of the ShowMandatory property, demonstrates its limitations, and explores several approaches to truly enforcing field requirements in AL code.

The Illusion of Mandatory Fields

In Business Central, certain fields display a red asterisk indicating that “the value for this field is required.” However, as Erik demonstrates, these indicators are more like guidelines than rules. You can create a customer with a blank tax area code, leave mandatory-looking fields empty on purchase orders, and even release and post documents with red asterisks still visible.

To quote a certain pirate movie: “These are not so much rules as they are guidelines.”

The red asterisks are telling you that at some point a field might be needed, so you might as well fill it out — but Business Central won’t necessarily stop you if you don’t.

How ShowMandatory Works in AL

The property that controls the red asterisk is ShowMandatory. At its simplest, you can set it to true on any field:

modify("Address 2")
{
    ShowMandatory = true;
}

This displays the red asterisk when the field is empty and hides it when a value is entered. But there’s no logic behind it — no validation, no check. The user can simply ignore it and move on.

The BlankZero Gotcha with Numeric Fields

When applying ShowMandatory to numeric fields like “Credit Limit (LCY)”, you might expect the asterisk to appear when the value is zero. However, zero is not considered “blank” for numeric fields. The asterisk won’t appear because the field technically has a value.

To make it work as expected, you need to combine it with BlankZero = true:

modify("Credit Limit (LCY)")
{
    ShowMandatory = true;
    BlankZero = true;
}

Now the field displays as empty when the value is zero, and the red asterisk appears accordingly.

Using Expressions for Conditional Mandatory Fields

ShowMandatory accepts an expression, so you can conditionally show the asterisk based on other field values. For example, only showing the credit limit as mandatory when the customer is not blocked:

modify("Credit Limit (LCY)")
{
    ShowMandatory = Rec.Blocked = Rec.Blocked::" ";
    BlankZero = true;
}

When the “Blocked” field is blank (meaning the customer is active), the red asterisk appears on the credit limit. Change “Blocked” to “All” or another value, and the asterisk disappears.

Attempting to Truly Enforce Mandatory Fields

Erik then explores several approaches to actually enforce a mandatory credit limit — and discovers why each approach has complications.

Approach 1: OnInsert Trigger on the Table

The first attempt is to use an OnInsert trigger on the Customer table to block creation of customers without a credit limit. The problem? Business Central creates the customer record before the user has a chance to type anything in. The customer template system calls insert as part of page initialization, so the error fires immediately — before the user can enter a credit limit.

Approach 2: OnModify Trigger on the Table

Same problem. The template application process triggers a modify as part of setting up the new customer, so the error fires during the template workflow, not when the user is actually editing the record.

Approach 3: OnModifyRecord on the Page

Moving the check to the page’s OnModifyRecord trigger has the same issue. The call stack reveals that the page’s OnAfterGetCurrRecord code runs with a NewMode variable set to true, the template is applied, and CurrPage.Update triggers a modify — all instantaneously, before the user has any control.

trigger OnModifyRecord(): Boolean
begin
    if Rec."Credit Limit (LCY)" = 0 then
        error('You cannot created a customer without a credit limit!');
    exit(true);
end;

Since Business Central auto-saves and there’s no explicit “click to save” action, enforcing mandatory fields at the record level during creation is fundamentally challenging.

The Practical Solution: Validate at the Point of Use

The approach that actually works is to enforce the requirement when the data is used, not when it’s entered. Erik demonstrates this by adding validation on the Sales Header’s “Sell-to Customer No.” field:

tableextension 50133 "Sales Header" extends "Sales Header"
{
    fields
    {
        modify("Sell-to Customer No.")
        {
            trigger OnAfterValidate()
            var
                Customer: Record Customer;
            begin
                Customer.Get(Rec."Sell-to Customer No.");
                if Customer."Credit Limit (LCY)" = 0 then
                    error('You cannot use a customer without a credit limit!');
            end;
        }
    }
}

Now, when a user tries to create a sales order for a customer that has no credit limit, they get an error: “You cannot use a customer without a credit limit!” This is essentially how Microsoft handles it throughout the base application — validation happens at the point of use rather than at the point of entry.

The Complete Source Code

Here’s the full extension file showing both the Customer Card page extension and the Sales Header table extension:

pageextension 50144 "Customer Card" extends "Customer Card"
{
    layout
    {
        modify("Credit Limit (LCY)")
        {
            ShowMandatory = Rec.Blocked = Rec.Blocked::" ";
            BlankZero = true;
        }
    }
    trigger OnModifyRecord(): Boolean
    begin
        if Rec."Credit Limit (LCY)" = 0 then
            error('You cannot created a customer without a credit limit!');
        exit(true);
    end;
}

tableextension 50133 "Sales Header" extends "Sales Header"
{
    fields
    {
        modify("Sell-to Customer No.")
        {
            trigger OnAfterValidate()
            var
                Customer: Record Customer;
            begin
                Customer.Get(Rec."Sell-to Customer No.");
                if Customer."Credit Limit (LCY)" = 0 then
                    error('You cannot use a customer without a credit limit!');
            end;
        }
    }
}

Other Strategies Worth Considering

  • Approval workflows: Use the built-in approval functionality to ensure records are reviewed and complete before they can be used.
  • Release management events: Validate fields during the document release process. The release management codeunits have events you can subscribe to for enforcing field requirements on sales and purchase orders.
  • Dependent field validation: When a user fills out a field that typically requires another field to be populated, check at that point and prevent the action until prerequisites are met.

Summary

Mandatory fields in Business Central are surprisingly complex — a topic that warranted nearly 25 minutes of exploration. The key takeaways are:

  1. ShowMandatory is purely a UI indicator — it shows a red asterisk but enforces nothing.
  2. For numeric fields, combine ShowMandatory with BlankZero = true to get the expected behavior.
  3. ShowMandatory supports expressions for conditional display.
  4. Enforcing mandatory fields at record creation time is extremely difficult because Business Central’s auto-save and template system creates and modifies records before the user has control.
  5. The practical approach is to validate at the point of use — when a customer is selected on an order, when a document is released, or when a process requires the data.
Picture of hougaard

hougaard