Microsoft MB-820: Developing Maintainable Business Central Extensions

MB-820, Microsoft Dynamics 365 Business Central Developer, is a current exam for developers who design, build, test, integrate, and maintain extensions for Business Central. Microsoft’s published blueprint covers Business Central architecture, development environments, AL objects, AL language, testing, telemetry, APIs, and integrations. The largest domain is development with AL objects, which makes practical extension work essential.

The exam is part of the Dynamics 365 Business Central Developer certification path. Developers need enough functional understanding to know what they are extending, while functional consultants on MB-800 need enough technical awareness to recognize when configuration has reached its limit. The two roles meet at the extension boundary.

A strong lab is a repository containing one real extension with a table extension, page extension, codeunit, report, permission set, tests, telemetry, and API. Build it in Visual Studio Code, publish it to a sandbox, upgrade it after a schema change, and connect it to an external service. The exam domains then become stages of one software lifecycle instead of separate lists.

Business Central architecture explains why extensions are packaged the way they are

Candidates should understand the base app, system app, extensions, online and on-premises differences, update lifecycle, dependencies, and AppSource concepts. An extension should add value without requiring unsupported modification of Microsoft’s application. That separation is what allows a cloud service to update while customer and partner code continues to evolve.

Inspect the dependencies of a small AL project and identify which capabilities come from the platform, system application, base application, and other extensions. Then consider what happens when the target runtime or dependency version changes. This creates a practical understanding of compatibility rather than a purely conceptual one.

The development environment should make builds reproducible

Visual Studio Code, the AL extension, launch configuration, app metadata, symbols, dependency management, source control, and sandbox settings form the everyday toolchain. Candidates need to know how to configure a workspace, download symbols, debug, publish, and manage multiple extensions without turning the environment into an undocumented personal setup.

Create the project from an empty folder and document every step required for another developer to build it. Add source control and remove any machine-specific secret or path. Reproducibility is a quality attribute: if only one workstation can build the extension, the team has an operational problem before the code even reaches production.

Tables and pages should extend the business model rather than duplicate it

AL objects include tables, table extensions, pages, page extensions, enums, reports, XMLports, codeunits, queries, and more. The design question is often whether to extend an existing object or create a new one. Duplicating standard data can cause synchronization and reporting problems, while overloading a standard table with unrelated fields can also produce poor design.

Add a small domain concept, such as a service classification or fulfillment attribute, and decide where it belongs. Expose it only on the pages that need it. Use an enum when a controlled value set is appropriate. The goal is to express the business concept cleanly with the smallest durable change.

Reports and queries require deliberate data shaping

MB-820 includes report data models, layouts, request pages, report triggers, processing-only reports, queries, joins, filters, aggregation, and XMLports. These tools are not simply output formats. They determine where data is read, transformed, filtered, and presented, with direct implications for maintainability and performance.

Create a report that joins related data, accepts a meaningful filter, and produces a layout suitable for its business audience. Then implement a query for an analytical aggregation and compare the two. Understanding when to use each object is more valuable than memorizing properties because it trains the design judgment the exam expects.

Codeunits, events, and interfaces help isolate behavior

Business logic that is scattered across page triggers is difficult to test and reuse. Codeunits provide a natural place to encapsulate behavior, while events allow an extension to react to the standard application without modifying it. Interfaces can make interchangeable implementations explicit and easier to test.

Move a business rule into a codeunit, expose a narrow procedure, and invoke it from more than one caller. Subscribe to a relevant event instead of editing a standard process. Then replace a hard-coded branch with an interface implementation where variability is expected. These choices make the extension easier to evolve as the system changes.

AL coding standards matter most when errors and upgrades occur

The blueprint covers data types, variables, expressions, file handling, data manipulation, access modifiers, error handling, and Business Central development standards. Code that works on the happy path can still be fragile if it assumes data always exists, exposes internal procedures unnecessarily, or fails with messages that give users no path forward.

