BCApps: the single open repository behind Business Central

From several private repositories to one open one

BCApps is described as the single open collaboration hub for Business Central application platform development, and the README is blunt about the direction of travel: code that used to live in several separate repositories now lives in one place. The stated contents are the System Application, the Business Foundation, the Base Application, Microsoft's first-party apps including E-Documents, the Shopify connector, Subscription Billing and Power BI reports, and the developer tools such as the Test Framework, Performance Toolkit and AI Test Toolkit.

The audience is broader than the Microsoft product team. The README describes Microsoft engineers, partners and community contributors working side by side on the same code, with the same pipelines and the same tooling, and it makes the governance point that GitHub is intended to become Business Central's business application collaboration platform. In practice that means an extension partner can read the platform code they build against, and a community contributor can propose a change with the same review path Microsoft engineers use.

One repository also means one issues list, and the README treats that consolidation as a feature rather than a side effect. It is worth separating the collaboration promise from the support promise, because the repository does not carry the second one.

Everything under src, split by application area and market

All source lives under src, organized by application area, with a convention that anything shipping in multiple localizations splits into a W1 worldwide base plus per-market folders such as DE, US or GB. The table in the README maps the layout: src/System Application holds the platform layer, src/Business Foundation holds business logic shared across the application, src/Layers holds the Base Application and the Application layers built per country and region, src/Apps holds the first-party apps in the same W1 plus localization split, and src/GDL holds additional country-specific application content.

The tooling sits alongside them. src/Tools carries the Test Framework, Performance Toolkit, AI Test Toolkit and Red Team Scan, src/DemoTool generates Business Central demonstration data, src/DisabledTests holds test apps that are temporarily disabled, and src/rulesets holds the code-analysis rulesets used when building the apps.

The W1 convention is the detail that trips up newcomers. A change to a base application behavior often needs a matching decision about every localization, and the per-market folders make the blast radius of a change visible before you touch anything. The disabled tests directory is equally informative: some test apps are switched off on purpose, so a missing or failing test is not automatically a broken build.

Build orchestration sits in build/ and build.ps1

Outside src, the build story is documented in two places. The build directory holds build orchestration, where build/projects defines the AL-Go projects and build/scripts holds the supporting automation, and build.ps1 builds the repository locally. A .devcontainer directory at the top level and a LOCAL_DEV_ENV.md file point to a containerised local development setup.

The automation is not homegrown. The README states that BCApps runs on AL-Go for GitHub, and that the same build, test and release automation is available to everyone. That is the single most useful sentence for an outside contributor, because it means the CI pipeline a partner runs on their own extension is the same machinery the product runs on. Anything the repository does to build, test and release the product is therefore reproducible outside Microsoft's own tenancy, subject to the AL-Go licensing and setup, which the repository links rather than re-explains.

The local build entry point is a single PowerShell script at the repository root, build.ps1, and the README does not list its parameters, so the documented expectation is simply that it builds the repository locally. For an engineer evaluating the repository, the practical first question is how large the local build is. The README does not give a build time or a minimum machine specification, and the structure of the tree, with a platform layer, a base application and per-market localizations, suggests a substantial one. Build locally with build.ps1 before assuming a change is small.

Every pull request needs an approved issue first

The contribution process has a hard ordering rule. The README states that every contribution needs an approved GitHub issue before a pull request is opened, and explains the reason plainly: it saves you from writing code that cannot be accepted. The full process is described in CONTRIBUTING.md, and LOCAL_DEV_ENV.md covers building and validating changes locally.

That is a meaningful constraint for anyone planning to contribute at volume, and it is the opposite of the usual open source flow where you open a pull request and let a maintainer sort it out. A team with several extensions against the same platform area now has a serialisation point in the issue tracker rather than in the review queue.

The repository also has the usual governance files at the root, including CODEOWNERS, CODE_OF_CONDUCT.md, SECURITY.md and SUPPORT.md, plus .github and .azuredevops directories, which is consistent with a repository where contributions are routed by area.

Not a support channel: the SLA warning in the README

One passage in the README is more emphatic than the rest, and it is the one that protects you from a mistake. The repository is not the right place to report product defects with customer impact to Microsoft. Issues created there might not be picked up by the Microsoft engineering team, do not fall under SLAs, have no guaranteed time to mitigation, and provided fixes will not be backported to all supported versions of the product. For customer-impacting defects the README points to the technical support documentation for Dynamics 365 Business Central.

Read that as a routing rule rather than a warning about quality. The BCApps issue tracker is a development tracker for the platform itself, and a support ticket filed in the wrong place can sit without a guaranteed response while a customer waits. A partner running a production environment needs both paths open: the BCApps tracker for platform behaviour and extensibility, Microsoft support for anything with customer impact.

The same separation appears in the extensibility requests section. Requests to add integration events, change function visibility, or replace an option with an extensible enum are handled in BCApps, which makes the repository a genuine channel for shaping the platform rather than only a place to read its source.

Agents are already inside the CI pipeline

The repository documents a code review agent that it calls a Copilot for PRs, already running in the BCApps CI pipeline. It inspects pull requests, posts review comments, and runs quality checks against shared best practices, and its documentation lives under tools/Code Review alongside other repository-level agent tooling and developer plugins.

The knowledge behind those checks is separate and open. BCQuality is described as an open, agent-consumable knowledge base of Business Central best practices, patterns and guidelines, and it is layered into Microsoft, Community and Custom tiers so partners can extend and override the rules the agents follow. The Copilot reviewer consumes it through the integration under tools/Code Review.

The stated direction is for this agent framework to ship as part of AL-Go for GitHub, so that any partner pipeline can opt into agents configured through BCQuality. That is a plan, not a shipped feature, and the README describes it in the future tense. What exists today is the review agent in this repository's own pipeline, and BCQuality as a standalone repository you can read or extend on its own.

MIT licensing, and what the repository does not tell you

The source code in BCApps is available to everyone under the standard MIT licence, with the LICENSE file at the repository root. That is unusually broad for a vendor product repository, and it means the platform code can be read, referenced and, within the terms, reused, subject to the usual attribution and notice requirements. This is a licensing statement, not legal advice, and any specific use should be checked against the actual LICENSE file.

There are gaps a reader should know about rather than discover later. The README does not document a rollback procedure for the many releases, and the release history shows why that would matter: three of the recent releases are StrictMode updates for successive versions, 29.0 for the 2026 Release Wave 2 on 2026-10-02, 28.5 for Release Wave 1 on 2026-09-07, and 28.4 for Release Wave 1 on 2026-08-07. The naming pattern shows a release train tied to product versions, and a StrictMode entry in particular suggests a change in how the AL compiler treats certain code, which is the kind of change that can affect extensions built on older object versions.

The last push to the repository was on 2026-10-20, and the repository is not archived, so the release cadence you see in that list is the current one.

Editorial conclusion

Use BCApps if you build Business Central extensions and want to see, or propose changes to, the same code, pipelines and tooling Microsoft uses, and if you need an extensibility request answered by the product team. Do not file customer-impacting defects there, because issues in that repository fall outside SLAs and fixes are not guaranteed to be backported across supported product versions; use the Dynamics 365 Business Central technical support path for that. Before you open a pull request, read CONTRIBUTING.md and LOCAL_DEV_ENV.md, get an approved GitHub issue in place first, and confirm that your change builds locally with build.ps1, since the repository is large and the submission process expects that evidence.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/BCApps on GitHub
3. Project website
4. README
5. Releases