Business Central AL Development: Extensions, Apps and Integrations

What does AL extension development for Business Central actually involve?

An AL extension is an app that adds to Dynamics 365 Business Central without editing the standard application. It is written in AL with the AL Language extension for Visual Studio Code, compiled into an app file, and installed into an environment like any other app. The building blocks are objects: table extensions that add fields to standard tables such as Customer or Sales Header, page extensions that put those fields on screen, new tables and pages for data the standard product has no home for, codeunits that hold business logic, reports and report layouts, API pages that expose data to other systems, and permission sets that decide who can use all of it.

The part that makes extensions maintainable is how they attach to standard behaviour. Instead of changing the posting routine, an extension subscribes to the events the standard code raises before and after it does its work, and runs its own logic there. The standard application stays standard, your logic stays in your app, and an update to the base application replaces Microsoft code without touching yours. That separation is the whole point, and an extension that tries to work around it (copying standard objects to change them, or bypassing the events) is the one that hurts on every update.

In practice the requests we see fall into a few shapes: a field and a rule the business needs on every sales order, an approval or check before posting, a document layout that matches how the company actually invoices, an integration with a bank, a web shop, a warehouse system or a CRM, and occasionally a full vertical solution packaged as an app for other Business Central customers.

• Table and page extensions: new fields, actions and fact boxes on standard Business Central screens.
• Business logic in codeunits, attached to standard processes through event subscribers.
• New tables, pages and setup screens for processes the standard application does not model.
• Reports and document layouts, including the sales and purchase documents customers and suppliers see.
• API pages and outbound integrations, covered in their own section below.
• Permission sets, upgrade code and installation code, so the app can be assigned, updated and installed cleanly.

How does Solzet build and ship an AL extension?

Every engagement starts with a written specification: the business process, the screens and fields, the rules, the events we plan to subscribe to, the data the extension adds, and the acceptance tests the business will sign off. It is short, plain and reviewed by the person who owns the process, because the easiest bug to fix in AL, as in any language, is the one caught while it is still a sentence.

Development happens in Visual Studio Code against a Business Central sandbox environment, never against production. The code lives in a Git repository you own from the first commit. Every object carries a prefix so it cannot collide with Microsoft objects or other apps, the code analyzers that ship with the AL Language extension run on every build, and automated tests in AL test codeunits cover the logic that matters: the calculations, the validations and the posting behaviour. Each release gets a new version number in the app manifest, so you always know which build is installed where, and a release moves from sandbox to production through a documented, repeatable procedure rather than someone uploading a file on a Friday evening.

We keep extensions small and focused. One app per business capability, with clear dependencies between them, is easier to test, update and retire than one large app that holds every customisation the company has ever asked for.

• A written specification, signed off before build, with acceptance tests per requirement.
• Source code in your Git repository, with the build reproducible from a clean checkout.
• Automated tests in AL test codeunits for calculations, validations and posting logic.
• Code analyzer warnings resolved, not suppressed, before each release.
• A versioned app per release, with upgrade code where data structures change.
• Release notes and a documented deployment procedure from sandbox to production.
• Handover documentation: what each object does, which events it subscribes to, its setup, and how to rebuild and redeploy it.

What does a well-built Business Central extension look like in code?

Two small examples show the pattern we follow. The first adds a credit hold flag to the Customer table and stops a sales document from posting while the flag is set. It does not copy or edit the posting routine: it subscribes to the event the standard posting codeunit raises before posting and raises an error there, with a translatable message. The second exposes the same data through a custom API page, so a CRM or a web shop can read and update the flag with an authenticated call instead of a nightly file.

Neither example is clever, and that is deliberate. Code that a different AL developer can read in five minutes, find the event it hooks into, and test in a sandbox is code that survives updates and staff changes. The object numbers and the SZ prefix are illustrative; on a real project they come from the ID range and prefix agreed for your app.

tableextension 50100 "SZ Customer Ext" extends Customer
  {
      fields
      {
          field(50100; "SZ Credit Hold"; Boolean)
          {
              Caption = 'Credit Hold';
              DataClassification = CustomerContent;
          }
      }
  }

  codeunit 50101 "SZ Sales Credit Check"
  {
      [EventSubscriber(ObjectType::Codeunit, Codeunit::"Sales-Post", 'OnBeforePostSalesDoc', '', false, false)]
      local procedure CheckCreditHold(var SalesHeader: Record "Sales Header")
      var
          Customer: Record Customer;
          CreditHoldErr: Label 'Customer %1 is on credit hold. Release the hold before posting.', Comment = '%1 = customer number';
      begin
          if Customer.Get(SalesHeader."Sell-to Customer No.") then
              if Customer."SZ Credit Hold" then
                  Error(CreditHoldErr, Customer."No.");
      end;
  }

page 50102 "SZ Credit Hold API"
  {
      PageType = API;
      APIPublisher = 'solzet';
      APIGroup = 'sales';
      APIVersion = 'v1.0';
      EntityName = 'creditHold';
      EntitySetName = 'creditHolds';
      SourceTable = Customer;
      ODataKeyFields = SystemId;
      DelayedInsert = true;
      InsertAllowed = false;
      DeleteAllowed = false;

      layout
      {
          area(Content)
          {
              repeater(Records)
              {
                  field(id; Rec.SystemId) { Editable = false; }
                  field(number; Rec."No.") { Editable = false; }
                  field(displayName; Rec.Name) { Editable = false; }
                  field(creditHold; Rec."SZ Credit Hold") { }
              }
          }
      }
  }

How do you build an app for Microsoft Marketplace (AppSource)?

