Microsoft MB-820: Building Business Central Extensions in AL

MB-820 is the exam for developers who design, implement, test and maintain extensions to Dynamics 365 Business Central. Microsoft's June 10, 2025 skills guide covers Business Central architecture, development environments, AL objects, AL language features, developer tools and integrations. The developer needs to understand the product's standard business logic because a small customization can affect sales posting, inventory, permissions or updates. The MB-800 functional consultant perspective defines that underlying financial and operational setup, which an extension must preserve. The correct outcome is an extension that adds value without making the underlying ERP fragile.

Consider a company that leases specialist equipment and wants custom inspection tracking on sales and service documents. It may need new tables, pages and actions, but the extension must also respect customer ownership, warranties and reporting. A developer who focuses only on placing controls on a page can create records that cannot be reconciled or secured. MB-820 preparation therefore combines AL syntax with data modeling, events, APIs and application lifecycle discipline.

Understand the extension model and standard application boundaries

Business Central has a base application, system application and extension mechanisms. The developer should recognize when to add a table extension, page extension, codeunit or report object, and how each interacts with supported platform behavior. Direct modifications to standard application objects are not the normal extension strategy. A change that works only by altering base code is hard to maintain through SaaS updates and should trigger a different design review.

The object model matters for business meaning. A new equipment inspection record needs a stable key, relationships to the relevant asset or document and suitable data classification. Defining every attribute as a text field may be fast initially but makes validation and reporting unreliable. Decide whether the record is a transaction, master data or supporting note. Its lifecycle determines how it should be edited, retained and exposed through pages or APIs.

Extensions also need versioned dependencies. One extension may call a public interface provided by another app. Changes to that interface can break downstream code even when both applications are otherwise valid. Maintain dependency metadata, test compatible versions and document requirements for installation order. Avoid making an internal implementation detail a public contract unless other extensions actually need it.

Build AL objects with explicit validation and permission design

Tables and fields carry data structure and validation rules; pages present information to users; codeunits encapsulate reusable logic. Business Central triggers and events let developers extend behavior, but execution order and transaction context need attention. A validation invoked when a field changes does not necessarily cover all integration paths unless supported business logic enforces the same rules. Test APIs, imports and background processes as well as interactive pages.

Permissions should follow intended operations. An extension may let technicians record inspections while keeping billing rates visible only to finance. A page control hidden from technicians is not sufficient if the underlying table remains readable through an API or a query object. Define permission sets and test using representative users. Minimize privileges required by background jobs and integrations; a service account that can modify every item master record is unnecessary for an interface that only imports inspection results.

A useful defect scenario is an inspection result entered twice after a mobile client retries a request. If the extension blindly inserts both records, compliance reports overstate completed inspections. Use unique business identifiers and appropriate transaction handling so repeated requests can be recognized and resolved predictably. The system should retain the authorized result and record the duplicate attempt when useful for diagnostics.

Work with AL language patterns and events safely

AL provides constructs for record manipulation, filtering, validation, data access and integration. A developer must know how the business application handles record insert, modify and delete operations and when to invoke validation logic rather than bypass it. Consider a new field whose value affects standard posting; changing the field programmatically may have side effects beyond its stored value. Use supported events and extensions where possible and test rollback on errors.

Event subscribers are powerful, but badly chosen subscribers can create unexpected cascades. A posting event that calls an external HTTP service synchronously may delay or fail a business-critical transaction. Separate durable state changes from asynchronous notifications when the workflow permits it. If the external system must acknowledge the result, use a designed integration contract that specifies timeout, retry and idempotency behavior rather than hiding it inside a form trigger.

Maintainable AL code also needs clear naming, small responsibilities and automated tests. Static analysis warnings, deprecated APIs and unused permissions can signal future update problems. When a change requires copying a large standard procedure merely to alter one condition, search for supported extension points or reconsider the requirement. The less standard logic an extension duplicates, the easier it is to maintain as Business Central evolves.

Integrate with APIs and external systems deliberately

Business Central APIs connect the ERP to e-commerce, warehouse, finance and service applications. A public endpoint needs an authenticated caller, stable contract and appropriate validation. Choose which fields are authoritative and how updates are reconciled. If a third-party application sends a shipping confirmation twice, the destination should avoid double-posting quantities. Use durable correlation IDs and design errors that let integration partners distinguish validation failures from temporary outages.

External systems frequently have different currencies, units and time zones. An integration might receive a quantity in cases while Business Central tracks individual units, or receive a timestamp in UTC while users work in local time. Convert and validate explicitly before creating transactions. A mistake that multiplies quantity by the wrong pack size can create inventory problems that look like theft or lost stock. Test these edge cases in an environment with representative data.

When publishing an API, avoid exposing internal field names or implementation assumptions as an unchangeable public contract without need. Version interfaces when breaking changes are unavoidable, and communicate migration windows. Log request identifiers, duration and failure categories while protecting personal data. Integration observability should help a support engineer reconstruct events without accessing every customer's full payload.

Manage development environments, CI and upgrades

Visual Studio Code and AL tooling support extension authoring, debugging and packaging. A developer should establish repeatable environments and use version control for source files, test data and build configuration. Continuous integration can compile extensions, enforce checks and produce versioned artifacts. A build succeeding does not prove that an extension works with a new application version; run regression tests against realistic business operations.

SaaS updates make compatibility testing essential. A field, event or platform behavior may change, requiring the extension to adapt. Maintain a release pipeline that can deploy to a sandbox, execute tests and collect diagnostics before production rollout. If a schema change transforms existing records, plan for data migration and recovery. Rolling back an app version does not always reverse the data changes introduced by its upgrade.

Performance is another upgrade risk. An extension that queries a table for each line of a large posted document may work well for tiny orders but become slow at month-end. Profile queries and evaluate set-based or more selective approaches when appropriate. Avoid creating overly broad event subscribers that execute for every transaction regardless of whether the feature applies. Performance tuning should protect standard ERP throughput as well as custom functionality.

Business Central extensions should be evaluated against a long-term upgrade contract. Suppose a developer adds a custom action that copies posted sales invoices into a separate table for reporting. That table could easily become a stale, inconsistent shadow ledger if invoices are corrected or credit memos are posted. A better design may query authoritative records or maintain a carefully defined integration projection with reconciliation. The developer should know where posted transaction truth resides and avoid bypassing application posting events.

The AL test strategy should include concurrency. Two users may try to reserve the same unique rental asset at nearly the same time. A page-level validation could pass for both sessions before either commits. The solution needs transactional enforcement and a clear user-facing conflict message. Test the race condition rather than assuming that fast manual testing proves the data rule. Also verify that an API client faces the same constraints as an interactive user.

A final scenario is a permissions change during application upgrade. An extension introduces a new table and service method, but the deployment does not assign the new permission set to the intended role. The application may appear healthy while background processing fails silently for ordinary users. Include role-based smoke tests, error telemetry and an upgrade checklist that compares permission changes with expected business operations. That discipline prevents a technically successful deployment from becoming a support incident.

Test a real extension from requirement to release

Build a small inspection extension with a new table, page, permission set and API integration. Add a validation rule and an event-driven notification that cannot duplicate the core business transaction on retry. Test invalid inputs, privilege boundaries, partial network failures and a platform upgrade in a sandbox. Then review report totals and records to prove that the extension's data remains consistent with Business Central master data.

Use Microsoft's MB-820 study guide for the precise scope, including AL objects, debugging, development lifecycle and integration. A strong candidate can explain not only how to create an object but why a particular extension point, transaction boundary and permission design preserves the ERP's long-term reliability. That engineering judgment is the foundation of sustainable Business Central development.