Business Central Developer Training for AL Extension Development and MB-820 Preparation

Business Central developer training teaches former NAV developers to replace direct customisation habits with AL extension development. The work now starts in Visual Studio Code, depends on AL extensions, and needs a lifecycle that can survive monthly service updates.

Business Central developer training is the practical study of building, testing, packaging, and maintaining extensions for Microsoft Dynamics 365 Business Central using AL, Visual Studio Code, source control, and modern deployment practices. For developers moving from .NET, Power Platform, or older NAV environments, the main shift is architectural: the base application is treated as a platform to extend rather than a codebase to alter.

Last updated: 2026. This guidance is written for the current Business Central development model and aligns with Microsoft Learn references for the MB-820 Microsoft Dynamics 365 Business Central Developer exam, the AL language reference, event-based development, and Business Central DevOps guidance. Microsoft changes product capabilities over time, so project settings, event signatures, and exam objectives should be checked against the current Microsoft Learn pages before a production release or exam booking.

What Business Central developers actually build

A Business Central developer usually works on extensions that add fields, pages, validations, integrations, reports, or process automation around finance, sales, purchasing, inventory, jobs, and service operations. The work is rarely isolated code writing. A small change to a table extension can affect page layouts, permissions, APIs, upgrade routines, telemetry, testing, and AppSource validation if the extension is intended for the marketplace.

The first design decision is distribution. An AppSource extension is built for a broad audience and must satisfy marketplace validation, stricter dependency control, permissions, AppSourceCop rules, signing expectations, and careful versioning. A per-tenant extension is customer-specific, usually changes faster, and is often the right model for local business rules, integrations, or internal process changes that do not need a marketplace listing. That decision influences the publisher, name, ID ranges, dependencies, target settings, and validation rules in app.json from the beginning.

This is also where older development habits need to be replaced. Direct modification of the base application is not the extension model for Business Central SaaS, and it creates upgrade risk even in environments where more freedom exists. The modern approach is to extend objects, subscribe to events, expose APIs where appropriate, and keep custom logic in a separate app that can be versioned, tested, and deployed independently.

Setting up a modern AL development environment

The standard local workflow starts with Visual Studio Code, the AL Language extension, Git, and access to a Business Central sandbox or container. Developers create an AL project, configure app.json, download symbols from the target environment, write extension objects, then publish and debug against a sandbox or a local container. The old idea of working inside a built-in object designer has been replaced by a source-controlled project structure that can be reviewed, built, tested, and released through a pipeline.

A Microsoft-hosted sandbox is usually the simplest place to begin. It reflects the SaaS service model, requires less local infrastructure, and is suitable for many extension, debugging, and user acceptance scenarios. Local containers built with BCContainerHelper are useful when a team needs stronger version pinning, repeatable build agents, automated test execution, or deeper investigation of behaviour before release. Containers add operational overhead, but they are valuable when reproducibility matters more than convenience.

Common setup mistakes are predictable. Developers forget to download symbols after changing the target environment, leave the wrong target in app.json for on-premises features, skip signing when release policy requires it, or treat version numbers as cosmetic. Another frequent issue is depending on an event that is not stable across target versions. In practice, the downloaded symbols are the working contract for the environment being extended, and they should be refreshed whenever the target changes.

Key app.json settings deserve early attention because they affect packaging and deployment later. The app ID must remain stable for the life of the extension, dependency versions should be deliberate, and publisher and name values should be treated as release metadata rather than placeholders. For AppSource work, code analysis rules such as AppSourceCop need to be part of the daily build rather than a final-stage surprise.

Learning AL through extension objects

AL development becomes clearer when learners start with the object model. Tables define persisted data, table extensions add fields to existing tables, pages and page extensions control user experience, codeunits hold reusable business logic, reports produce documents and analysis, and permission sets decide what users can access. The skill is not merely knowing object syntax; it is understanding where a change belongs so that the extension remains maintainable.

The following example shows a small table and page pair. It is intentionally simple because the learning point is object structure: field numbers, data classification, keys, page source tables, and the relationship between persisted data and user interface.

Example — A simple AL table and list page

