Business Central development turns fragile operational workarounds, such as spreadsheet-driven approvals, into cloud-ready extensions that can survive monthly platform updates and move safely through sandbox testing before production. The valuable developer is more than an AL coder: they understand how Business Central is extended, tested, monitored, and maintained over time.
Microsoft Business Central development is the practice of extending Dynamics 365 Business Central with AL, Visual Studio Code, events, permission sets, integrations, tests, and deployment pipelines. In modern Business Central, especially cloud-first environments on recent versions such as Business Central 22 and later, strong developers work extension-first and avoid direct changes to the base application because unsupported customisations create upgrade, support, and maintenance problems.
Last updated: 2026. This guidance reflects the current AL and Extension v2 model used in Business Central online, while noting where on-premises environments may still require additional operational decisions around servers, containers, authentication, and release management.
What a Business Central Developer Actually Builds
A Business Central developer customises and extends the ERP platform so finance, operations, sales, purchasing, inventory, service, and reporting processes fit the business without breaking the upgrade path. That work may involve new tables, pages, reports, APIs, integrations, workflow logic, background processing, data migration, or small usability improvements that remove manual effort from daily operations.
The role sits between software engineering and ERP consulting. Developers need enough functional knowledge to understand postings, dimensions, number series, approvals, inventory movements, and document lifecycles, while also being able to design maintainable code. The strongest projects usually start with a clear business process discussion before any AL object is created.
There is also a commercial and deployment dimension. A developer may build an AppSource application intended for many customers, a per-tenant extension for one Business Central tenant, or a more controlled on-premises customisation where cloud restrictions do not apply in the same way. The choice matters early: AppSource work demands stricter packaging, validation, upgrade, and documentation discipline; per-tenant extensions allow customer-specific behaviour but still need clean event-driven design; on-premises work may provide more control but can increase the burden of infrastructure and upgrade responsibility.
Learn AL as an Extension Language, Not as Old NAV Development
AL is the language used to create Business Central extensions. A developer coming from C#, JavaScript, or older Dynamics NAV development should treat AL as a domain-specific language for ERP extension work, not as a general-purpose programming language. Its object model, database access patterns, events, permissions, and page/report concepts are tightly connected to how Business Central behaves.
The most important mindset shift is event-driven development. Rather than modifying Microsoft’s base application, developers subscribe to published events and add behaviour around standard processes. This approach improves upgrade resilience and makes it easier to isolate, test, and remove custom logic later.
The following simple example shows the shape of a common AL customisation. It subscribes to an event in a standard process and adds validation without editing the base application.
Example — AL event subscriber for customer validation
codeunit 50100 CustomerValidationSubscriber
{
[EventSubscriber(ObjectType::Table, Database::Customer, 'OnBeforeValidateEvent', 'Name', false, false)]
local procedure CheckCustomerName(var Rec: Record Customer; var xRec: Record Customer; CurrFieldNo: Integer)
begin
if StrLen(Rec.Name) < 3 then
Error('Customer name must contain at least three characters.');
end;
}
This example demonstrates the extension-first pattern: subscribe to an event, keep the logic small, and let the base application continue to own its standard behaviour. In production work, the developer would also consider localisation, data quality rules, test coverage, and whether the requirement belongs in validation logic, workflow configuration, or a separate approval process.
Permissions are part of the same discipline. A feature that compiles but cannot be used safely by the intended role is incomplete. Permission sets should be shipped with the extension so administrators can assign access deliberately rather than granting broad rights after go-live.
Build on the Right Development Environment
Most Business Central development work uses Visual Studio Code, the AL Language extension, Git, and a sandbox tenant or container-backed development environment. Cloud sandboxes are convenient for manual testing and customer review, while local containers created with bcContainerHelper can help developers reproduce versions, automate tests, and get quicker feedback before changes reach a shared environment.
Environment parity is one of the practical differences between hobby-level work and the habits expected from someone capable of performing effectively in the role. If code is only tested in a single shared sandbox, developers often discover version, dependency, or permission problems late. A container-based workflow can reduce that friction by creating repeatable environments aligned to the target Business Central version, especially when combined with scripted builds and automated tests.
On-premises Business Central adds more variables. Developers may need to understand service tiers, authentication, certificate handling, SQL Server administration, network access, and customer-specific deployment rules. Cloud development removes much of that server administration, but it makes supported extension patterns, API-based integration, and automated validation more important.
Use Source Control and CI/CD Before the Project Feels Large
Business Central projects become difficult to manage when source control and automated deployment are introduced late. A useful baseline is a Git repository with a clear app structure, branching rules, versioned dependencies, automated code analysis, and a repeatable package build. That applies even when the extension is small, because small ERP changes often become long-lived production assets.
A practical CI/CD flow for AL usually builds the app, runs code analysis, creates the package, runs tests in a controlled environment, and publishes to a sandbox for review. Teams using Azure DevOps or GitHub Actions can call PowerShell and bcContainerHelper scripts to create environments and run the same steps repeatedly. The exact implementation depends on the tenant, licensing, authentication model, and release governance, so secrets should be stored in the pipeline’s secure secret store rather than in AL code, YAML files, or repository variables exposed to contributors.
The following simplified GitHub Actions example shows the idea rather than a complete production pipeline. It assumes the build script handles container creation, dependency installation, compilation, and test execution using secure pipeline configuration.
Example — GitHub Actions job calling a Business Central build script
name: business-central-extension-build
on:
pull_request:
branches: [ main ]
jobs:
build-and-test:
runs-on: windows-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Build and test AL extension
shell: pwsh
run: ./build/Build-BusinessCentralApp.ps1 -AppProjectPath './src' -RunTests
The learning takeaway is that a Business Central developer should be comfortable with more than AL syntax. Hiring teams often look for evidence that a candidate can work safely in a team: pull requests, repeatable builds, automated checks, and deployment to sandboxes without manual packaging surprises.
Write Tests That Protect Business Processes
Testing in Business Central should be tied to the business process being changed. The AL Test Tool and test codeunits allow developers to create repeatable checks for posting logic, validations, integration behaviour, permissions, and upgrade scenarios. Good tests make future refactoring safer because they confirm that important ERP outcomes still hold after a platform update or extension change.
New developers commonly write code that works for one demo record but fails when master data, permissions, posting setup, or number series differ. A better test pattern creates the necessary fixture data, runs the operation, and asserts the business result. That habit is especially important in ERP systems, where a small validation change can affect invoicing, stock, or month-end routines.
Upgrade codeunits deserve separate attention. When an extension changes table structures or moves data, upgrade logic should preserve existing customer data across versions. Developers who can show tested upgrade routines in a portfolio demonstrate that they understand production software, not only first-time installation.
Use Code Analysis, AppSource Rules, and Clean Permissions
AL projects should use rule sets and Microsoft’s code analysers, including CodeCop and AppSourceCop where appropriate. Code analysis is not a replacement for review, but it catches patterns that lead to maintainability, naming, packaging, or marketplace validation issues. AppSource-targeted extensions need stricter discipline than a private per-tenant extension because they must be suitable for repeated installation and upgrade across different customers.
A compact set of common mistakes explains why these checks matter:
- Bringing NAV habits into Business Central by looking for base-code changes instead of events and subscribers.
- Relying on broad permissions during testing and forgetting to ship a usable permission set with the extension.
- Skipping automated tests because the customisation appears small, even when it affects posting, approvals, or data migration.
- Writing inefficient record loops instead of filtering records, using suitable keys, and loading only the fields needed.
Each mistake has a practical fix: design around Extension v2, make permissions part of the feature, test the business outcome, and review database access patterns before performance issues appear in production.
Understand Integration Patterns Across Dynamics 365 and Microsoft Services
Business Central rarely operates alone. Many implementations connect with Power Platform, Dataverse, Microsoft 365, Azure services, e-commerce systems, warehouse applications, payment services, or reporting platforms. A developer does not need to specialise in every integration tool at once, but should understand APIs, authentication, data mapping, error handling, retry behaviour, and ownership of the source of truth.
Integration work is where ERP knowledge becomes visible. A technically valid integration can still fail if it ignores posting rules, dimensions, tax logic, currency handling, or reconciliation. Strong developers ask what should happen when a downstream system is unavailable, whether records should be created immediately or staged for review, and how failed messages will be diagnosed by support teams.
Microsoft Learn and Microsoft documentation remain important references for object types, AL syntax, testability, APIs, and telemetry concepts. Community repositories and technical blogs can also be valuable, but snippets should be reviewed against the current Business Central version and the project’s security requirements before being reused.
Learn Telemetry and Performance Early
Operational skill separates maintainable Business Central development from code that only works during testing. Business Central online can emit telemetry to Application Insights, giving teams a way to investigate errors, long-running operations, extension behaviour, and performance signals. Developers who can read telemetry are better prepared to support production systems after go-live.
Kusto Query Language, commonly called KQL, is used to query Application Insights data. The exact table names and dimensions available depend on the telemetry configuration, but the habit is what matters: look for failing operations, correlate events by time and tenant context, and use evidence before changing code.
Example — KQL query for recent Business Central errors
traces
| where timestamp > ago(24h)
| where severityLevel >= 3
| project timestamp, message, operation_Name, customDimensions
| order by timestamp desc
This starter query helps a developer inspect recent high-severity trace entries. In a real support workflow, the next step would be to filter by extension, user session, operation, or correlation identifier so the team can connect a symptom to a specific feature or deployment.
Performance also begins in the AL code itself. Developers should filter records before looping, use appropriate keys, load only needed fields with patterns such as SetLoadFields, and avoid holding locks longer than necessary. Background sessions can help with suitable long-running work, but they should be designed with clear error handling and user feedback rather than used as a way to hide slow processing.
Create a Portfolio That Looks Like Real Work
A hiring-ready portfolio should show how the developer thinks, not only that an extension compiles. A useful project might include a small approval enhancement, a posted-document validation, an integration with an external staging table, a report extension, and an upgrade scenario. The repository should contain readable AL code, tests, a permission set, a short setup guide, and evidence of a repeatable build.
Good portfolio projects explain trade-offs. For example, a README can describe why the developer used an event subscriber instead of page customisation, how test data is created, what permissions are required, and how telemetry would be used after deployment. That context helps a reviewer see whether the candidate understands production consequences.
Contributing to community discussions can also help, provided the focus remains practical. Answering a narrow AL question clearly, reporting a documentation issue, or publishing a small reproducible example often demonstrates better judgement than sharing a large unfinished extension with no tests or explanation.
Use Certification and Structured Training as a Skills Map
Formal learning is useful when it connects directly to hands-on development. The Microsoft Dynamics 365 Business Central Developer certification path, including exam MB-820, provides a structure for topics such as AL development, extension architecture, integration, and deployment. It should be treated as a map for building capability rather than a substitute for project experience.
Readynez offers an MB-820 Microsoft Dynamics 365 Business Central Developer course for learners who want guided preparation around the developer role. Readers comparing options may also find the broader Microsoft training catalogue useful when Business Central work overlaps with Azure, Power Platform, or Microsoft 365 integration skills.
The important point is sequencing. A developer should combine study with a working extension, source control, tests, and a deployment pipeline. Certification can validate knowledge, but employers and project teams still need to see whether the developer can reason through requirements, protect data, and support code after release.
Building a Career Roadmap That Holds Up in Real Projects
The strongest roadmap starts with AL fundamentals, then moves into extension design, events, permissions, testing, CI/CD, integration, telemetry, and performance. Each stage should produce something tangible: a small extension, a test suite, a pipeline, a telemetry query, or a documented upgrade routine. This creates evidence of judgement as well as technical skill.
Readynez can support the structured learning part of that journey through Unlimited Microsoft Training, particularly for developers building skills across Business Central and adjacent Microsoft technologies. A practical next step is to choose one realistic Business Central problem, build it as an extension with tests and source control, and use the contact page if a conversation about training direction would help.
FAQ
What skills are most important for a Microsoft Business Central developer?
The core skills are AL programming, extension design, event subscribers, table and page objects, permissions, integrations, testing, debugging, and source control. Developers also need enough ERP understanding to work safely with posting routines, dimensions, approvals, inventory, and financial data.
Should a new Business Central developer learn C/AL or AL?
New developers should focus on AL and the modern extension model. Older C/AL and NAV knowledge may help when reading legacy systems, but current Business Central cloud development is based on AL, Visual Studio Code, events, and extensions.
How can someone practise Business Central development without a large project?
A good practice project can be small but complete. For example, a developer could build a validation extension, add a permission set, write tests, create a GitHub Actions build, and document how the extension is installed and upgraded. That kind of project demonstrates realistic habits better than a large amount of untested code.
Is MB-820 useful for becoming a Business Central developer?
MB-820 is useful as a structured way to align learning with the Business Central developer role. It should be combined with hands-on AL projects, testing, debugging, CI/CD practice, and review of Microsoft documentation for the current platform version.
What common challenges do Business Central developers face?
Common challenges include choosing the right extension approach, handling upgrades, managing permissions, writing reliable tests, integrating with external systems, and diagnosing production issues through telemetry. These challenges are easier to manage when the project uses source control, code analysis, automated tests, and clear deployment environments from the beginning.
