We are at an inflection point

I am just back from Directions EMEA 2025 where I have spoken with a number of people who show the way forward.

Maybe the inflection point was there before, but AI has definitely made it more obvious.

Artificial Intelligence is the asteroid hurtling down and hitting our ecosystem.

Business Central is fundamentally different from Dynamics NAV

It is an error not to make enough sense of urgency.

This is not just about upgrading from Dynamics NAV to BC. Business Central development is fundamentally different from Dynamics NAV development, and this difference is accelerating.

The upgrade cycle has changed forever

In Dynamics NAV, you could upgrade every five or ten years. You had time. You could write code that worked, even if it didn’t follow best practices. The upgrade cycle was slow enough that technical debt could accumulate without immediate consequences.

Business Central changes the rules completely:

• Monthly updates: Your code is updated every month, whether you like it or not
• Breaking changes: With two major releases per year, breaking changes arrive on a regular basis

The problem isn’t new—it’s just more urgent

The truth is, Dynamics NAV had programming guidelines. Microsoft provided them. But many developers created their own patterns, and it worked because upgrades were rare.

That approach is much harder to sustain now.

When you’re facing monthly updates and breaking changes, code that doesn’t follow modern practices becomes a challenge. It can break, cost more to fix, and frustrate customers. And it may put you at a competitive disadvantage.

The customer perspective

Customers are often unaware of the technical debt hidden in their codebase. They don’t know to ask for:

• Code that follows Microsoft’s guidelines
• Test coverage
• Modern architecture patterns
• Regular code reviews

They trust that “senior developers with a lot of experience” are delivering quality code. But experience without modern practices can sometimes lead to legacy code.

The AI acceleration

The world is moving fast. AI tools are making it possible to build better solutions faster. Competitors who adopt modern practices and leverage AI will outcompete those who don’t.

If you’re still writing code the Dynamics NAV way, you may find yourself falling further behind every month.

What modern Business Central development looks like

Modern BC development requires:

• Investment in training: Understanding BC’s architecture, not just porting Dynamics NAV code
• Test-driven development: Writing tests that run in milliseconds (see my articles on Environment Interfaces and Temporary Tables in Tests)
• Code review: Peer review of all changes (see my article on How to make a code review)
• Modern tools: CodeCop, linters, proper settings.json configuration (see my article on Advanced Rulesets)
• Clean architecture: Namespaces, interfaces, proper organization (see my Clean Code Initiative)
• Engineering management: Teams that understand modern software development

The cost of delay

We’ll upgrade to BC during the next two years.

But in two years, everything will have moved so far from where we are now. This year alone has seen rapid changes. Waiting two years means you’ll be even further behind, with even more technical debt to address.

The time to act is now.

How to identify legacy code patterns

After three years as a freelance BC developer, I’ve seen patterns that suggest code may not be ready for BC’s update cycle:

• Objects organized by Object Type instead of functionality
• Global variables everywhere
• No test apps
• Minimal or missing settings.json configuration
• No CodeCop or other linters
• No use of interfaces or namespaces
• Inconsistent naming conventions
• No automatic code cleanup
• No peer code review process

If this describes your codebase, it is urgent time to get started fixing it.

The path forward

I have changed my job title to Modern Business Central Developer.

Prefer to rewrite code using modern patterns rather than patching old code.

If you have adopted a modern development mindset, then show it by changing your job title to Modern Business Central Developer.

And, please, by all means share this article with your network and ask your network to join the movement.

We need to outcompete legacy practices

The best way to make legacy practices obsolete is to outcompete them.

By using the latest technologies and a modern mindset, we will build better solutions faster.

Solutions that are:

• Easy to maintain
• Prepared for evolution
• Easy to extend
• Easy to support
• Ready for BC’s update cycle

Reach out if you need help with the transition.

Finn Pedersen

Modern BC Developer

PS: I realize that some people might be offended by this post. That was not the intention. The purpose of this post is not to offend anyone, but to create enough sense of urgency. The technical reality is that BC’s update cycle requires modern practices. The longer we delay, the more expensive and difficult the transition becomes. I want to help, not criticize.

An app says more than a 1000 words

If you are not a developer, you have to try Lovable.dev!

The reason is that it will expand your view on what is possible.

This is what you will learn from making apps with Lovable.dev.

• How to express an idea
• How to reformulate and clarify your thoughts
• How to communicate your idea to others
• Understand how your first hypotheses had flaws and can be improved

To help you get started, there are some examples below.

Lovable.dev

Use my referral link to get free credits when you sign up.

https://lovable.dev/invite/8e75e0e5-5de0-4a7f-860d-3f192c0714f1

And don’t forget to publish your app. It will give me 10 credits to build more fun games.

Team Building

I recommend vibe coding for team building.

People who don’t know how to code often have fewer ideas for what is possible to make. No longer.

After a few attempts you will rapidly get the hang of it.

The hottest new programming language is English

I will be giving a talk on Vibe Coding at the Directions EMEA 2025 conference, 4-6 November 2025 in Poznan, Poland.

More information about the conference at www.directionsforpartners.com/emea2025 and my session.

Snake Game

Build a Snake game for my phone as a web app

Extra instructions

The game must not end. When the snake reaches the edge it should just continue on the other side. Start with a length of 3. Add buttons on the right hand side. The swiping up and right did not work as expected.

Make the head of the snake blue.

mobile-snake-play.lovable.app

Converting French to Braille

Make a small web app that converts a text as I type it to braille. I want the braille to be above the text input field so I can see it as I type on my phone. The braille should not be abbreviated. I expect to write in French. ...

braille-ahead-typer.lovable.app

2048 Game

Make a 2048 game that runs on my phone.

Extra instruction

Swiping works left, right, and up. Swipe down refreshes the page.

twenty-forty-eight-slide.lovable.app

Whether we are just coding with AI or entirely Vibe Coding, we face the same challenges.

The term Vibe Coding went viral in February 2025 and now everyone is talking about it or trying it out.

I have submitted a talk, Vibe coding. The hottest new programming language is English on this subject, to Directions EMEA 2025

There is actually a lot we can learn from vibe coding:

• How do we communicate our needs to the AI?
• Is that similar to how we communicate with a developer?
• What is easy and what is difficult in programming?
• Are some programming languages more suited for development with AI than others?
• Do you need to be a developer to do Vibe Coding?
• How much coding do you actually need to know to succeed with vibe coding?
• Is vibe coding just for fun or can I use it in my work?

