Every email should be sent from an email scenario in Business Central

Are you using email scenarios? If not, you should. Check the video for how simple it is to enhance your email sending to support scenarios, even custom ones:

https://youtu.be/OgaXMVy4vZY

In this video, Erik demonstrates why every email sent from Business Central should use an email scenario. He walks through the email scenario feature, shows how to assign scenarios to specific email accounts, and explains how to extend the system with custom scenarios using enum extensions — all with surprisingly little effort.

What Are Email Scenarios?

With the email subsystem in Business Central, Microsoft introduced the concept of email scenarios. The idea is simple: whenever an email is sent from Business Central, a scenario is specified. That scenario controls which email account the message is sent from.

For example, you might have multiple email accounts configured:

  • A default/primary account for general communication
  • A sales department account
  • A purchase department account

By navigating to Email Scenarios for the sales account, you can assign specific scenarios — such as Sales Invoice — to that account. This means that when a sales invoice email is sent, it will come from the sales account rather than the default one.

Sending Emails in Code

To send an email programmatically in Business Central, you work with two codeunits. Think of these less as traditional libraries and more as objects:

  • Email Message — used to create and compose the email
  • Email — used to actually send it

Here’s a basic example from the source code:

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage();
    var
        TheMessage : Codeunit "Email Message";
        Email : Codeunit Email;
        base64 : Codeunit "Base64 Convert";
        InS: InStream;
    begin
        TheMessage.Create('erik@hougaard.com','Hello Friend', 'This is the body');
        TheMessage.AddAttachment('myfile.zip','application/zip',base64.ToBase64(InS));
        Email.Send(TheMessage);
    end;
}

This works — it sends an email. But there’s a problem: no scenario is specified. The email will always be sent from the default account, and you’re missing the opportunity to let administrators control routing.

Always Specify the Scenario

The Email.Send() function has overloads. The second overload accepts an email scenario parameter:

Email.Send(TheMessage, Enum::"Email Scenario"::"Sales Invoice");

By specifying the scenario, the email will be routed through whatever account the administrator has mapped to that scenario. If no mapping exists, it falls back to the default account — so nothing breaks.

The rule is simple: never use the basic Send() — always use the overload that specifies a scenario.

Creating Custom Email Scenarios

But what if you’re sending an email that doesn’t fit any of the built-in scenarios? That’s where enum extensions come in. The email scenario is an enum, so you can extend it with your own values:

enumextension 50100 "My Email Scenarios" extends "Email Scenario"
{
    value(50100; "YouTube")
    {
        Caption = 'YouTube';
    }
    value(50101; "Email Scenario Demo")
    {
        Caption = 'Email Scenario Demo';
    }
}

Use IDs from your assigned object range (the same range you use for other objects like pages and tables). After deploying, navigate to Email Scenarios in Business Central, and your new scenarios will appear alongside the standard ones, ready to be assigned to any email account.

Then in your code, simply reference your custom scenario:

Email.Send(TheMessage, Enum::"Email Scenario"::"YouTube");

Seeing It in Action

After deploying the extension and assigning the new scenarios to the sales email account, Erik demonstrated that the email was indeed sent from the sales account — not from the default one. As he noted, “Thunderbird thinks this message is junk mail — I’m not sure that I disagree” — but the important thing is it came from the correct account.

Summary

With surprisingly little effort, you can significantly improve email handling in your Business Central customizations:

  1. Always specify an email scenario when calling Email.Send() — use the overload, never the basic version.
  2. If no existing scenario fits, create an enum extension with your own custom scenarios.
  3. If administrators don’t map the scenario to a specific account, everything still works — it falls back to the default. But if they do map it, your emails are routed correctly.

It’s a small addition to your code that aligns your custom functionality with the rest of the Business Central email infrastructure, giving administrators full control over which accounts send which emails.

Picture of hougaard

hougaard