Namespaces in AL

The Problem That Needed Solving

Before the release of Business Central 2023 Wave 2 (version 23.0), which became generally available on October 2, 2023. The AL development world faced a fundamental challenge: naming conflicts. Imagine two independent software vendors creating brilliant extensions for Business Central. Both naturally name their core table “Project Management” or “Time Registration”. When customers tried to install both extensions, chaos ensued. The system couldn’t distinguish between the two “Project Management” tables, leading to broken functionality and frustrated users.

This wasn’t just a theoretical problem—it was a major roadblock for building a rich ecosystem of interoperable extensions on Microsoft AppSource.

The Solution: Namespaces Arrive

In October 2020, Microsoft introduced namespaces to Business Central, fundamentally changing how we develop and distribute extensions. A namespace acts as a unique prefix that identifies all objects within an extension, much like a surname distinguishes people with the same first name.

What Exactly is a Namespace?

A namespace is a unique identifier that you register for your company or solution. For example:

Microsoft.Sales.Customer (Microsoft’s sales customer table)
Contoso.ServiceMgmt (Contoso’s service management extension)
Waldo.InventoryAnalytics (Waldo’s inventory analytics solution)

Instead of just “Customer,” we now have fully qualified names that eliminate ambiguity.

Real-World Implementation

Declaring Your Namespace

Every extension now can have a namespace declaration in its app.json file:

JSON

{
  "name": "Contoso Service Management",
  "publisher": "Contoso Inc.",
  "version": "1.0.0.0",
  "runtime": "11.0",
  "namespace": "Contoso.ServiceMgmt"
}

{
  "name": "Contoso Service Management",
  "publisher": "Contoso Inc.",
  "version": "1.0.0.0",
  "runtime": "11.0",
  "namespace": "Contoso.ServiceMgmt"
}

Writing Code with Namespaces

Here’s how namespaces transform your development experience:

namespace Contoso.ServiceMgmt;

using Microsoft.Sales.Customer;
using Microsoft.Sales.History;
using Microsoft.Inventory.Item;

table 50100 "Service Contract"
{
    fields
    {
        field(1; "Contract No."; Code[20]) { }
        field(2; "Customer No."; Code[20])
        {
            TableRelation = Customer; // Thanks to 'using', we don't need full namespace
        }
        field(3; "Service Item No."; Code[20])
        {
            TableRelation = Item;
        }
    }
}

codeunit 50100 "Contract Management"
{
    procedure CreateContract(CustomerNo: Code[20])
    var
        Customer: Record "Customer";
        SalesHeader: Record "Sales Header";
    begin
        // Clean, readable code without namespace clutter
        Customer.Get(CustomerNo);
        if Customer.Blocked then
            Error('Customer %1 is blocked', Customer.Name);
        
        // Business logic here
    end;
}

namespace Contoso.ServiceMgmt;

using Microsoft.Sales.Customer;
using Microsoft.Sales.History;
using Microsoft.Inventory.Item;

table 50100 "Service Contract"
{
    fields
    {
        field(1; "Contract No."; Code[20]) { }
        field(2; "Customer No."; Code[20])
        {
            TableRelation = Customer; // Thanks to 'using', we don't need full namespace
        }
        field(3; "Service Item No."; Code[20])
        {
            TableRelation = Item;
        }
    }
}

codeunit 50100 "Contract Management"
{
    procedure CreateContract(CustomerNo: Code[20])
    var
        Customer: Record "Customer";
        SalesHeader: Record "Sales Header";
    begin
        // Clean, readable code without namespace clutter
        Customer.Get(CustomerNo);
        if Customer.Blocked then
            Error('Customer %1 is blocked', Customer.Name);
        
        // Business logic here
    end;
}

The `using` Directive: Namespace’s Best Friend

While namespaces solve the uniqueness problem, they could make code verbose. Enter the using directive—a way to tell the compiler “in this file, assume these objects belong to these namespaces.”

Without `using` (Verbose):

procedure ProcessOrder()
var
    Customer: Record "Microsoft.Sales.Customer.Customer";
    SalesLine: Record "Microsoft.Sales.SalesLine.Sales Line";
begin
    Customer.Get('CUST1001');
    SalesLine.SetRange("Sell-to Customer No.", Customer."No.");
end;

procedure ProcessOrder()
var
    Customer: Record "Microsoft.Sales.Customer.Customer";
    SalesLine: Record "Microsoft.Sales.SalesLine.Sales Line";
begin
    Customer.Get('CUST1001');
    SalesLine.SetRange("Sell-to Customer No.", Customer."No.");
end;

With `using` (Clean):

using Microsoft.Sales.Customer;
using Microsoft.Sales.SalesLine;

procedure ProcessOrder()
var
    Customer: Record Customer;
    SalesLine: Record "Sales Line";
begin
    Customer.Get('CUST1001');
    SalesLine.SetRange("Sell-to Customer No.", Customer."No.");
end;

using Microsoft.Sales.Customer;
using Microsoft.Sales.SalesLine;

procedure ProcessOrder()
var
    Customer: Record Customer;
    SalesLine: Record "Sales Line";