An app for Microsoft Marketplace (AppSource) is an AL extension written for many Business Central customers instead of one, and that changes the engineering more than the code. Nothing can be hard-coded for a single company: every behaviour that differs between customers becomes setup, every caption becomes a translatable label, every object carries the publisher prefix, permissions are explicit, and installation and upgrade code has to work on tenants you will never see. Business Central extensions submitted to the marketplace are validated with the AppSourceCop analyzer, so we run it from the first build rather than discovering its findings the week before submission.

Solzet builds the app, the automated tests, the upgrade path between versions and the technical documentation the submission needs, and prepares the package for submission. You stay the publisher: the listing, the commercial terms and the customer relationship are yours. For software vendors without in-house AL developers we can also maintain the app afterwards, keeping it compatible as Business Central updates and releasing new versions through the same pipeline.

• Product design for many tenants: setup tables, feature switches and sensible defaults instead of customer-specific code.
• AppSourceCop and the other AL code analyzers enabled from day one, with findings fixed as they appear.
• Translatable labels throughout, and the translation files your markets need.
• Install and upgrade codeunits tested against a previous version of the app, so existing customers upgrade cleanly.
• Permission sets that match the roles in the app, so customers can assign access without guesswork.
• Technical documentation, a test record and a submission-ready package, with you as publisher.

How do Business Central integrations and APIs work?

Business Central exposes a standard REST API (API v2.0) for the common entities such as customers, vendors, items, sales orders and invoices. When the standard API covers the data, we use it, because Microsoft maintains it and there is nothing extra to own. When it does not, we build custom API pages like the example above, versioned and published under your own API group, so the other system gets exactly the fields and actions it needs and nothing else. For outbound calls, where Business Central has to push data to a bank, a logistics provider, a tax service or a web shop, the extension calls the external service from AL with proper error handling, retries and a log table someone can actually read when a call fails.

Integration with Dynamics 365 Customer Engagement is its own topic. Business Central connects to Dataverse through the Set up Dataverse connection assisted setup, with one-way or two-way synchronization, and that connection is the route for integrating with Dynamics 365 Sales. The Business Central Virtual Table app exposes Business Central data in Dataverse as virtual tables without copying it, and custom APIs can be exposed the same way. Which of the two fits depends on whether CRM users need a synchronized copy of the data or a live view of it. Our CRM and ERP integration service covers that design end to end, and on the CRM side the same team builds Dynamics 365 Customer Engagement, so one design governs both systems and the data flow between them.

• Standard API v2.0 used wherever it covers the data, so there is less custom code to maintain.
• Custom API pages, versioned under your own API group, for the data and actions the standard API does not expose.
• Outbound integrations from AL with error handling, retry logic and a readable integration log.
• Authentication through registered applications for service-to-service access, never shared user passwords.
• Dataverse connection and Sales integration, or Business Central virtual tables in Dataverse, designed with the CRM side.

How do you turn old Dynamics NAV customisations into extensions?

Older Dynamics NAV solutions were often customised by changing the standard application code directly. Moving to Business Central online means that logic has to live in extensions, and the move is the right moment to ask, for every customisation, whether it is still needed at all. We inventory the modifications in the NAV database, trace each one to the business process and the people who use it, and sort it into one of three outcomes: the standard Business Central application now does it, so the customisation is retired; it is still needed, so it is rebuilt as an AL extension that subscribes to events; or nobody can name a current need, so it is confirmed with the business owner and dropped.

The rebuild is cleaner than a line-by-line port, because code written to change the old base application rarely maps one to one onto events, and copying it forward keeps every old shortcut. Custom tables and their data are carried across so history is preserved. The code work runs alongside the data migration: Dynamics NAV customers upgrade to Business Central on-premises first and then switch to Business Central online with the cloud migration tool, and the rebuilt extensions have to be ready at the right point in that sequence. The full migration, from the path for your NAV version to cutover and reconciliation, is on our migration to Business Central page.

Can Microsoft partners use Solzet for white-label AL capacity?

Yes. Solzet delivers Business Central and Finance and Operations capacity for Microsoft partners on a white-label basis: AL and X++ developers and consultants who work inside your delivery process. For Business Central that means AL developers who take a specification from your consultants, work in your repository and your branching model, follow your coding standards and prefix, attend your stand-ups if you want them to, and release through your pipeline. Your client sees your brand; the work is delivered by Solzet under your direction.

Partners usually bring us in for one of three reasons: a peak where the backlog outgrows the bench, a skills gap such as APIs or app packaging, or a NAV customer whose customisations need rebuilding as extensions before the move to online. Engagement models, confidentiality and how the hand-offs work are on the white-label Dynamics 365 subcontracting page, which covers Customer Engagement, Power Platform, Business Central and Finance and Operations capacity under one agreement.

Who is this for, and who is it not for?

This service is for companies already on Business Central that need behaviour the standard application and its setup do not provide, for Dynamics NAV customers whose customisations must become extensions before they move to Business Central online, for software vendors building an app for Microsoft Marketplace (AppSource), and for Microsoft partners who need AL capacity under their own brand. It is also for anyone who has inherited extensions with no source code, no tests and no documentation and wants an assessment and a stabilisation plan before the next update.

It is the wrong starting point in three cases. If the requirement can be met by setup or by an app that is already on the marketplace, we will tell you during the specification, because the cheapest extension is the one that never gets written. If you are implementing Business Central from scratch, start with the Business Central implementation page: extensions are one part of that project, not the project. And if your organization is larger and more complex, your ERP may be Finance and Operations, where extension work is X++ rather than AL; see Finance and Operations and the comparison below.