Business Central development services: extensions, integrations and reports

What our Business Central development service covers

We build extensions, integrations, APIs and reports. An extension can be one event subscriber or a full module with tables and pages for a process the standard product does not model. An integration links Business Central to your web store, CRM or bank. A custom API lets another system read or write data. Report work adds the layouts and datasets your team needs.

It also includes the work around the code. That means data upgrade routines when a table changes, and permission sets for new objects. It means translation files where users work in more than one language. It also means telemetry that shows how the extension behaves in production. These are easy to forget and costly to add later.

How we build and test the code

Our developers build and test in a sandbox, never in your live company. Each project gets its own sandbox, so one change does not disturb another. When a fault shows only in another environment, we use snapshot debugging to replay that session. You can see the work at each stage.

We keep code in Git and build it in a pipeline. The pipeline compiles against the current and the next Business Central version. The standard code analyzers run on every commit, so they catch rule violations before a person reads the change. A second developer reads every pull request before it merges.

Business Central development with automated tests

Every meaningful rule in an extension gets a test codeunit. Tests create their own data and run the logic. Then they check the ledger entries or field values that result. They run in the pipeline. So a later change that breaks an earlier rule fails the build.

Page scripting is a tool built into the web client. It lets your own key users record and replay acceptance tests without writing code. We combine both. Developers own the unit tests, and process owners own the recorded scenarios. Between them, the code and the process are both covered before release.

From sandbox to production in Business Central development

You deploy a finished extension as a per-tenant extension through the Extension Management page. If it is a product for many customers, you publish it to Microsoft's marketplace. Per-tenant deployment is the usual route for work written for one company. We advise on which route fits before we write any code.

Releases follow a version number and a change log. We install in a sandbox copy of production first and run the data upgrade. Then we confirm the result with a key user. After that, we schedule the production install for a time when few people are posting. We write a rollback plan for every release.

Business Central development traps worth avoiding

Slow code is the most frequent complaint. It often comes from loops that read records one at a time. Missing keys and flow fields on long lists cause it too. We write set-based code and load only the fields we need. Then we check the result with the in-client performance profiler.

The second trap is relying on objects that Microsoft has marked obsolete. Compiler warnings announce removals well ahead of time. We treat those warnings as work items. So an extension never blocks a tenant from getting an update. We read the release plans for each wave and plan the changes early.

Business Central development questions

What do you build in Business Central development projects?

We build extensions that add fields, pages and logic, integrations with other systems, custom APIs and report layouts. All of it is written in AL, Microsoft's language for Business Central, and installed as extensions. Because extensions sit beside Microsoft's code, updates can arrive without overwriting your custom work.

Can old C/AL modifications be converted to AL?

Yes. We move old C/AL modifications into AL extensions and drop changes that nobody uses any more. Our C/AL to AL conversion page explains that work in detail. The new code is smaller and easier to keep.

Do you build integrations as part of development?

Yes. Business Central exposes standard REST APIs. We write custom API pages when another system needs data that the standard ones do not carry. For simple triggers, a Power Automate flow with the Business Central connector may be enough, with no code. We pick the lightest tool that does the job.

Who holds the source code during a project?

The repository can sit in your own account from the first commit. Our developers get access to it. That way you always hold the current code, the history and the pipeline definition. Nothing has to be handed over at the end. You can also change partners later without losing any Business Central development work.

Can you work alongside our in-house developer?

Yes. We agree on branching rules, coding conventions and who approves pull requests. Shared work goes through the same pipeline and analyzers. So the code reads as one body of work, whoever wrote a given line. Your developer keeps the knowledge, and we add extra hands when you need them.

Related development services

Development sits between a business requirement and a running system. The pages below cover the neighboring work: lighter changes, packaged extensions, APIs and the consultants who write them. Read them to see where Business Central development fits in your plan. Then we can talk through your requirement and choose the simplest way to build it. For the product detail, see Development in AL for Business Central.