begin
    Customer.Get('CUST1001');
    SalesLine.SetRange("Sell-to Customer No.", Customer."No.");
end;

Why This Matters for Your Business

For Independent Software Vendors (ISVs):

AppSource Compatibility: Namespaces are mandatory for AppSource publication
Brand Protection: Your unique namespace protects your intellectual property
Coexistence: Your extensions can safely coexist with competitors’ solutions

For In-House Development Teams:

Modular Architecture: Build independent modules that don’t interfere with each other
Team Scalability: Multiple teams can work on different extensions simultaneously
Upgrade Safety: Reduce risk when updating or modifying extensions

For Partners and Implementers:

Solution Composition: Confidently combine extensions from different vendors
Customization Safety: Add custom functionality without breaking existing solutions
Cleaner Code: More readable and maintainable codebase

Practical Benefits in Action

Consider these real scenarios:

Scenario 1: Multiple Project Management Solutions

Company A uses Microsoft.Projects.Project (standard BC)
Company B uses JetProjects.Advanced.Project (third-party)
Company C uses Contoso.Internal.Project (custom internal)

All three can coexist without conflicts.

Scenario 2: Extension Dependencies

namespace Contoso.AdvancedReporting;

using Microsoft.Sales.Customer;
using Waldo.InventoryAnalytics;  // Third-party extension
using Contoso.ServiceMgmt;       // Our other extension

codeunit 50100 "Business Intelligence"
{
    procedure GenerateReport()
    var
        Customer: Record Customer;
        Forecast: Record "Inventory Forecast Entry";  // From Waldo.InventoryAnalytics
        ServiceContract: Record "Service Contract";   // From Contoso.ServiceMgmt
    begin
        // Seamless integration across multiple extensions
    end;
}

namespace Contoso.AdvancedReporting;

using Microsoft.Sales.Customer;
using Waldo.InventoryAnalytics;  // Third-party extension
using Contoso.ServiceMgmt;       // Our other extension

codeunit 50100 "Business Intelligence"
{
    procedure GenerateReport()
    var
        Customer: Record Customer;
        Forecast: Record "Inventory Forecast Entry";  // From Waldo.InventoryAnalytics
        ServiceContract: Record "Service Contract";   // From Contoso.ServiceMgmt
    begin
        // Seamless integration across multiple extensions
    end;
}

Cloud vs. On-Premises Deployment

The introduction of namespaces marked a fundamental shift in AL development. However, the timeline and enforcement of this change have been significantly different between the Cloud (SaaS) and On-Premises environments.

Cloud – Strict Enforcement

// REQUIRED in Cloud
namespace Contoso.MyApp;

using Microsoft.Sales.Customer;
using Microsoft.Sales.Order;

codeunit 50100 "My Codeunit"
{
    procedure Process()
    var
        Customer: Record Customer; // WORKS due to 'using'
    begin
        Customer.FindFirst();
    end;
}

// REQUIRED in Cloud
namespace Contoso.MyApp;

using Microsoft.Sales.Customer;
using Microsoft.Sales.Order;

codeunit 50100 "My Codeunit"
{
    procedure Process()
    var
        Customer: Record Customer; // WORKS due to 'using'
    begin
        Customer.FindFirst();
    end;
}

On-Premises – Mixed/Transitional Mode

// STILL WORKS in On-Prem (not recommended for new development)
codeunit 50100 "My Codeunit"
{
    procedure Process()
    var
        Customer: Record Customer; // WORKS, but may generate a warning
    begin
        Customer.FindFirst();
    end;
}

// STILL WORKS in On-Prem (not recommended for new development)
codeunit 50100 "My Codeunit"
{
    procedure Process()
    var
        Customer: Record Customer; // WORKS, but may generate a warning
    begin
        Customer.FindFirst();
    end;
}

Migration and Best Practices

For New Developments:

Always declare a namespace from day one
Choose meaningful, unique namespaces (typically Company.ProductArea)
Use using directives strategically to maintain code readability

For Legacy Code:

Microsoft provided migration tools to add namespaces to existing extensions
The process is well-documented and relatively straightforward
The long-term benefits outweigh the migration effort

Conclusion: A Foundation for the Future

Namespaces represent more than just a technical feature—they’re the foundation of Business Central’s modern ecosystem. By solving the fundamental problem of naming conflicts, they enable:

True modularity in business application development
Safe composition of solutions from multiple vendors
Enterprise-grade scalability for complex implementations
Innovation without constraints for developers

This change marked Business Central’s transition from a monolithic system to a truly composable business platform. For developers, it meant embracing a new way of thinking about code organization. For businesses, it meant unprecedented flexibility in tailoring their ERP systems.

The introduction of namespaces wasn’t just an update—it was a strategic move that positioned Business Central for the future of enterprise resource planning in a world where customization and integration are no longer nice-to-have features, but essential business requirements.

Whether you’re an ISV building the next great AppSource solution or an in-house developer creating custom functionality, understanding and properly implementing namespaces is no longer optional—it’s essential for success in the modern Business Central ecosystem.

Sources:

Namespaces in AL
Finally we got namespaces in AL and Business Central, let’s try it out!