The industry is changing how Business Central solutions are built, especially as more organisations move from heavily customised NAV and on-premises deployments to cloud-first Microsoft Dynamics 365 Business Central extensions.
Modern Business Central developer training is therefore about learning how to design, build, test, package, and maintain AL extensions that survive upgrades. It is also about understanding how Business Central fits with APIs, Power Platform, reporting, source control, and the Microsoft certification path for developers who want to validate their skills through MB-820.
The role has become more disciplined than many legacy customisation projects required. A developer who previously changed base application objects in C/AL now needs to think in events, dependencies, permissions, test codeunits, and deployment rules. That change affects daily work: less direct modification, more extension design; less isolated coding, more lifecycle management; fewer one-off fixes, more upgrade-safe patterns that can be repeated across customers or tenants.
Why Business Central development training has changed
Business Central development used to be strongly associated with NAV customisations, C/AL, and partner-specific changes made close to the application core. That history still matters because many organisations run migrated solutions or have business processes shaped by older NAV designs. However, the skills needed for new development are different because Business Central SaaS depends on extension-based customisation and a controlled application lifecycle.
AL development in Visual Studio Code changes the developer’s mental model. Instead of editing standard objects directly, developers extend tables, pages, reports, and behaviour through extension objects and event subscribers. Training should therefore spend less time on general ERP concepts and more time on the patterns that keep extensions loosely coupled: integration events, business events, interfaces, permissions, API pages, dependency declarations, and automated tests.
This shift also changes project conversations. A requirement such as “add a new approval check before posting” should not immediately lead to a copied posting routine or a modified base process. A trained Business Central developer first looks for a suitable event publisher, checks whether the requirement belongs in an app-per-tenant extension or a reusable AppSource-style app, and considers how the change will behave during monthly service updates.
What the MB-820 developer path actually covers
MB-820 is the Microsoft Dynamics 365 Business Central Developer exam path. Microsoft Learn describes the assessed skills around AL development, Business Central architecture, extension design, testing, debugging, deployment, integration, and performance. The exam is not simply a syntax test; it expects developers to understand how AL solutions are built and operated in the Business Central environment.
There is a useful distinction between the functional and developer paths. MB-800 focuses on setup, configuration, finance and operations processes, and how Business Central is implemented for users. MB-820 focuses on AL code, extensions, events, APIs, testing, and deployment. Developers who mainly gather requirements and configure processes may be closer to the functional route, while those building extensions and integrations should prioritise the developer route; readers who recognise they are on the configuration path can compare it with the wider Microsoft training catalogue.
For developers who want a structured instructor-led route aligned to the developer exam, Readynez offers Microsoft Dynamics 365 Business Central Developer MB-820 training. The important point, regardless of provider, is that certification preparation should be connected to working code: creating extensions, debugging in VS Code, writing tests, exposing APIs, and deploying packages into realistic environments.
The practical development environment
A realistic training environment should resemble the conditions developers face on customer and partner projects. At minimum, that means Visual Studio Code with the AL Language extension, Git for version control, Docker for local containers where appropriate, and BCContainerHelper for creating Business Central development containers. Developers should also understand when containers are useful and when SaaS sandboxes are the better match for a target customer environment.
Version alignment is one of the first practical details to get right. A developer building for a Business Central 24.x SaaS tenant should not casually test against an unrelated local image, because platform and application changes can affect symbols, events, obsoletions, and API behaviour. Training environments should state their assumptions clearly: the target Business Central major version, whether the app is intended for SaaS or on-premises, and whether it depends on platform features introduced in a specific release.
BCContainerHelper is commonly used to create local containers for development and test automation, particularly when developers need repeatable environments. In practice, teams should choose image tags that match the target version as closely as possible, keep container setup scripts in the repository, and avoid hard-coding credentials in scripts or CI pipelines. Secrets belong in secure pipeline variables, secret stores, or local developer secret handling rather than committed configuration files.
Git is not optional on serious Business Central projects. A weak branching model can delay multi-tenant work because app-per-tenant fixes, reusable product features, release branches, and customer-specific hotfixes can become entangled. Even small teams benefit from a clear approach: protected main branches, short-lived feature branches, pull requests, versioned releases, and tags that match published app packages.
Core AL skills that matter in real projects
AL fundamentals include tables, pages, reports, queries, codeunits, enums, interfaces, permissions, and events. Yet the practical skill is knowing which object type is appropriate for a change and how to minimise coupling to the base application. A page extension that adds a field is straightforward; a posting-related change requires more care because it can affect transactions, performance, and upgrade behaviour.
Events are central to modern Business Central development. A developer should know how to find event publishers, subscribe to them, handle parameters safely, and avoid writing subscribers that create unexpected side effects. Over-customising by duplicating standard logic is a common mistake because it may appear faster at the start, but it creates brittle code that can break during upgrades or conflict with other extensions.
The following simplified AL example shows an event subscriber pattern. It is intentionally small: the purpose is to show the structure of an extension hook, not to prescribe a posting rule for every implementation.
Example — subscribing to a Business Central event in AL
codeunit 50120 "Sales Posting Guard"
{
[EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforePostSalesDoc', '', false, false)]
local procedure CheckCustomerReference(var SalesHeader: Record "Sales Header"; CommitIsSuppressed: Boolean; PreviewMode: Boolean)
begin
if PreviewMode then
exit;
if SalesHeader."External Document No." = '' then
Error('External Document No. must be provided before posting.');
end;
}
This pattern keeps the change outside the base application and makes the intent visible. In a production extension, the developer would also consider localisation, test coverage, whether the rule should be configurable, and whether the chosen event is stable enough for the intended lifecycle.
APIs and integrations require design discipline
Business Central APIs let developers connect the ERP system with portals, middleware, Power Platform, reporting tools, and external applications. Microsoft documents standard API endpoints and authentication patterns, but training should go beyond calling an endpoint successfully. Developers need to understand idempotency, pagination, throttling behaviour, data ownership, permissions, and the difference between standard APIs, custom API pages, OData web services, and integration events.
A common integration mistake is building chatty loops that call Business Central repeatedly for small units of work. That can create poor performance and brittle integrations, especially when external systems retry or when background jobs run during busy business periods. Better designs batch where appropriate, use set-based operations inside AL, reduce unnecessary round trips, and expose purpose-built API pages when a standard endpoint does not reflect the business process.
Hiring patterns increasingly reflect this wider integration reality. Small and mid-sized businesses, partners, and ISVs often value developers who can move across AL, Business Central APIs, Power Platform connectors, and basic Power BI modelling. The strongest project contributors are not necessarily those who know the most syntax; they are often the ones who can turn a finance, inventory, or service requirement into an extension, an integration, a tested release, and a reportable outcome.
A mini-scenario: from requirement to deployed extension
Consider a wholesaler that needs to prevent warehouse staff from posting sales shipments when a customer reference is missing. The requirement sounds small, but the implementation still needs careful design because it sits close to an operational posting process. A rushed change might duplicate posting logic or add validation in only one page, leaving API-driven or background posting paths uncovered.
A trained Business Central developer would begin by clarifying the business rule: which document types it applies to, whether exceptions are allowed, and whether the rule differs by customer group. The developer would then search for suitable events in the posting flow, create a focused AL codeunit, and add configuration if the rule should vary by company or customer. The solution should be committed to Git with a clear branch and reviewed before release.
Testing should follow the design rather than arrive at the end. Business Central supports automated test codeunits and test libraries, and Microsoft Learn includes material on AL testability. In this scenario, tests should cover the blocked posting case, the allowed posting case, preview posting if relevant, and any configuration-driven exception. Manual testing in the web client may still be useful, but it is not a replacement for repeatable automated tests.
Packaging and deployment complete the scenario. The app.json file should declare the application version, platform dependency, publisher, app name, and version in a way that supports future upgrades. For SaaS, deployment constraints differ from on-premises environments, and AppSource packages have additional validation and governance expectations. For app-per-tenant extensions, developers still need disciplined versioning and release notes because customers must understand what changed and how to roll back if necessary.
Testing, performance, and lifecycle management
Automated testing is one of the areas that separates experimental AL development from maintainable Business Central engineering. Skipping the AL Test Tool or leaving tests until after user acceptance testing often increases project risk because errors appear late, when business stakeholders expect a near-finished solution. Tests also protect upgrades by showing whether an extension still behaves correctly after a platform or application update.
Performance deserves the same attention. Business Central extensions can become slow when developers use record loops where queries would be more appropriate, perform repeated database calls inside nested loops, or trigger unnecessary page updates. In many cases, set-based operations, Query objects, background sessions for appropriate workloads, and careful filtering provide better results than procedural code that processes one record at a time.
Long-running operations should be profiled rather than guessed at. Developers should look at where time is spent, whether queries are selective, whether keys support common filters, and whether integration calls are being made synchronously when a queued or background pattern would be safer. Performance tuning is not a final polish step; it influences object design, data model decisions, and API boundaries.
Lifecycle management is equally important. Semantic versioning helps teams communicate the difference between fixes, compatible feature additions, and breaking changes. Dependency ranges should be chosen carefully so that extensions are neither locked unnecessarily to one version nor allowed to run against unsupported combinations. AppSource apps require particular care because breaking changes can affect many tenants, while app-per-tenant extensions still need governance to avoid customer-specific release chaos.
Common mistakes that delay Business Central projects
Several avoidable mistakes appear repeatedly in Business Central development work. They usually come from treating AL as a quick customisation language rather than as part of a managed cloud application lifecycle.
- Changing the design to copy standard logic instead of subscribing to suitable events, which increases upgrade risk and makes maintenance harder.
- Skipping automated tests because manual checks seem faster, which often moves defects into deployment or upgrade windows.
- Using weak Git practices, such as long-running shared branches or untagged releases, which makes customer fixes and product releases difficult to trace.
- Creating overly chatty integrations that make excessive API calls instead of batching, filtering, or designing purpose-built API pages.
- Ignoring versioning and dependency decisions until packaging, which can lead to avoidable deployment failures.
These mistakes are training issues as much as technical issues. Developers need hands-on practice with the tools, but they also need the judgement to recognise when a design will be hard to upgrade, hard to test, or hard to support across multiple tenants.
How to build a useful training plan
A good Business Central developer training plan starts with the platform architecture and then moves quickly into building. Developers should learn how extensions are structured, how symbols are downloaded, how launch.json connects to a sandbox or container, and how app.json controls identity, dependencies, and versioning. From there, training should progress into events, table and page extensions, reports, permissions, API pages, and test codeunits.
For NAV and C/AL developers, the most important transition is not simply learning new syntax. It is learning to stop thinking in terms of modifying the base application and start thinking in terms of extension boundaries. Existing knowledge of finance, inventory, warehousing, and posting processes remains valuable, but it must be applied through AL extension patterns that respect SaaS upgrade behaviour.
For .NET and JavaScript developers, the challenge is often different. They may understand APIs, source control, and automated testing well, but need to learn Business Central’s domain model, transaction patterns, permissions, and event-driven extension model. Their training should include enough functional context to avoid technically correct solutions that do not fit how users actually work.
Team leads should also consider how training continues after the first course or exam preparation period. Business Central receives regular updates, and developers need a habit of reading release plans, checking obsoletions, reviewing Microsoft Learn updates, and testing extensions against upcoming versions. Organisations with broader Microsoft upskilling needs may also consider ongoing Microsoft training access when multiple roles need recurring development and platform skills.
FAQ
Is MB-820 the right certification for a Business Central developer?
MB-820 is the relevant Microsoft certification path for developers who build Business Central extensions, integrations, tests, and deployment packages. Professionals focused mainly on configuration, finance setup, and business processes should compare it with the MB-800 functional consultant path.
Does a NAV C/AL developer need to relearn everything for AL?
No. Knowledge of NAV processes, posting routines, and customer requirements remains useful. The major change is architectural: modern work relies on AL extensions, events, source control, testing, and upgrade-safe design rather than direct base application modification.
Should developers train with containers or SaaS sandboxes?
Both can be useful. Containers are helpful for repeatable local development and automated testing, while SaaS sandboxes are often better for validating behaviour against the customer’s cloud environment. The target Business Central version should guide the choice.
Developing Business Central skills that survive upgrades
Business Central developer training should produce developers who can make safe design decisions, not just write AL syntax. The practical focus should be extensions, events, APIs, automated testing, performance, versioning, and deployment governance, because those are the skills that determine whether a solution remains reliable after the first release.
The most effective next step is to choose training that matches the work ahead: MB-820 preparation for developers building extensions, functional training for those configuring business processes, and continued practice in realistic environments. Readynez can support that route, and readers who want to discuss the most suitable path can contact the training team for guidance.