What is Vibe Coding?

Computer scientist Andrej Karpathy, a co-founder of OpenAI and former AI leader at Tesla, introduced the term vibe coding in February 2025. The concept refers to a coding approach that relies on LLMs, allowing programmers to generate working code by providing natural language descriptions rather than manually writing it.

Source Wikipedia Vibe Coding

The snake game

Here is an idea for a prompt:

Make the snake game in Elm as we knew it from the old nokia phones.

• Download and install Cursor
• Setup your development environment
• Write your prompt

40 minutes

Within 40 minutes, I had a running game on my computer. I was super optimistic. Take into account that I was also playing, I mean testing, the game during that time.

Then …

Several days later

The app was only running on my laptop and I wanted it to work on my phone. This is where the troubles started. I refused to touch the code. I had to prompt my way to the result. However, at one point, I had to study the code and specifically ask it to change some of the CSS.

I also had to rollback the code completely a couple of times.

Try it

Warning: It is quite addictive.

Project on GitHub

Elm Snake Game on GitHub

The main branch is the first desktop version and the mobile-first branch is the mobile-first version. Feel free to star the project and clone it.

You can follow my dialog with the AI in the cursor_create_a_hello_world_app_in_elm.md file.

It is the entire dialog to get to the first version. You don’t want to see the second. It is too long.

The readme.md is also almost entirely generated with a few prompts stating the sections.

Cursor.com

I used Cursor.com, the AI Code Editor, to realize the project.

I did not write a single line of code, so I did not care about setting anything up.

Programming Languages

Are all programming languages born equal for AI peer programming and Vibe Coding? They are not. Actually, this will challenge our common worldview on programming languages.

What if another language will challenge C# or TypeScript simply because the AI works better with it? Could a small and rather unknown language like Elm suddenly spring into popularity because it works much better with AI?

Some really interesting articles have started to appear.

• Elm as target language for vibe coding by Wil Chung
• The AI Symbiote: Why Deterministic Languages Are the Future of Coding by Le Jon

This is the reason why I chose Elm for my first vibe programming project.

Elm

A delightful language for reliable web applications.

elm-lang.org

Elm is a pure functional language for building interactive web applications. The model-update-view architecture has all state management handled in a single model. The strong static type system guarantees no runtime errors. And I just love the helpful compiler messages and easy-to-read code.

If it compiles, it works.

As it turns out, the AI in Cursor also likes the helpful error messages from Elm.

Try Elm

There are a couple of ways to try out Elm. Here are a few.

• elm-editor.com
• ellie-app.com

Other languages and AL

Since the amount of open source code for a given language is also important for training the LLM, the most popular languages like JavaScript, TypeScript, and Python have an advantage.

A purpose-specific language might also have some advantages. AL is purpose-specific.

AL and AI

Age and how much a language changes plays a role. AL is old and has evolved a lot. There is no tradition for open source projects on GitHub, best practices were not followed, and the language has evolved a lot. For example, we no longer write Find('-') we write FindFirst(). So the LLM has to discard what was good in the past and now considered bad.

Where Elm has been stable for the past five years.

AI assistance helping the AI

When I had trouble with the Mobile-First UI of the Game, I found that the Inspect function in Chrome has an AI assistance. I asked how to fix the issue and passed the advice directly to the AI developer in Cursor. Nice!

Conclusion

Are you in a team? Do you work with developers, project managers, product owners, users, or managers?

Here is what you should do: Make a team-building event and vibe code something together.

You will learn much more than you could possibly imagine.

Warning: You will have so much fun that you will have a hard time getting back to work.

Have fun and learn

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a condition for writing good tests, but it does not guarantee code coverage by tests.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Temporary Tables will satisfy the need for speed and isolation from the database.

Avoid Touching the Database in Tests

We have looked at Environment Interfaces and how they save us time and improve speed, but there is one more thing to avoid during tests: touching the database. Here, we have to think differently—we are not going to develop an interface toward the database, and we don’t have to.

If we want to run hundreds of tests in seconds, we have to change the way we write functions. While the Clean Code Initiative told you to stick to the standard patterns, we are now going to challenge this a little bit in some cases.

Pure Functions

First of all, we want to have pure functions—that is, functions with no side effects. Touching the database is a side effect.

This has important consequences for where we place database operations like Record.Get(), Record.Modify(), Record.Insert(), and Record.FindSet() in our code. In this project, they are now all at the top level.

Passing Records by Reference

To achieve fast, isolated tests, we use temporary tables, which run entirely in memory. When a function operates on a temporary record, you must pass that record by reference using the var keyword. This ensures that any changes made to the record inside the function are retained and that the function works with the same in-memory instance. In the example below, both EncodePhoneNumber and the helper method GetPhoneNumber take Setup as a var parameter, allowing the test to run against a temporary, in-memory version of the table instead of querying or modifying the actual database.

internal procedure EncodePhoneNumber(var Setup: Record Setup; ObjectKey: Text; PhoneNumber: Text; var Object: JsonObject)
var
    PhoneNumberAsText: Text;
begin
    PhoneNumberAsText := this.GetPhoneNumber(Setup, PhoneNumber);
    Object.Add(ObjectKey, PhoneNumberAsText);
end;

local procedure GetPhoneNumber(var Setup: Record Setup; PhoneNumber: Text): Text
begin
    if Setup."Application State" <> Enum::"Application State"::Production then
        exit(Setup."Phone Number Test");
    exit(PhoneNumber);
end;

Previously, I would simply have made a Setup.Get() at the bottom level where I needed the information. This new approach forces me to have a well-organized architecture of my code.

Testing in the context of a production environment

[Test]
internal procedure TestEncodePhoneNumberProduction()
var
    TempSetup: Record Setup temporary;
    Decoders: Codeunit Decoders;
    Encoders: Codeunit Encoders;
    Object: JsonObject;
    CalculatedPhoneNumber: Text;
    CustomerPhoneNumber: Text;
begin
    // [SCENARIO #015] Testing encoding a phone number to a JSON object in a production environment.
    // [GIVEN] A phone number
    // [WHEN] encoded to JSON object
    // [THEN] we should get the same phone number

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup."Application State" := Enum::"Application State"::Production;
    CustomerPhoneNumber := '1234567890';
    Encoders.EncodePhoneNumber(TempSetup, 'Test', CustomerPhoneNumber, Object);
    Decoders.DecodeText(Object, 'Test', CalculatedPhoneNumber);
    this.Assert.AreEqual(CustomerPhoneNumber, CalculatedPhoneNumber, 'In the production environment we expected to encode the customer phone number directly.');
