MB-820: Building Business Central Extensions with AL

MB-820, Microsoft Dynamics 365 Business Central Developer, focuses on extending Business Central through the AL language, development tools, object design, integration, and application lifecycle management. Microsoft's skills outline dated June 10, 2025 remains the basis for this current examination at the October 10, 2026 checkpoint. The engineering objective is to add useful business capability while protecting data integrity, permissions, performance, upgradeability, and supportability. Creating a new page or field is only a small portion of that responsibility.

Business Central extensions are deployed into a business environment where sales orders, posting, purchasing, inventory, and financial reporting must continue reliably. Developers work with functional consultants to identify a requirement and decide whether supported configuration already satisfies it. A customization that duplicates standard logic or depends on undocumented platform behavior can become expensive to maintain through frequent cloud updates. The developer should design from the platform's extension model outward rather than attempting to rewrite the base application.

Understand the extension architecture and its contracts

AL defines tables, table extensions, pages, page extensions, codeunits, reports, queries, interfaces, enums, and other Business Central objects. Each object has a role. A new table may represent a genuinely separate business entity; a table extension adds supported fields to an existing record; a codeunit can encapsulate reusable operations. Choose objects according to data ownership, lifecycle, and business behavior, not simply because an object is convenient to create.

Business Central separates platform and application layers, including standard applications and extensions. Developers need to know which system capabilities are public extension points and which internal details should not be assumed stable. An event subscriber can react to a supported event, but it must respect the publisher's contract and transaction context. Side effects that are harmless when triggered once may be dangerous if an event fires during bulk processing or a retry.

An extension manifest declares identity, version, dependencies, and platform compatibility. Manage these values carefully so environments do not contain conflicting builds or unexpected dependency chains. When extensions are installed or upgraded, schema and data changes must preserve existing business records. An incompatible field change can be more consequential than a compilation error because data may already exist in production.

The code should make the relationship between business data and user experience explicit. For example, a custom warranty entitlement belongs to a controlled record with validation, not only a field displayed on a sales order page. If another system updates that entitlement through an API, the same rules must still apply. Use supported validation and event patterns so that legitimate entry points cannot bypass core controls.

Design tables, pages, and reusable AL behavior

A table definition requires thoughtful keys, field types, relationships, and validation rules. Use identifiers appropriate to the business domain and avoid storing derivable values unnecessarily. Denormalization can improve some read patterns but makes synchronization more difficult when underlying data changes. A good design states which source is authoritative and how outdated representations are refreshed. Review indexing effects on both search performance and write operations.

Pages and page extensions should help users complete work. A purchasing screen might display a warranty status or a calculated approval signal, but the interface should not crowd out fields that staff use every minute. If the customization adds an action, define when it is enabled, who may invoke it, how failure is reported, and whether the result is reversible. Accessibility and localization matter, particularly for extensions intended for multiple tenants or regions.

Codeunits, interfaces, and dependency injection patterns can separate business rules from external services. An approval decision should be testable without contacting a live shipping API. An external connector can translate the API's response into a stable business result. This separation makes future provider changes less disruptive and helps developers build meaningful automated tests.

Error handling should distinguish invalid requests from temporary failures. A user trying to post a document with missing required information needs an actionable explanation. A network timeout should not imply the underlying financial operation definitely failed; the remote system might have processed it already. Design identifiers and retry policies that avoid duplicate updates, and record enough context for a support team to reconcile outcomes safely.

Work effectively in Visual Studio Code and source control

The AL extension development environment uses Visual Studio Code, the AL Language extension, project configuration, symbol downloads, and tools for building, debugging, and publishing to appropriate environments. A repeatable development setup includes compatible dependencies and consistent configuration. Document the test tenant, application version, and required permissions so that a change can be reproduced by another developer.

Source control should preserve design intent. Commit small cohesive changes, require review for sensitive behavior, and use branches or pull requests according to the team's governance. The practices behind branch protection and pull-request controls help reduce accidental releases, even when the exact pipeline configuration varies by organization. Include tests and extension-version changes in the same release plan rather than applying them as untracked manual fixes.