table 50100 "Training Resource"
{
    DataClassification = CustomerContent;

    fields
    {
        field(1; "No."; Code[20])
        {
            DataClassification = CustomerContent;
        }

        field(2; Name; Text[100])
        {
            DataClassification = CustomerContent;
        }

        field(3; "Active"; Boolean)
        {
            DataClassification = CustomerContent;
        }
    }

    keys
    {
        key(PK; "No.")
        {
            Clustered = true;
        }
    }
}

page 50100 "Training Resources"
{
    PageType = List;
    SourceTable = "Training Resource";
    ApplicationArea = All;
    UsageCategory = Lists;

    layout
    {
        area(Content)
        {
            repeater(Resources)
            {
                field("No."; Rec."No.") { }
                field(Name; Rec.Name) { }
                field("Active"; Rec."Active") { }
            }
        }
    }
}

This code creates a custom table and a list page that exposes it in the client. In a real project, the next checks would include object ID allocation, captions, permissions, test data, and whether this information should be stored in a separate custom table or attached to an existing Business Central entity through a table extension.

Events are the safer way to react to standard application behaviour without changing Microsoft-owned objects. Developers should learn both integration events published by the base application and custom events published inside their own extensions. Event subscribers allow logic to run at defined extension points while keeping the custom app separate from the platform code.

Example — Subscribing to an event in AL

codeunit 50101 "Training Resource Events"
{
    [EventSubscriber(ObjectType::Table, Database::"Training Resource", 'OnBeforeInsertEvent', '', false, false)]
    local procedure RequireNameBeforeInsert(var Rec: Record "Training Resource"; RunTrigger: Boolean)
    begin
        if Rec.Name = '' then
            Error('Name must be entered before the resource can be created.');
    end;
}

The subscriber enforces a small rule before a record is inserted. The wider lesson is that event-based development keeps the rule in the extension rather than embedding it in a modified base object. For standard Business Central objects, developers should confirm event names and parameter signatures from the symbols downloaded for the exact target version.

From coding to a release-ready extension

Professional Business Central development is shaped by release management. Semantic versioning matters because Business Central uses app identity and version metadata to understand upgrade paths. Changing a field, object, or dependency without a migration plan can block installation or damage data continuity, especially when several apps depend on each other.

Obsolete states are part of responsible maintenance. When a field or object needs to be replaced, developers should mark it as obsolete, communicate the reason, and plan the removal rather than deleting it abruptly. Upgrade codeunits then handle data movement when an installed app moves from one version to another. This is one of the areas where experienced application developers often need Business Central-specific training, because the technical change is tied directly to customer data preservation.

AL-Go for GitHub and Azure DevOps-based pipelines help teams turn these release practices into repeatable quality gates. A mature pipeline can compile the app, restore artifacts, run code analysis, execute automated tests, sign packages where required, and publish build outputs for review. Some teams also create short-lived validation environments for pull requests so that each change is tested against a clean Business Central instance before it is merged.

1. Create the AL project with a stable app ID, name, publisher, version, and dependency model.
2. Download symbols from the intended target environment before writing or updating objects.
3. Build extension objects, event subscribers, permissions, and tests in source control.
4. Run code analysis and automated tests before packaging the app.
5. Publish to a sandbox or container and verify installation, data upgrade, and permissions.
6. Promote the signed package through the agreed release process after review.

That sequence prevents a common anti-pattern: writing AL code first and discovering deployment constraints late. Business Central extensions live inside customer environments where permissions, dependencies, upgrade paths, and performance matter as much as syntax.

Testing, performance, and telemetry

Testing in Business Central should include more than manual page checks. Test codeunits can validate rules, posting behaviour, upgrade routines, and integration assumptions. They also give teams a safer way to refactor when Microsoft releases new application versions or when a dependent extension changes.

The next example shows the shape of a test codeunit. The exact libraries available depend on the test toolkit and target environment, but the pattern is the same: arrange data, execute the behaviour, then assert the result.

Example — A focused AL test codeunit

codeunit 50102 "Training Resource Tests"
{
    Subtype = Test;

    [Test]
    procedure InsertResourceRequiresName()
    var
        TrainingResource: Record "Training Resource";
    begin
        TrainingResource.Init();
        TrainingResource."No." := 'RES-100';

        asserterror TrainingResource.Insert(true);
    end;
}

This test checks that the validation rule prevents incomplete data from being inserted. In production-quality tests, teams would add assertions for the specific error, include positive-path tests, and run the suite automatically in the build pipeline rather than treating tests as optional local checks.