end;

Testing in the context of a test environment

[Test]
internal procedure TestEncodePhoneNumberTest()
var
    TempSetup: Record Setup temporary;
    Decoders: Codeunit Decoders;
    Encoders: Codeunit Encoders;
    Object: JsonObject;
    CalculatedPhoneNumber: Text;
    CustomerPhoneNumber: Text;
begin
    // [SCENARIO #016] Testing encoding a phone number to a JSON object in a test environment.
    // [GIVEN] A phone number
    // [WHEN] encoded to JSON object
    // [THEN] we should get the test phone number

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup."Application State" := Enum::"Application State"::Test;
    TempSetup."Phone Number Test" := '1234567890';
    CustomerPhoneNumber := '0987654321';
    Encoders.EncodePhoneNumber(TempSetup, 'Test', CustomerPhoneNumber, Object);
    Decoders.DecodeText(Object, 'Test', CalculatedPhoneNumber);
    this.Assert.AreEqual(TempSetup."Phone Number Test", CalculatedPhoneNumber, 'In the test environment we expected to ignore the customer phone number and encode the test phone number from the setup.');
end;

Running the actual code

In the actual code, the Setup.Get() is executed once at the highest level. This also gives me a better understanding of all dependencies on the setup table in the code. That is, we do not retrieve the setup table in multiple places throughout the code. We get it once and pass it around by reference.

Conclusion

This new design has several advantages:

• Better performance: Fewer reads to the database.
• Fast, isolated tests: Run tests without database access using just temporary tables.
• Improved code overview: Dependencies are clear and easy to manage.

Overall, this approach leads to a better design, even though it is not entirely how we used to write code. It is essential for writing modern, maintainable, and high-performance AL test code.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a condition for writing good tests, but it does not guarantee code coverage by tests.

Introduction

I will introduce three different contexts of Environment Interfaces. Discussed in parts 1, 2, and 3.

1. Interface against the system environment (Sandbox or Production)
2. Interface against an external API
3. Interface against the standard application

Environment interfaces usually have a single implementation within the application but can have several implementations in the test application. There is no corresponding Enum implementing the Interface.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Environment Interfaces are the solution to this apparent paradox.

Interface against Standard Business Central

In parts 1 and 2, we have seen how interfaces enable us to reach code we could otherwise never reach in tests.

However, there are other important constraints: we cannot spend too much time writing tests, and we only want to test our own code.

This is why we sometimes have to develop an interface against the standard application.

Finance interface

In this case, we are handling payments and refunds.

namespace MicrosoftPartner.AppName.Finance;

using Microsoft.Finance.GeneralLedger.Journal;
using Microsoft.Sales.History;

interface IFinance
{
    procedure CreatePaymentLine(
        var PaymentRequest: Record "Payment Request";
        var Setup: Record Setup;
        var GenJournalBatch: Record "Gen. Journal Batch";
        var GenJournalLine: Record "Gen. Journal Line";
        var GenJournalTemplate: Record "Gen. Journal Template";
        var PostedSalesInvoiceHeader: Record "Sales Invoice Header")

    procedure CreateRefundLine(
        var RefundRequest: Record "Refund Request";
        var Setup: Record Setup;
        var GenJournalBatch: Record "Gen. Journal Batch";
        var GenJournalLine: Record "Gen. Journal Line";
        var GenJournalTemplate: Record "Gen. Journal Template";
        var SalesCrMemoHeader: Record "Sales Cr.Memo Header")
}

Implementing the App version of the interface

The implementation is as you would expect. It is the code you would normally have written. We are inserting a GenJournalLine and we are using .Validate to ensure that the line is created with all the logic on the fields

codeunit 50019 "App Finance" implements IFinance
{
    procedure CreatePaymentLine(...)
    begin
        GenJournalLine.Init();
        GenJournalLine.Validate("Journal Template Name", GenJournalTemplate.Name);
        GenJournalLine.Validate("Journal Batch Name", GenJournalBatch.Name);
        GenJournalLine.Validate("Document Type", Enum::"Gen. Journal Document Type"::Payment);
        GenJournalLine.Validate("Document No.", PaymentRequest."Request Reference");
        
        ...
        GenJournalLine.Insert(true);
    end;

    procedure CreateRefundLine(...)
    begin
        GenJournalLine.Init();
        ...
        GenJournalLine.Insert(true);
    end;
}

Implementing the Test App version of the interface

This is where it becomes interesting.

Stub Finance

The stub function simply returns what I have asked it to return. This is how I control which part of my code is touched.

namespace MicrosoftPartner.AppName.Test.Helpers;

using Microsoft.Finance.GeneralLedger.Journal;
using Microsoft.Sales.History;

