Confirm() must be implemented through the Confirm Management codeunit

The built-in Confirm() function displays a confirmation dialog but does not check whether a UI is available. When code that calls Confirm() runs in a non-GUI context — job queues, API calls, web service endpoints — the call fails at runtime with no fallback.

The Confirm Management codeunit from the System Application wraps this check. It calls IsGuiAllowed() before displaying the dialog and returns a configurable default response when no UI is present. Use GetResponse() or GetResponseOrDefault() instead of calling Confirm() directly.

Example

The following code calls Confirm() directly:

codeunit 50100 "Document Processing"
{
    procedure PostDocument()
    begin
        if Confirm('Do you want to post the document?') then; // Confirm() must be implemented through the Confirm Management codeunit [AC0004]
    end;
}

To fix this, use the Confirm Management codeunit:

codeunit 50100 "Document Processing"
{
    procedure PostDocument()
    var
        ConfirmManagement: Codeunit "Confirm Management";
    begin
        if ConfirmManagement.GetResponse('Do you want to post the document?', false) then;
    end;
}

When the diagnostic is reported

• A direct call to Confirm() appears in an application object.

Exception

Page objects (except API pages) and page extensions are excluded. Pages run in a user-interactive context where IsGuiAllowed() returns true, making the Confirm() call safe. API pages are designed for web service consumption and never have a UI, so they are checked.

See also

• Codeunit “Confirm Management” on Microsoft Learn
• Forget Confirm() method; start with Confirm Management module by Tom Kapitan
• The best practice for confirmation dialog box by Yun Zhu
• AC0005 — GlobalLanguage() must be implemented through the Translation Helper codeunit