MB-820: Engineering Dependable Business Central Extensions

Business Central developers work in a system where application logic affects financial records, inventory and business approvals. MB-820 measures the ability to extend that platform using AL, Visual Studio Code, supported application objects, testing and integrations. The June 10, 2025 objective outline includes development environments, extensions, object models, debugging, performance and application lifecycle processes. The priority is not producing the largest customization, but delivering a safe capability that still works when Business Central updates.

A functional consultant preparing for MB-800 may configure standard processes and posting groups. An MB-820 developer writes or extends application behavior after a real requirement has justified it. Keeping that boundary clear prevents custom code from unintentionally becoming the authority on accounting or purchasing policy.

Understand the extension model before starting a project

AL development uses objects such as tables, pages, codeunits, reports, queries and extensions that can adapt the standard application. The supported extensibility model protects upgradeability by favoring additive changes and event-driven integrations over edits to the base application. Before introducing a new table, ask whether a standard entity can carry the information. Before overriding behavior, inspect available events and supported APIs.

A company wants a custom approval reason on purchase orders. It may need a field, form placement, validation and a way to expose the information to reporting. Creating an independent copy of the purchase-order table would break the relationship with built-in posting and approval behavior. A careful design uses supported extensions, defines when the value is required and establishes what happens when an order is copied or reopened.

Development environments and dependencies matter. A developer should know how to configure a sandbox, obtain appropriate symbols and keep project references aligned with supported platform versions. A feature that compiles only on one engineer's machine cannot be trusted for production rollout. Document assumptions about external apps and object versions so build and deployment are repeatable.

Use AL objects to express behavior explicitly

Table objects and table extensions hold data and related validation. Pages present interactions. Codeunits organize reusable procedures and business logic. Report and query objects support analysis and presentation, while extension objects alter supported parts of the standard application. A good design gives each object a clear responsibility instead of hiding many unrelated operations in one large procedure.

Suppose a warranty extension must record the manufacturing batch for returned equipment. The developer needs to relate the return to the correct item and customer, present fields at an appropriate stage and prevent invalid values where policy requires. An ordinary page validation may not cover records created through APIs or background processes. Decide where the invariant belongs and test every permitted entry path.

AL's event model enables extensions to respond to platform behavior without modifying its source. The difficult part is choosing an event that is stable, occurs at the right time and provides enough context. A subscriber that updates financial data too early or too late in a posting sequence can cause inconsistent results. The developer should understand transaction boundaries and avoid turning every event into a broad integration hook.

Treat transactional logic as a shared contract

Business Central transactions can involve multiple records and posting routines. Custom logic must respect error handling and transactional semantics. A developer who writes a secondary record before a transaction is guaranteed to complete can leave contradictory state if the rest of the operation fails. Conversely, holding locks while waiting for an external API can create serious performance and availability problems.

A shipping extension calls a carrier to generate a label. If the carrier times out after accepting the request, blindly retrying can buy two labels and charge the customer twice. Use an idempotency strategy and a reliable record of the external request. The main posting process should not be left in an ambiguous state while the integration waits. A queued workflow may be more appropriate than a synchronous call, depending on the business requirement.

Data validation should distinguish business rules from convenience checks. A valid serial number might have format constraints, but eligibility for warranty may depend on a service record and contract date. Put logic in maintainable services, expose meaningful errors and test conflicting updates. Do not assume a user-facing form is the only way a record can be created or changed.

Build APIs and integrations with ownership and security in mind

Business Central can expose APIs and interact with Power Platform or external services. Integrations need stable identifiers, versioning, permission boundaries and clear data ownership. A customer update from a CRM system and an invoice posting from Business Central are not interchangeable events. Design the interface so consumers know what they may read or write and what the system promises about timing and consistency.

Imagine synchronizing confirmed orders with a manufacturing system. An event might be delivered twice, a receiver might process it after a delay or a field may be missing in an older version. Build validation and reconciliation for these cases instead of assuming each message is processed once in order. An API that returns success while silently discarding a required field is more dangerous than a clear error that can be investigated.

Service identities should receive only appropriate permissions. Avoid distributing a general administrator credential simply because it makes integration testing easier. Restrict data exports and log sensitive information sparingly. Integration records should include correlation identifiers and enough context for troubleshooting without copying private customer data into unrelated systems.

Upgrade testing is especially important when an extension changes financial posting indirectly. Imagine a custom subscriber that writes a project reference onto a sales invoice and then a new platform version changes the sequence of events around posting. A happy-path test that merely creates a document can pass while the reference disappears after partial posting or a background job. A more useful test suite checks draft creation, validation, posting, reversal, permission boundaries and reprocessing after a transient integration failure. It also confirms that a retry does not create duplicate external records. Where an extension imports data, the developer should define an idempotent key and a recovery procedure for rejected rows; otherwise fixing one failed batch may create a second financial event. Platform upgrades should therefore be rehearsed with representative transaction data in a sandbox before deployment, with explicit comparisons of posted records and customer-visible outputs.

Test extensions against upgrades and real workloads

AL test codeunits and repeatable test environments help verify behavior before deployment. Unit tests can validate focused calculations, while integration and business-process tests reveal what happens when custom code interacts with posting, permissions and batch operations. A happy-path test of one order does not establish that the extension works for partial shipments, corrections, cancellations or a large import.

A custom price calculation may pass a test for an ordinary item but fail for a credit memo or a foreign-currency customer. Construct cases using approved business examples and expected results. When a platform update changes standard behavior, regression tests should show whether the extension still preserves those expectations. If a new version requires a data migration, test it on representative historic records before publishing.

Performance can change sharply with record count. A procedure that performs a database lookup for every line may become slow during month-end processing. Inspect SQL patterns, record filtering and memory usage under realistic volume. A developer should know when to replace repeated queries with a more efficient design, without bypassing validation or producing a result that looks fast only because it omitted important checks.

Deliver through controlled lifecycle management

Source control, code review, automated builds and versioned app packages reduce risk when multiple developers work on extensions. A release should state compatible Business Central versions, dependencies, data migration effects and support expectations. AppSource and privately distributed applications have different distribution and review considerations. Whichever route is chosen, document the operations and permissions needed for installation and upgrade.

Consider a release that adds a new required field to a customer extension. Existing customers do not contain a value. Enforcing the requirement before migrating data may break routine transactions. Stage the rollout by introducing a compatible field, populating or validating historic records, updating integrations and tightening behavior only when the organization is ready. A technically successful deployment that leaves users unable to invoice is a failed release.

Observability should be designed into the feature. Support staff need to know which app version runs, what errors occurred and how to reproduce failures without privileged developer access to every tenant. Well-named telemetry and clear messages can reduce incident time; excessive logging may create privacy risk and storage cost. Choose signals according to the failure modes the extension can actually produce.

Study by building a small extension that survives stress

Build a warranty or purchasing extension with an AL table extension, a form field, a codeunit for business logic and a controlled API or event interaction. Include access restrictions, tests and a repeatable deployment. Then simulate a missing value in old data, two overlapping updates, a failed external service, and an update to the base application. For each, explain whether the extension can recover and what evidence a support engineer will see.

Compare the proposed customization against standard configuration. Sometimes the correct decision is not to create an extension at all; the platform already supports the process the business needs. MB-820 tests the judgment to know the difference and the technical depth to build safely when custom logic is justified.

Maintainability is the measure of a professional extension. Developers who can explain what changed, how it was tested and how it will behave during the next upgrade provide value long after the initial feature is delivered.