Introduce an invalid state and verify that the extension fails safely with useful information. Review access modifiers and remove public surface area that is not required. Then simulate an upgrade that adds a field or changes stored data. Maintainable AL code should make those transitions predictable rather than surprising.

Automated tests protect extensions from platform and business change

Business Central provides the Test Toolkit and test codeunits. A meaningful test establishes data, executes behavior, and verifies business results. The best candidates understand that tests are especially valuable in an evergreen cloud product where Microsoft updates the platform and base application over time.

Create tests for a successful scenario, a permission-related failure, and a boundary condition. Run them before and after changing the extension. If a future platform update changes behavior, these tests become early evidence that the extension needs attention rather than waiting for users to discover the regression.

Telemetry turns production behavior into evidence

The exam includes configuration and analysis of telemetry and observability plus creation of custom signals. Telemetry can reveal slow operations, extension failures, usage patterns, and unexpected behavior that is hard to reproduce locally. Developers should design observability into important operations rather than adding logging only after an incident.

Add a custom telemetry event around a business operation and include identifiers that support diagnosis without exposing sensitive data. Trigger both success and failure conditions, then inspect the signals. This encourages a supportable extension culture in which production questions can be answered from evidence.

APIs and REST integrations should have clear contracts and failure behavior

Business Central can call external REST services and expose APIs. Candidates should understand HTTP classes, JSON handling, API pages, OData actions, authentication considerations, and performance features such as read scale-out. An integration is a contract between systems, so error handling and versioning matter as much as the first successful request.

Build a small external integration that reads one resource and posts another. Handle timeouts, invalid payloads, and authentication failure. Then expose one Business Central API and document its fields and expected behavior. This turns the integration domain into software engineering rather than copy-and-paste HTTP code.

Finish with a release exercise: tag the extension, publish it to a clean sandbox, install or upgrade it, run automated tests, exercise the API, and inspect telemetry. The MB-800 functional exam is useful adjacent context because developers make better extension decisions when they understand the standard Business Central processes they are changing.

If another developer can build, understand, test, upgrade, and support your extension without relying on tribal knowledge, you are operating at the level MB-820 is designed to measure. The exam is fundamentally about creating Business Central software that survives real lifecycle pressure, not just producing AL that compiles.

Schema evolution deserves deliberate practice because Business Central extensions store business data over long periods. Add a field, deprecate an old one, and create an upgrade codeunit that transforms existing records safely. Test the upgrade with realistic data rather than an empty company. The difficult part is not adding new schema; it is preserving the meaning and integrity of data created by earlier versions of the extension.

Dependency management also becomes important when several extensions share functionality. Create a small library extension and a dependent business extension, then change the library interface. Observe how symbol versions and dependency declarations affect compilation and deployment. This makes it easier to reason about AppSource applications and partner solutions where many independently versioned extensions coexist in the same tenant.

Performance troubleshooting should include both AL logic and database access patterns. Build an intentionally inefficient loop, then compare it with filtering, FindSet behavior, query objects, or other more appropriate access patterns. Use telemetry or timing evidence to confirm the effect. A developer who can recognize a bottleneck from production signals and trace it back to code is more valuable than one who only optimizes after users complain.

Integration tests should also model failure after partial success. Suppose an external service accepts a request but the local transaction later fails, or Business Central commits data before the remote API times out. Decide how the extension detects duplication, retries safely, or reconciles uncertain state. APIs are easy when every call succeeds; resilient integration design is about preserving consistency when network and application outcomes disagree.

Permission sets deserve developer attention because an extension is not complete if users must receive excessive rights to run it. Define the tables and operations the feature genuinely requires, package permissions with the app where appropriate, and test with a non-administrator account. A permission error discovered only after production deployment is usually evidence that security was left until too late in development.

Source control and CI/CD should be treated as part of the extension itself. Store the app source, tests, configuration templates, and build metadata together, then create a repeatable build that produces the same package from a clean checkout. Even a small Business Central team benefits from this discipline because it makes releases auditable and reduces dependence on one developer’s local environment.