Use Environment Information to your vantage in AL

A smart app has situational awareness, a smart app knows the environment it’s operating inside. Making your app smart is easy. Check out the video:

https://youtu.be/CgeAhADYiUw

In this video, Erik demonstrates how to leverage environment information in AL to give your Business Central apps situational awareness. Knowing whether your app is running in a sandbox, production, on-premises, or SaaS environment allows you to implement different behaviors — like enforcing licensing only in production, preventing test data from hitting production APIs, or adjusting feature availability based on the deployment context.

Why Situational Awareness Matters

Business Central apps can run in a variety of environments: production or sandbox in the cloud, on-premises, or various SaaS configurations. Building environment awareness into your app lets you make smart decisions at runtime. Erik shares a practical example from his own AppSource apps:

  • Sandbox: Let users try the app freely without requiring a license.
  • Production: Require a paid license before allowing full functionality.
  • API integrations: If your app communicates with external services, you can ensure sandbox environments never send data to production endpoints, or always flag transactions as test data.

The Environment Information Codeunit

Microsoft provides a built-in codeunit called Environment Information that makes it straightforward to determine where your app is running. Here are the key methods available:

  • IsFinancials() — Returns whether the environment is a Financials environment.
  • IsOnPrem() — Returns true if running on-premises.
  • IsProduction() — Returns true if this is a production environment.
  • IsSaaS() — Returns true if running in a SaaS (cloud) environment.
  • IsSaaSInfrastructure() — Returns true if running on SaaS infrastructure.
  • IsSandbox() — Returns true if this is a sandbox environment.

When Erik runs this against a cloud sandbox, the results are:

  • IsFinancials: Yes
  • IsOnPrem: No
  • IsProduction: No
  • IsSaaS: Yes
  • IsSaaSInfrastructure: Yes
  • IsSandbox: Yes

This makes it easy to build conditional logic. For example, you might first check IsSaaS(), and if true, then check IsSandbox() versus IsProduction(). If it’s not SaaS, you can assume it’s on-premises.

Tenant Information and Azure AD Tenant

Beyond environment type, you can also retrieve tenant-specific details using two additional codeunits:

Tenant Information Codeunit

The Tenant Information codeunit provides:

  • GetTenantDisplayName() — Returns the display name of the tenant.
  • GetTenantId() — Returns the internal tenant ID used by Business Central.

Azure AD Tenant Codeunit

If you need the Azure Active Directory tenant ID — which is typically the one you’ll need for integrations and external service calls — use the Azure AD Tenant codeunit:

  • GetAadTenantDomainName() — Returns the domain name (e.g., yourdomain.onmicrosoft.com).
  • GetAadTenantId() — Returns the Azure AD tenant ID (a GUID).

Erik notes an important distinction: the tenant ID from Tenant Information is an internal Business Central identifier, while the Azure AD tenant ID from Azure AD Tenant is the one you’ll typically need when working with Azure services, APIs, or any external integrations.

The Complete Source Code

Here’s the full example that demonstrates all three codeunits in action, wired up as a page extension on the Customer List:

pageextension 50100 CustomerListExt extends "Customer List"
{
    trigger OnOpenPage();
    var
        Environment: Codeunit "Environment Information";
        Tenant: Codeunit "Tenant Information";
        Tenant2: Codeunit "Azure AD Tenant";
    begin
        Message('%1 %2 %3 %4 %5 %6',
            Environment.IsFinancials(),
            Environment.IsOnPrem(),
            Environment.IsProduction(),
            Environment.IsSaaS(),
            Environment.IsSaaSInfrastructure(),
            Environment.IsSandbox());

        Message('%1 %2',
            Tenant.GetTenantDisplayName(),
            Tenant.GetTenantId());

        Message('%1 %2',
            Tenant2.GetAadTenantDomainName(),
            Tenant2.GetAadTenantId());
    end;
}

When the Customer List page opens, three messages display in sequence showing the environment flags, the internal tenant details, and the Azure AD tenant information.

Practical Use Cases

Here are some real-world scenarios where environment awareness is invaluable:

  1. Licensing enforcement: Allow free usage in sandbox environments while requiring a valid license in production.
  2. API safety: Ensure sandbox environments communicate only with test/staging endpoints, or automatically flag transactions as test data.
  3. Feature toggling: Enable or disable certain features based on whether the app is running on-premises versus in the cloud.
  4. Logging and diagnostics: Include environment context in telemetry data to distinguish between production issues and sandbox testing.
  5. Multi-tenant awareness: Use the Azure AD tenant ID to identify tenants when your app communicates with external services.

Summary

Building situational awareness into your Business Central apps is both straightforward and powerful. With just three codeunits — Environment Information, Tenant Information, and Azure AD Tenant — you can determine exactly where and how your app is running and adapt its behavior accordingly. Whether it’s enforcing licensing, protecting production APIs from test data, or simply including context in your telemetry, these tools give you the control you need to build robust, environment-aware applications.

Picture of hougaard

hougaard