Performance work should start before go-live. Developers need to understand record filtering, keys, set-based operations, page loading behaviour, and how integrations affect transaction time. Business Central telemetry can be sent to Azure Application Insights, where teams can analyse extension errors, long-running operations, web service calls, and performance patterns after deployment. A telemetry-first mindset changes support from guesswork into evidence-based troubleshooting.

How MB-820 fits into a Business Central developer learning path

The MB-820 exam is aimed at Business Central developers who design, build, test, and maintain solutions using AL. Microsoft Learn describes skills around Business Central architecture, development environment setup, AL objects, user interface extension, business logic, integrations, and application lifecycle management. The exam should be treated as a structured validation of practical development ability rather than a substitute for building extensions.

A sensible path depends on the learner’s starting point. A .NET developer may move quickly through syntax and spend more time on Business Central data structures, posting concepts, permissions, and extension events. A Power Platform developer may already understand business process automation but need deeper practice with AL, app packaging, and source control. A functional consultant may only need enough AL to read extensions, write small changes, and communicate accurately with a development team.

Instructor-led preparation can help when the goal is to connect these topics to the MB-820 objectives without drifting into unrelated development content. Readynez offers an MB-820 Business Central Developer course for learners who want a guided route through the exam-relevant skills and practical development workflow. Learners who need broader prerequisites first can review the wider Microsoft training catalogue before committing to a developer-specific path.

Choosing the right training route

Business Central developer training works best when it is project-led. A learner should leave the path with a working extension in source control, tests that can be run again, a clear packaging process, and enough understanding of telemetry to support the app after release. Reading AL syntax alone does not prepare a developer for dependency conflicts, upgrade codeunits, permissions, or AppSource validation.

Teams evaluating training should look for alignment with current AL and Visual Studio Code workflows, MB-820 objectives, Git-based development, test automation, and deployment lifecycle practices. They should also avoid materials that still imply direct base application changes, use outdated product names such as Microsoft Flow instead of Power Automate, or ignore signing, semantic versioning, and symbol management.

A longer learning plan may combine Business Central developer training with adjacent Microsoft skills such as Azure DevOps, Power Platform integration, and security fundamentals. Readynez learners who expect to take several Microsoft courses can consider Unlimited Microsoft Training as one way to structure that broader path.

Building AL skills that survive production

The strongest Business Central developers are comfortable moving between AL code, business process, release discipline, and operational support. They know when to use a table extension rather than a custom table, when to subscribe to an event rather than duplicate logic, when a per-tenant extension is enough, and when AppSource requirements must shape the design from day one.

The practical next step is to build a small extension end to end: configure the project, download symbols, create objects, subscribe to events, add tests, package the app, publish it to a sandbox, and inspect telemetry after exercising the feature. Readers who want help choosing the right MB-820 preparation route can contact Readynez to discuss the certification path and related Microsoft training options.

FAQ

What should Business Central developer training cover?

It should cover AL development in Visual Studio Code, project configuration, symbols, extension objects, event subscribers, source control, testing, packaging, deployment, upgrade codeunits, and telemetry. For MB-820 preparation, it should also map these skills to the current Microsoft Learn exam outline without replacing hands-on practice.

Is Business Central development mainly for experienced programmers?

Experienced developers usually progress faster, especially if they already understand typed languages, Git, APIs, and automated testing. Functional consultants can still benefit from lighter AL training when they need to read customisations, make small changes, or communicate more precisely with developers.

Should learners use a SaaS sandbox or a local container?

A SaaS sandbox is usually better for early learning and validating behaviour in a Microsoft-hosted environment. A local container is useful when the team needs repeatable test runs, specific artifacts, version pinning, or deeper debugging as part of a professional build process.

How does MB-820 relate to real project work?

MB-820 focuses on skills that a Business Central developer uses in real projects, including AL objects, business logic, integrations, and application lifecycle management. Passing an exam is most realistic when study is paired with building and releasing sample extensions.

What mistakes should new Business Central developers avoid?

New developers should avoid designing around base application changes, skipping symbol downloads, ignoring dependency versions, using weak app versioning, delaying tests until the end, and forgetting upgrade codeunits when data structures change. They should also use current product names such as Power Automate and validate settings against the target Business Central environment.