codeunit 50120 "Stub Finance" implements IFinance
{
    Description = 'Stub Finance';

    var
        SetupVar: Record Setup;
        GenJournalBatchVar: Record "Gen. Journal Batch";
        GenJournalLineVar: Record "Gen. Journal Line";
        GenJournalTemplateVar: Record "Gen. Journal Template";
        PaymentRequestVar: Record "Payment Request";
        RefundRequestVar: Record "Refund Request";
        PostedSalesCrMemoHeaderVar: Record "Sales Cr.Memo Header";
        PostedSalesInvoiceHeaderVar: Record "Sales Invoice Header";

    internal procedure CreatePaymentLine(var PaymentRequest: Record "Payment Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var PostedSalesInvoiceHeader: Record "Sales Invoice Header")
    begin
        PaymentRequest := this.PaymentRequestVar;
        Setup := this.SetupVar;
        GenJournalBatch := this.GenJournalBatchVar;
        GenJournalLine := this.GenJournalLineVar;
        GenJournalTemplate := this.GenJournalTemplateVar;
        PostedSalesInvoiceHeader := this.PostedSalesInvoiceHeaderVar;
    end;

    internal procedure SetupPaymentResponse(var PaymentRequest: Record "Payment Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var PostedSalesInvoiceHeader: Record "Sales Invoice Header")
    begin
        this.PaymentRequestVar := PaymentRequest;
        this.SetupVar := Setup;
        this.GenJournalBatchVar := GenJournalBatch;
        this.GenJournalLineVar := GenJournalLine;
        this.GenJournalTemplateVar := GenJournalTemplate;
        this.PostedSalesInvoiceHeaderVar := PostedSalesInvoiceHeader;
    end;

    internal procedure CreateRefundLine(var RefundRequest: Record "Refund Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var SalesCrMemoHeader: Record "Sales Cr.Memo Header")
    begin
        RefundRequest := this.RefundRequestVar;
        Setup := this.SetupVar;
        GenJournalBatch := this.GenJournalBatchVar;
        GenJournalLine := this.GenJournalLineVar;
        GenJournalTemplate := this.GenJournalTemplateVar;
        SalesCrMemoHeader := this.PostedSalesCrMemoHeaderVar;
    end;

    internal procedure SetupRefundResponse(var RefundRequest: Record "Refund Request"; var Setup: Record Setup; var GenJournalBatch: Record "Gen. Journal Batch"; var GenJournalLine: Record "Gen. Journal Line"; var GenJournalTemplate: Record "Gen. Journal Template"; var SalesCrMemoHeader: Record "Sales Cr.Memo Header")
    begin
        this.RefundRequestVar := RefundRequest;
        this.SetupVar := Setup;
        this.GenJournalBatchVar := GenJournalBatch;
        this.GenJournalLineVar := GenJournalLine;
        this.GenJournalTemplateVar := GenJournalTemplate;
        this.PostedSalesCrMemoHeaderVar := SalesCrMemoHeader;
    end;
}

Conclusion

Running logic in the base application introduces several challenges:

Setting up tests is time-consuming due to dependencies on G/L Accounts, Banks, General Journal Batch, General Journal Template, Number Series, and more — a rabbit hole that can consume significant amounts of time.

It creates a strong dependency on the base app, increasing maintenance overhead.

It is slow, as it writes to the database and rolls back changes, preventing the use of temporary variables.

By using Environment Interfaces, I have avoided these issues. My tests are fast, independent, and focused on my code.

You might say that this is cheating. That I am not really testing the code. And you are right in the sense that I have to understand perfectly what Business Central is returning when it creates the General Journal Line. But I am not testing that Business Central is working; I am testing that my code is working.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

London Style Terminology

When writing tests in Business Central, you may come across different types of test doubles—objects that replace real dependencies in your code. The “London style” (or “mockist”) terminology is widely used in the testing community to describe these patterns. Understanding these terms will help you communicate more clearly about your test design and choose the right approach for your scenario.

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a condition for writing good tests, but it does not guarantee code coverage by tests.

Introduction

I will introduce three different contexts of Environment Interfaces. Discussed in parts 1, 2, and 3.

1. Interface against the system environment (Sandbox or Production)
2. Interface against an external API
3. Interface against the standard application

Environment interfaces usually have a single implementation within the application but can have several implementations in the test application. There is no corresponding Enum implementing the Interface.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Environment Interfaces are the solution to this apparent paradox.

Interface against the external API

Before describing the interface, I need a small helper Enum.

Api Method Enum

There is a standard Enum, but I just want to keep it simple and to what I need.

enum 50005 "Api Method"
{
    value(0; GET)
    {
        Caption = 'GET', Locked = true;
    }
    value(1; POST)
    {
        Caption = 'POST', Locked = true;
    }
}

Api Request Interface

It is a very simple interface with just one function Send. But it is all we need.

interface IApiRequest
{
    procedure Send(RequestMethod: Enum "Api Method"; RequestUrl: Text; Payload: Text; SecretKey: SecretText; var ResponseStatusCode: Integer; var ResponseContent: Text)
}

Implementing the App version of the interface

The implementation of the Send function is quite generic and you can reuse this code. The API accepts a JSON payload, an encrypted key, and it returns a Status Code (200 for OK) and a response payload also in JSON.

codeunit 50011 "App Api Request" implements IApiRequest
{
    internal procedure Send(RequestMethod: Enum "Api Method"; RequestUrl: Text; Payload: Text; SecretKey: SecretText; var ResponseStatusCode: Integer; var ResponseContent: Text)
    var
        ApiTools: Codeunit ApiTools;
        HttpClient: HttpClient;
        HttpContent: HttpContent;
        ContentHeaders: HttpHeaders;
        RequestHeaders: HttpHeaders;
        HttpRequestMessage: HttpRequestMessage;
        HttpResponseMessage: HttpResponseMessage;
        Hash: SecretText;
    begin
        Hash := ApiTools.CreateHash(Payload, SecretKey);

        HttpRequestMessage.Method := Format(RequestMethod);
        HttpRequestMessage.SetRequestUri(RequestUrl);
        HttpRequestMessage.GetHeaders(RequestHeaders);
        RequestHeaders.Clear();
        RequestHeaders.Add('Accept', 'application/json');
        RequestHeaders.Add('Authorization', Hash);

        if RequestMethod = Enum::"Api Method"::POST then begin
            HttpContent.WriteFrom(Payload);
            HttpContent.GetHeaders(ContentHeaders);
            ContentHeaders.Clear();
            ContentHeaders.Add('Content-Type', 'application/json');
            HttpRequestMessage.Content := HttpContent;
        end;

        if HttpClient.Send(HttpRequestMessage, HttpResponseMessage) then begin
            ResponseStatusCode := HttpResponseMessage.HttpStatusCode();
            if ResponseStatusCode = ApiTools.HttpStatusCodeOK() then
                HttpResponseMessage.Content().ReadAs(ResponseContent)
            else
                ApiTools.WebServiceCallFailedError(HttpResponseMessage.HttpStatusCode());
        end else
            ApiTools.ConnectionError();
    end;
}

Implementing the Test App version of the interface

This is where it becomes interesting.

Stub Api Request

The stub function simply returns what I have asked it to return. This is how I control which part of my code is touched.

codeunit 50113 "Stub Api Request" implements IApiRequest
{
    Description = 'Stub Api Request';

    var
        ResponseStatusCodeVar: Integer;
        ResponseContentVar: Text;

    internal procedure Send(RequestMethod: Enum "Api Method"; RequestUrl: Text; Payload: Text; SecretKey: SecretText; var ResponseStatusCode: Integer; var ResponseContent: Text)
    begin
        ResponseStatusCode := this.ResponseStatusCodeVar;
        ResponseContent := this.ResponseContentVar;
    end;

    internal procedure SetupResponse(ResponseStatusCode: Integer; ResponseContent: Text)
    begin
        this.ResponseStatusCodeVar := ResponseStatusCode;
        this.ResponseContentVar := ResponseContent;
    end;
}

Using it

For each endpoint the API exposes, I have written a Codeunit with these functions

codeunit 50007 "Api Operation <Endpointname>"
{
    Description = 'Implementation of the Api Operation <Endpointname>';

    internal procedure OperationType(): Text
    begin
        exit('<Endpointname>');
    end;

    internal procedure RequestMethod(): Enum "Api Method"
    begin
        exit(Enum::"Api Method"::POST);
    end;

    internal procedure RequestPayload(var EndpointTable: Record "Endpoint Table Name"): Text[2048]
    begin
        exit(<the calculated payload>);
    end;

    internal procedure SendRequest(var Setup: Record Setup"; var EndpointTable: Record "Endpoint Table Name"; ApiRequest: Interface IApiRequest)
    var
        Decoders: Codeunit Decoders;
        ResponseStatusCode: Integer;
        SecretKey: SecretText;
        RequestUrl: Text;
        ResponseContent: Text;
    begin
        RequestUrl := Setup.ApiUrl(this.OperationType());
        SecretKey := Setup.ApiHmac();
        ResponseStatusCode := 0;
        ApiRequest.Send(this.RequestMethod(), RequestUrl, this.RequestPayload(EndpointTable), SecretKey, ResponseStatusCode, ResponseContent);
        Decoders.DecodeEndpointResponse(Setup, ResponseStatusCode, ResponseContent, EndpointTable);
    end;
}

Running the actual code

When I call the SendRequest function, I pass it the implementation.

var
  AppApiRequest: Codeunit "App Api Request";
...

ApiOperationEndpoint.SendRequest(Setup, Rec, AppApiRequest);

Testing in the context of a fake API

Before calling SendRequest, I call the SetupResponse and tell my fake API what to return to me. I know that this sounds strange at first, but trust me. I am not testing if the API works. I am testing how my code reacts to the response from the API. In this way, I can ensure that I am also testing more exotic events and responses.

This is the setup for success:

StubApiRequest.SetupResponse(200, '{"Result":"OK","Reference":"TEST"}');
ApiOperationEndpoint.SendRequest(TempSetup, TempRecord, StubApiRequest);

Failure could look like this:

StubApiRequest.SetupResponse(200, StubApiResponses.NotUniqueErrorResponse());
ApiOperationEndpoint.SendRequest(TempSetup, TempRecord, StubApiRequest);

I still get a valid JSON, but something is wrong. Then I am testing if my decoders are working as they should.

Conclusion

By using stubs and environment interfaces, I can thoroughly test all my decoding logic, failure detection, and error handling — without ever calling the real API during tests.

This approach ensures that every line of my code is exercised and verified, resulting in fast, reliable, and maintainable tests for my Business Central app.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

London Style Terminology

When writing tests in Business Central, you may come across different types of test doubles—objects that replace real dependencies in your code. The “London style” (or “mockist”) terminology is widely used in the testing community to describe these patterns. Understanding these terms will help you communicate more clearly about your test design and choose the right approach for your scenario.

The theme for this series is Super fast tests covering 100% of your code.

This 2025 series of articles is a continuation of the 2024 series called the Clean Code Initiative.

Clean Code is a prerequisite for writing good tests, but it does not guarantee code coverage by tests.

Introduction

I will introduce three different contexts of Environment Interfaces, discussed in parts 1, 2, and 3.

1. Interface against the system environment (Sandbox or Production)
2. Interface against an external API
3. Interface against the standard application

Environment interfaces usually have a single implementation within the application but can have several implementations in the test application. There is no corresponding Enum implementing the Interface.

Scenario

The app we are building communicates with an external API.

We face several key requirements:

• The app can only be in production mode when running in a production environment. If running in a sandbox, it must operate in test mode.
• Our tests must cover all code paths, including those only reachable in production mode.
• Our tests cannot call the actual API, but we still need to verify both the requests we send and how we decode the API responses.
• Tests must be extremely fast, with runtimes measured in milliseconds.
• Writing tests should be quick and cost-effective.
• We want to test only our own code, assuming that dependencies and external systems work as expected. We assume everyone else knows what they are doing

Environment Interfaces are the solution to this apparent paradox.

Interface against the system environment

You can find the code for this article on GitHub.

github.com/finnpedersenfrance/BC-Environment-Interfaces

System Environment Enum

First, we need a new Enum. If you are running BC in the cloud, there are only two options. You are either in a Sandbox or a Production environment.

enum 50004 "System Environment"
{
    value(0; " ")
    {
        Caption = ' ', Locked = true;
    }
    value(1; Sandbox)
    {
        Caption = 'Sandbox';
    }
    value(2; Production)
    {
        Caption = 'Production';
    }
}

Environment Interface

Then we need an interface.

The interface is the recipe for which functions need to be implemented.

interface IEnvironment
{
    /// <summary>
    /// Returns the state of the current system environment. That is either Production, Sandbox or empty.
    /// </summary>
    /// <param></param>
    /// <returns>System Environment</returns>
    procedure SystemEnvironment(): Enum "System Environment"

    /// <summary>
    /// Returns the name of the current company.
    /// </summary>
    /// <param></param>
    /// <returns>Company Name</returns>
    procedure ThisCompanyName(): Text[30]

    /// <summary>
    /// Returns the state of the current company. That is either Production or Evaluation.
    /// </summary>
    /// <param></param>
    /// <returns>False if Production Company. True if Evaluation Company.</returns>
    procedure IsEvaluationCompany(): Boolean
}

Implementing the App version of the interface

The implementation is as you would expect. It is the code you would normally have written.

codeunit 50010 "App Environment" implements IEnvironment
{
    internal procedure SystemEnvironment(): Enum "System Environment"
    var
        EnvironmentInformation: Codeunit System.Environment."Environment Information";
    begin
        if EnvironmentInformation.IsProduction() then
            exit(Enum::"System Environment"::Production);
        if EnvironmentInformation.IsSandbox() then
            exit(Enum::"System Environment"::Sandbox);
        exit(Enum::"System Environment"::" ");
    end;

    internal procedure ThisCompanyName(): Text[30]
    begin
        exit(CopyStr(CompanyName(), 1, 30));
    end;

    internal procedure IsEvaluationCompany(): Boolean
    var
        Company: Record System.Environment.Company;
    begin
        Company.Get(CompanyName());
        exit(Company."Evaluation Company");
    end;
}

This also allows us to replace the booleans with an enum, which is much nicer.

Notice that ThisCompanyName() also solves the CodeCop Warning AA0139 (overflow). CompanyName() returns a Text which causes an overflow warning when you assign it to a Company Name field of type Text[30]. With this interface function, I have solved this everywhere I needed to use CompanyName().

Implementing the Test App version of the interface

This is where it becomes interesting.

Stub Production

I have written a Stub Production implementation of the environment. This allows me to fool my code into believing that it is in production.

codeunit 50102 "Stub Production Environment" implements IEnvironment
{
    Description = 'Stub Production Environment';

    procedure SystemEnvironment(): Enum "System Environment"
    begin
        exit(Enum::"System Environment"::Production);
    end;

    procedure ThisCompanyName(): Text[30]
    begin
        exit('Production Company Name');
    end;

    procedure IsEvaluationCompany(): Boolean
    begin
        exit(false);
    end;
}

Take a minute to look at how elegantly this allows us to test our code as if we were live in a production environment.

Stub Test

And a Stub Test implementation of the environment.

codeunit 50103 "Stub Test Environment" implements IEnvironment
{
    Description = 'Stub Test Environment';

    procedure SystemEnvironment(): Enum "System Environment"
    begin
        exit(Enum::"System Environment"::Sandbox);
    end;

    procedure ThisCompanyName(): Text[30]
    begin
        exit('Test Company Name');
    end;

    procedure IsEvaluationCompany(): Boolean
    begin
        exit(true);
    end;
}

And now we are in an evaluation company in a sandbox.

Using it

It is crucial for my application code to know if the application is Production or in a Test setup. For this, I am using an enum Application State.

enum 50006 "Application State"
{
    Extensible = true;

    value(0; " ")
    {
        Caption = ' ', Locked = true;
    }
    value(1; Test)
    {
        Caption = 'Test';
    }
    value(2; Production)
    {
        Caption = 'Production';
    }
}

I have written a function to calculate the state of the application based on the environment and the setup. The functions are in my Setup table.

internal procedure ValidateApplicationState(Environment: Interface IEnvironment)
begin
    Rec."Application State" := this.ApplicationState(Rec, Environment);
end;

internal procedure ApplicationState(var Setup: Record Setup; Environment: Interface IEnvironment): Enum "Application State"
begin
    case true of
        (Setup.Licensee = Environment.ThisCompanyName()) and
        (Environment.SystemEnvironment() = Enum::"System Environment"::Production) and
        (not Environment.IsEvaluationCompany()):
            exit(Enum::"Application State"::Production);
        (Setup.Licensee = Environment.ThisCompanyName()):
            exit(Enum::"Application State"::Test);
        else
            exit(Enum::"Application State"::" ");
    end;
end;

We are in production mode, only and only if

• the app is in a Production environment and
• it is not an evaluation company, and
• the Licensee matches the name of the current company

We are in a test mode if

• the solution is running in a sandbox or
• the company is an evaluation company
• the Licensee still has to match the name of the current company

An important safety feature

If someone makes a copy of the company, the company name will differ from the Licensee name in our setup, which will automatically disable the solution and prevent anyone from using the solution by mistake.

Now I can call this function in both my tests and production, reaching all the code.

Testing in the context of a test environment

Testing that the application is in test mode in a sandbox.

[Test]
internal procedure TestTestMode()
var
    TempSetup: Record Setup temporary;
    StubTestEnvironment: Codeunit "Stub Test Environment";
begin
    // [SCENARIO #003] Application State in test
    // [GIVEN] a setup with a valid licensee
    // [WHEN] calling ValidateApplicationState
    // [THEN] the application state should be test

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup.Licensee := StubTestEnvironment.ThisCompanyName();
    TempSetup.ValidateApplicationState(StubTestEnvironment);

    this.Assert.AreEqual(Enum::"Application State"::Test, TempSetup."Application State", 'Expected Application State to be Test.');
end;

Testing in the context of a production environment

Testing in our simulated production environment.

[Test]
internal procedure TestProductionMode()
var
    TempSetup: Record Setup temporary;
    StubProductionEnvironment: Codeunit "Stub Production Environment";
begin
    // [SCENARIO #002] Application State in production
    // [GIVEN] a setup with a valid licensee
    // [WHEN] calling ValidateApplicationState
    // [THEN] the application state should be production

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup.Licensee := StubProductionEnvironment.ThisCompanyName();
    TempSetup.ValidateApplicationState(StubProductionEnvironment);

    this.Assert.AreEqual(Enum::"Application State"::Production, TempSetup."Application State", 'Expected Application State to be Production.');
end;

Testing that the solution is disabled if there is no licensee.

[Test]
internal procedure TestNoCompanyName()
var
    TempSetup: Record Setup temporary;
    StubProductionEnvironment: Codeunit "Stub Production Environment";
begin
    // [SCENARIO #001] No company name in disabled environment
    // [GIVEN] a setup with no licensee
    // [WHEN] calling ValidateApplicationState
    // [THEN] the application state should be empty. I.e. disabled.

    this.TestHelper.InitializeSetup(TempSetup);
    TempSetup.Licensee := '';
    TempSetup.ValidateApplicationState(StubProductionEnvironment);

    this.Assert.AreEqual(Enum::"Application State"::" ", TempSetup."Application State", 'Expected Application State to be disabled.');
end;

The code in the App

I am not testing the following code at the highest level. I call the function from the Setup page.

trigger OnModifyRecord(): Boolean
var
    AppEnvironment: Codeunit "App Environment";
begin
    Rec.ValidateApplicationState(AppEnvironment);
end;

Bonus Safety feature

You can implement one more safety feature. Just to be sure that you solution is disabled in the copied company. Subscribe to the OnAfterCopyCompanyOnAction event.

codeunit 50031 "Event Subscribers Copy Company"
{
    Description = 'Event Subscribers for Copy Company. This ensures that the copied company cannot be used by mistake.';

    [EventSubscriber(ObjectType::Page, Page::Companies, OnAfterCopyCompanyOnAction, '', false, false)]
    local procedure OnAfterCopyCompanyOnAction(CompanyName: Text[30])
    var
        Setup: Record Setup;
    begin
        Setup.ChangeCompany(CompanyName);
        if Setup.Get() then begin
            Setup.Licensee := '';
            Setup."Application State" := Enum::"Application State"::" ";
            Setup."Job Scheduler on Standby" := true;
            Setup.Modify(false);
        end;
    end;
}

Conclusion

Bugs are often found in code that was never executed before. Think about it. If I had a bug in the part of my code that would only be reached in production, I would otherwise never find it during tests.

With this design, I am quite confident that my code will act as planned when put in production and my tests cover 100% of my code.

Clean AL Code Initiative

• Part 1: Rulesets in Business Central
• Part 2: Namespaces in AL
• Part 3: VS Code Extensions for AL
• Part 4: Automated Tests in AL
• Part 5: Advanced CodeCop Analyzer and Custom Rulesets
• Part 6: How to make a code review
• Part 7: Preconditions and TryFunctions in AL

Super fast tests covering 100% of your code

• Part 1: Environment Interfaces - Part 1 - System Environment
• Part 2: Environment Interfaces - Part 2 - External API
• Part 3: Environment Interfaces - Part 3 - Standard Application
• Part 4: Temporary Tables in Tests

London Style Terminology

When writing tests in Business Central, you may come across different types of test doubles—objects that replace real dependencies in your code. The “London style” (or “mockist”) terminology is widely used in the testing community to describe these patterns. Understanding these terms will help you communicate more clearly about your test design and choose the right approach for your scenario.

I recently took a small detour from my usual topics to write my first Wikipedia article.

I have been renting out apartments in Denmark for more than 30 years and found myself searching for some information that dated back before 2001.

I wanted to share the information because

• It was hard to find
• It was of general interest for both parties when renting an apartment, a room, or a house in Denmark.
• It potentially concerns a lot of people. Basically, all landlords and tenants.

Since it was missing from Wikipedia, I decided to fill that gap. Here is a short guide, based on my experience, on how you can do it too.

My article (only in Danish)

• Wikipedia: Standardblanket for lejeaftaler

In short, the article helps landlords and tenants to use the right version of the rental contract. Over the past 29 years, there have been 4 versions, and I explain the importance of using the right version and the potential consequences when you don’t.

Preparation

Check if your topic is missing or underdeveloped

Before creating an article, do a quick search on Wikipedia to make sure it doesn’t already exist or that it’s not adequately covered.

Read the key guidelines

• Wikipedia:Neutral Point of View
• Wikipedia:Manual of Style
• Wikipedia:Five Pillars
• Wikipedia:Notability

There is a lot to read and it took me some time. Most is common sense, but I had extra focus on ensuring the Neutral Point of View. I also wanted to make sure that it looked like a real Wikipedia article. That is, ensure consistency.

Gather reliable sources

Every fact, statement, or claim should ideally have a reference from a reputable source. Wikipedia articles thrive on verifiability.

Most of my sources were government websites, so that was easy.

Writing Your Draft

Once you have signed up, you go to your Sandbox and start writing.

Use the Wikipedia Sandbox

You draft your article in the personal sandbox to get familiar with Wikipedia’s markup and style before publishing.

Focus on neutrality

Wikipedia articles must avoid personal opinions. State the facts, cite sources, and keep a neutral tone.

I made sure that both the landlord and the tenant would benefit equally from the article.

Wikipedia markup

Wikipedia has a special markup language, which is different from, for example, Markdown. But you don’t really have to know anything about it. Simply use the editor.

Here are a few examples.

• Use double square brackets for internal links, e.g., [[Article Title]].
• Bold the article title the first time it appears, e.g., '''Article Title'''.
• Use == Heading == syntax for section titles.

Publishing and Follow-Up

Once you have moved your article from the Sandbox to its real place, it is no longer your baby. It lives its own life, and other people can contribute to it.

Review your draft

Double-check grammar, style, and references. Ensure your draft aligns with Wikipedia’s Manual of Style.

Move from sandbox to main space

Once you’re confident, you can publish your draft. Be prepared for feedback and possible edits from the Wikipedia community.

Monitor and respond

Other editors may add, remove, or refine content. Engage politely on the article’s talk page if you need to discuss changes.

Why Contribute?

Share knowledge

If you notice a topic of general interest that isn’t on Wikipedia or is incomplete, adding your expertise benefits everyone.

Strengthen Wikipedia

By contributing high-quality articles, you help maintain and improve the world’s largest encyclopedia.

Learn along the way

Writing in Wikipedia’s style forces you to be concise, neutral, and well-referenced — excellent skills for any research-based writing.

Closing Thoughts

Contributing to Wikipedia was hard work, fun, rewarding, and informative.

In The Divine Comedy by Dante Alighieri, in part Purgatorio, Canto XV (15), Virgil explains to Dante:

That the more of any material thing one man has, the less of it there is for others; whereas the more peace or knowledge or love one man has, the more there is for all the others.

Happy editing!

The notes and links are disappearing. What is going on?

Recently, I had to solve the above mystery for a customer. It made me discover some of the inner workings of Record Links and I thought I better share this knowledge before someone gets hurt.

The scenario is quite simple. Imagine a Sales Document. It has a primary key with two fields: Document Type and Number. Classic.

When the document changes type from Quote to Order, in this case, it keeps its number and it is just the type that changes.

However, each time the notes and links of the document vanished.

Where did they go? Are they lost forever or can we get them back?

Record Links

Notes and links are records in the same table: Record Links.

Anti-pattern

Record Links is an anti-pattern because of this:

• The table is shared across all companies.
• Instead, it has a field Company specifying which company the record belongs to.

I ignore the origins of this design decision, but I suppose it could have been like any other table with DataPerCompany and consequently there would be no need for the Company field.

Fields

The primary key is an integer and it is automatically incremented by the system.

The field Record ID is of the special type RecordID. This is a unique pointer to any record in the database independently of the table and company. I will show you how to find the original record further down.

Table Design

The following is a reduced version of the table, included so you don’t have to look for it.

You can find the table in the Microsoft System app.

table 2000000068 "Record Link"
{
    Caption = 'Record Link';
    DataPerCompany = false;
    ReplicateData = false;
    Scope = Cloud;
    InherentPermissions = rX;

    fields
    {
        field(1; "Link ID"; Integer)
        {
            AutoIncrement = true;
            Caption = 'Link ID';
        }
        field(2; "Record ID"; RecordID)
        {
            Caption = 'Record ID';
        }
        field(3; URL1; Text[2048])
        {
            Caption = 'URL1';
        }
        field(7; Description; Text[250])
        {
            Caption = 'Description';
        }
        field(8; Type; Option)
        {
            Caption = 'Type';
            OptionCaption = 'Link,Note';
            OptionMembers = Link,Note;
        }
        field(9; Note; BLOB)
        {
            Caption = 'Note';
            SubType = Memo;
        }
        field(12; Company; Text[30])
        {
            Caption = 'Company';
            TableRelation = System.Environment.Company.Name;
        }
    }

    keys
    {
        key(Key1; "Link ID")
        {
            Clustered = true;
        }
        key(Key2; "Record ID")
        {
        }
        key(Key3; Company, "Record ID")
        {
        }
    }
}

Page Design

If you want to make a page showing all the record links, you need the following code on the OnOpenPage trigger. Because you are only interested in seeing the record links for the current company.

trigger OnOpenPage()
begin
    Rec.SetRange(Company, Database.CompanyName());
end;

Function Design

Test if Record Link is Orphaned

To test if a record link is orphaned, you need a function like this:

local procedure RecordLinkIsOrphaned(RecordLink: Record "Record Link"): Boolean
var
    RecRef: RecordRef;
begin
    if RecordLink.Company <> Database.CompanyName() then
        RecRef.ChangeCompany(RecordLink.Company);
    exit(not RecRef.Get(RecordLink."Record ID"));
end;

If you do not change the company, the Get will fail when the record is not in the current company.

Move a Record Link to another record

Assume that we have some kind of Sales Document as mentioned in the beginning.

In our scenario, the record links did not get moved to the new record.

Luckily, there is a standard codeunit to help us with this: Record Link Management.

procedure MoveRecordLink(FromSalesDocument: Record SalesDocument; ToSalesDocument: Record SalesDocument)
var
    LinkManagement: Codeunit "Record Link Management";
begin
    LinkManagement.CopyLinks(FromSalesDocument, ToSalesDocument);
    FromSalesDocument.DeleteLinks();
end;

Warning: Do not try this in production

My first version of the above function looked like this:

procedure MoveRecordLink(FromSalesDocument: Record SalesDocument; ToSalesDocument: Record SalesDocument)
var
    LinkManagement: Codeunit "Record Link Management";
begin
    LinkManagement.CopyLinks(FromSalesDocument, ToSalesDocument);
    LinkManagement.RemoveLinks(FromSalesDocument);
end;

Though this looks right, it is wrong. The following line will remove the record links on all records in the entire table, not just on the selected record.

    LinkManagement.RemoveLinks(FromSalesDocument); // DANGER

So, please, note that you have to use the following code to remove the links on a specific record.

    FromSalesDocument.DeleteLinks();

Deleting a Record Link - Behind the Scenes

Let’s say, you have added a note to a document and then you delete the document. What happens to the note?

It depends on whether the OnDelete trigger is run or not.

If you delete the document from the UI, that is a Page, then the note is deleted automatically. If you delete the document from code, you have to explicitly tell the code to run the OnDelete trigger.

This will delete the note:

    SalesDocument.Delete(true);

This will not delete the note and the note will become an orphan.

    SalesDocument.Delete(false);

Anti-pattern

Normally, at least in the past, we only ran the trigger, if there was code on it. Rec.Delete(false);

Now, if you are deleting a record that has record links, but no code in the OnDelete trigger, you have to run it like this Rec.Delete(true);.

Removing Orphaned Links

There is a function for that and you can use it like this:

local procedure RemoveOrphanedLinks()
var
    LinkManagement: Codeunit "Record Link Management";
begin
    LinkManagement.RemoveOrphanedLinks();
end;

This will remove all orphaned links in the entire database in all companies.

Job Queue Entry

I have not quite understood the relation ship between error messages in Job Queue Entry and Record Links.

If you make a page displaying all Record Links in the company, you will see notes belonging to Job Queue Entries. This a bit strange. If you open the corresponding Job Queue Entry Card page and click Show Error, you will see the latest error. But in the Record Links there will be the entire history of errors.

If you know anything about this, let me know.

Back to Our Mystery

The origin of the disappearing links and notes were this code.

SalesDocument.Find();
SalesDocument.Delete();
SalesDocument.Copy(NewSalesDocument);

The good part of the story is that the programmer wrote SalesDocument.Delete(); thereby making all the Record Links orphans and since only the document type changed, I was able to find and pair all Record Links with its parent again.

I fixed the code like this.

SalesDocument.Find();
MoveRecordLink(SalesDocument, NewSalesDocument);
SalesDocument.Delete();
SalesDocument.Copy(NewSalesDocument);

When Anti-patterns Meet

This was the story of what can happen when two anti-patters meet.

The story ended happily. The users got their links and notes back.

But it could have gone terribly wrong.

Anti-patterns are the opposite of best practice and they are bad for our brains. When we see something we first presume, it works as usual and we use our intuition to move forward quickly. When it doesn’t we have to analyze it and it will slow us down.

Message to all BC developers: Stick to best practices whenever you can and avoid anti-patterns.

Microsoft has announced their new upgrade strategy, where they explain that they need to clean up obsoleted fields and tables since version 12.

Version 25 is going to be a Jump Version.

Source: Microsoft on YouTube: Introduction to Business Central cloud migration (2023)

What is a Jump Version?

The following versions are Jump Versions.

• Version 14.0 aka BC 2019 Spring
• Version 25.0 aka BC 2024 Wave 2 (arrives in October 2024)
• Version 30.0 aka BC 2027 Wave 1 (every 5 versions will be a jump version in the future.)

You can upgrade directly to a Jump Version if you are on a previous version. But you have to stop on the Jump Version to get to the next one or higher.

This means that to upgrade to version 26.0 aka BC 2025 release wave 1, you will first have to upgrade to version 25, if you are on an earlier version.

Now is a good time to clean up

What does it all mean? It means that it is in your and your customers’ best interest to clean up, implement robustness and automated tests.

Automated Tests

We used to test when a new version was installed. Now we need to automatically test business-critical functions and APIs frequently.

There has never been a better argument or a better time for getting started with automated tests.

In my Clean AL Code Initiative series, you can read more about Automated Tests in AL

Robustness

We need to have built-in robustness in our customizations. We need to require that our suppliers also have this robustness built-in.

In my Clean AL Code Initiative series, you can read more about How to make a code review and how to make robust code in Preconditions and TryFunctions in AL

Explain it and Sell it to your customers

We told customers that they never have to go through upgrade hell again, but did we tell them that they now are in maintenance mode?

We need to explain and sell this to our customers.