I’m asking the questions around here in Business Central!

In this video, I go explore how to ask a user a simple yes/no question. Check it out:

https://youtu.be/-MNwRChl4d0

In this video, Erik explores a question that many AL developers might not have considered: why does Business Central have a dedicated Confirm Management codeunit when the built-in Confirm function has worked perfectly fine for decades? As it turns out, there’s a very good reason for the apparent over-engineering.

The Classic Confirm Function

Every AL developer knows the Confirm function. It’s the standard way to ask a user a yes/no question — “Should we continue?”, “Do you want to delete?”, and so on. It’s simple and straightforward:

if Confirm('Should we continue?', false) then
    Message('true')
else
    Message('false');

The second parameter sets the default button. When set to false, the “No” button is highlighted. If you just hit Enter, you get the default response. You can also pass parameters into the confirm text using placeholders:

if Confirm('Should we continue with %1?', false, CustomerName) then
    Message('true')
else
    Message('false');

This has been in the system for decades and works perfectly well. Everybody uses it.

Discovering Confirm Management

While browsing the System Application, Erik came across something that initially seemed odd: a codeunit called Confirm Management. Why would you need an entire codeunit to wrap something as simple as a confirm dialog?

The Confirm Management codeunit offers two main methods:

  • GetResponse
  • GetResponseOrDefault

Using it looks like this:

if ConfirmManagement.GetResponseOrDefault('Should we continue?', false) then
    Message('true')
else
    Message('false');

On the surface, the result looks exactly the same as the built-in Confirm. The dialog appears identical — same “No” highlighted by default, same behavior. So what’s the point?

The Secret Sauce: GuiAllowed

Diving into the source code of the Confirm Management codeunit reveals the answer. The implementation follows Microsoft’s typical facade pattern — a public-facing codeunit with an implementation codeunit behind it. And in that implementation code, the critical difference becomes clear:

The codeunit calls the standard Confirm function internally, but it first checks GuiAllowed. This is the key insight.

Consider scenarios where your code runs without a user interface:

  • Job Queues — background processing with no user present
  • Background threads — asynchronous operations
  • Web services — API calls with no screen or keyboard
  • Automated tests — typically running in a non-GUI scenario

If your code contains a standard Confirm and it gets triggered in any of these contexts, you’d normally have to add defensive code:

if not GuiAllowed then
    // handle the non-GUI case
else
    if Confirm('Should we continue?', false) then
        // proceed

With Confirm Management, this is baked in for you. When GuiAllowed returns false, the codeunit simply returns whatever default value you specified — no dialog, no error, no crash.

The Testing Benefit

One particularly valuable use case is in automated testing. Tests typically run in a non-GUI scenario, which means any Confirm dialog would require a handler to deal with the UI operation. By using Confirm Management instead, your code doesn’t need all those test handlers just to get past confirmation dialogs. The confirm simply returns the default value and your test continues smoothly.

A Note on Implementation

Erik noticed that the Confirm Management codeunit is implemented as a Single Instance codeunit, which means it stays in memory for the entire session. This seems like an unusual choice for something so lightweight — possibly a slight performance optimization at the cost of memory. The reasoning behind that particular design decision remains a bit of a mystery.

Conclusion

What initially looks like unnecessary encapsulation of a simple built-in function turns out to have a very practical purpose. By using Confirm Management instead of the raw Confirm function, your AL code becomes inherently compatible with non-interactive scenarios — job queues, web services, background threads, and automated tests — without requiring additional conditional logic. It’s one of those small changes that makes your code more robust across all the different ways Business Central code can be executed. Sometimes there really is a method to the madness.

Picture of hougaard

hougaard