Debugging requires knowledge of both AL execution and business transaction state. A breakpoint may show the code path, but an unexpected result can originate in posting rules, permissions, event ordering, or input data. Reproduce defects with realistic records and isolate the smallest failing case. Avoid troubleshooting directly in production when a supported sandbox can provide the necessary evidence.

AppSource distribution introduces additional considerations such as compatibility, upgrade paths, documentation, security review, and support across different customer environments. A private tenant extension may rely on known business configuration, while a commercial app must cope with a broader range of legitimate setups. Use clear dependency versions and test migration from previous releases, not only a clean installation.

Treat application lifecycle management as a business safety control

ALM coordinates requirements, code, tests, environments, publication, upgrades, and support. The release process should answer who approves new behavior, which environments it has passed through, and how problems will be diagnosed. Continuous integration can compile packages and run appropriate checks, while continuous delivery can stage releases. Neither replaces business acceptance for changes that affect posting, inventory, or customer commitments.

The principle of CI/CD observability is relevant because developers need to know what was deployed, when it ran, and whether post-release behavior changed. Monitor failed integration calls, unusual job-queue volumes, application errors, and transaction processing time after an update. A successful deployment operation is not proof that the new extension is compatible with every real business scenario.

Plan data upgrades explicitly. Introducing a new enum value, changing field semantics, or replacing a table may require migration code and cleanup of old records. Test with populated data and an upgrade path from the version customers actually run. Define recovery procedures before publishing the update. Some data transformations cannot simply be undone by installing an older app package; the team must know the safe correction path.

Integrate Business Central using supported APIs and events

Business Central exposes standard and custom integration capabilities, including APIs, web services, events, and interactions with Power Platform. Choose according to the requirement. Reading a customer balance for display differs from initiating a financial posting in response to an external event. The latter must enforce authorization, validation, idempotency, and reconciliation to business records. Avoid sharing an administrator credential merely because it allows an integration to begin working quickly.

Custom APIs should have stable contracts. Define identifiers, filters, error responses, paging, and the meaning of updates. Consider which records a caller is authorized to access across companies. A data consumer may need a subset of fields, not every property on the underlying table. Apply privacy and business restrictions at the correct layer so a new integration path does not expose previously protected information.

External services can fail independently of the Business Central application. Queue work where appropriate, use retry policies with clear limits, and record the status of each request. When a payment, shipment, or stock adjustment is involved, the receiving party must be able to determine whether a duplicate request is a retry or a genuinely new transaction. Correlation identifiers and idempotency keys can provide that distinction if designed consistently.

Power Automate and other applications may orchestrate business processes, but developers should keep business-rule ownership clear. A flow should not be the only place where a critical finance validation exists if transactions can arrive through another interface. Document the boundary between low-code automation, AL extension code, and standard Business Central behavior.

Test security, performance, and posting outcomes

Permission sets and entitlements determine who can use extension features. A new table storing customer financial data must not inherit broad access by accident. Validate operations under restricted roles, including users who may view but not change sensitive information. The broader concepts of identity and access management reinforce the need to apply least privilege and record authorization decisions, although Business Central has its own permission model.

Automated tests should cover AL business logic, data upgrades, API behavior, and essential posting interactions. Include negative cases: an unauthorized caller, a deleted dependency, a partial return, an invalid dimension, and a repeated external message. A unit test that verifies a field was assigned does not prove the sales or purchasing transaction remains financially correct. Pair technical tests with scenarios developed by functional consultants.

Performance testing should use realistic record counts and concurrency. A page that calculates an expensive aggregate for every row may look fast in a sandbox with fifty records and become unusable with millions. Review database access patterns, key selection, event subscribers, and repeated external calls. Optimize based on measured behavior rather than removing necessary validations to improve a benchmark.

MB-820 differs from the MB-800 Business Central functional role: one is responsible for designing and maintaining technical extensions, while the other primarily configures financial and operational processes. A strong candidate for MB-820 can explain not only how to implement an AL object, but why that object belongs in the architecture, how it is tested and secured, and how it will continue to operate after the platform and business rules evolve.