Every implementation eventually meets a workflow the standard product doesn't quite cover, or a system it was never going to talk to on its own: an e-commerce platform, a bank feed, an EDI trading partner, a piece of shop-floor equipment. We build custom AL extensions and Azure-based system integrations to close those gaps — using Microsoft's supported extension model and standard integration patterns, so the fix survives every upgrade after it ships.
Most of what looks like "an ERP problem" is actually a gap at the edge of the ERP — a process it doesn't model, or a system it doesn't automatically talk to. Both show up the same way: someone re-keying data that should have arrived on its own, or working around a step Business Central was never configured to handle.
Older Dynamics NAV customizations worked by editing the base application's source code directly — powerful, but it meant every new version had to be manually re-merged against every customization before it could be applied, a job that got more expensive and more fragile every year. Business Central replaced that model with AL extensions: independent packages of code that layer new fields, logic, pages, and integrations on top of the standard application without altering a single line of it. Microsoft validates the extension platform against every release, so code written against it keeps working release after release.
Extensions attach to Business Central through defined extension points rather than modifying base objects, so a Microsoft platform update cannot silently overwrite your customization — or the other way around.
Every extension we build lives in a proper repository with a change history, and ships with automated tests that run against each new Business Central release before we let you touch it — not just at the point we hand it over.
No bundled feature set to license or maintain. An extension does one job — validate an address, drive a scanner, calculate a local tax — with a surface area small enough to review, test, and support with confidence.
Alongside extension work, we build and maintain the integrations that connect Business Central to the rest of your operating environment: e-commerce platforms, banking feeds, EDI trading partners, shipping carriers, and the other line-of-business tools your team already runs. We build these on Azure's integration and messaging services, using API-based patterns wherever the other system supports them, so each connection is monitored and recoverable rather than a fragile script someone has to babysit.
E-commerce platforms, bank statement feeds, EDI trading partners, and shipping carriers connected directly into Business Central, so orders, payments, and shipments arrive as transactions instead of a spreadsheet someone re-types.
Logic Apps, Service Bus, Functions, and API Management as the layer between Business Central and everything else — so an integration is logged, retried on failure, and alerted on when it breaks, not silently dropping data.
The same integration discipline links Business Central to Dynamics 365 CRM and the broader Power Platform, so sales, service, and automation run against the same data instead of a separate copy of it.
E-commerce, banking, EDI partners, carriers, shop-floor equipment
Logic Apps, Service Bus, Functions, API Management — logged and monitored
System of record — orders, ledgers, inventory, production
Automation, apps, and reporting built on the same connected data
Integration work is where this pillar meets two other parts of our practice: automating the processes around Business Central through Power Platform, and turning the resulting data into dashboards through our Power BI & Analytics work. For how we implement and support Business Central itself, see Business Central Implementation, or browse our broader Expertise & Technology.
The examples below are illustrative of the categories of work we take on — every engagement is scoped to the client's actual process, not sold off a shelf. If your gap looks like one of these, or nothing like any of them, the starting point is the same conversation.
A handheld-scanner interface for receiving, put-away, picking, and cycle counts that writes straight into Business Central inventory in real time, instead of a paper sheet keyed in at the end of the shift. Worth building once pick errors, stock discrepancies, or count time are costing you more than an implementation would.
Standardizes and verifies customer and vendor addresses at the point of entry, catching typos and incomplete records before they cause a failed delivery or a bounced EDI transaction. A common need for businesses shipping physical goods across multiple countries or carriers.
A simplified, touchscreen-friendly front end for machine operators to report job progress, downtime, and scrap against production orders, without giving them the full Business Central client. Fits manufacturers who need floor-level data but don't want to license or train every operator on the core system.
Calculates and reports a jurisdiction-specific withholding or transaction tax that Business Central's standard localization doesn't model correctly out of the box. Typical for businesses operating in a market with tax rules that fall outside Microsoft's core localization for that country.
Connects Business Central directly to shop-floor equipment — PLCs, sensors, or an existing SCADA layer — so machine-generated data (run counts, cycle times, fault codes) flows into production orders and maintenance records automatically. Useful once "check the machine" is a manual step in someone's daily routine.
Generates and scans QR or barcode labels at each stage of a production routing, giving full genealogy and traceability from raw material to finished, shippable unit. Common in regulated or quality-critical manufacturing where a recall or audit needs to trace a lot number back to its inputs.
Have a workflow — or a system — that doesn't match any category above? Most of what we build starts as a one-off problem, not a request for a named product. Describe it and we'll tell you honestly whether an extension, an integration, or both is the right answer.
We map the exact process or connection that isn't working, confirm it genuinely needs custom code or integration rather than configuration, and agree a fixed scope before any development starts.
A working prototype against your data — or a test connection to the other system — reviewed with the people who'll actually use it, so the design gets tested before the build is committed.
Development in AL, or against the relevant Azure integration services and the other system's API, with automated test coverage, run in a sandbox environment that mirrors production before anything reaches your live tenant.
Release, documentation, and a maintenance path that re-validates the extension or integration against each new Business Central release and any change on the other system's side, so it keeps working as both platforms move.
Every extension is written in AL, Microsoft's language for the Business Central extension platform, and packaged against the same architecture Microsoft uses for its own module boundaries. Integrations are built on Azure's integration services with logging, retry logic, and failure alerting from the first version, not added after something breaks in production. Both get version control from the first commit, automated test suites that run in CI, and a re-validation pass against each new Business Central release well before it reaches your tenant — so an upgrade is a non-event instead of a support ticket.
Extensions are built as per-tenant extensions for internal use by default. Where a client wants to commercialize an extension — license it to other companies, or offer it as a product in its own right — we can also package and publish it to Microsoft AppSource as a separate engagement, including the certification and listing work that involves.
Microsoft's purpose-built language for the Business Central extension platform — not a general scripting bolt-on.
Extensions built and tested to run cleanly on both the cloud service and on-premises deployments where required.
Every integration logs its own activity and alerts someone when a message fails, instead of failing silently until a customer notices.
Scoped to one environment by default, with a clear upgrade path to a published extension if you later choose to distribute it.
Code structured from day one so it can be submitted for Microsoft's certification process without a rebuild, if that becomes the goal.
Not necessarily. If you already run an integration platform or a set of point-to-point connections that work, we'll build new connections consistently with what's there rather than forcing a rebuild. Where an existing setup is the source of the problem — no monitoring, no retry logic, nobody who understands it any more — replacing it is usually part of the conversation.
Often, yes. A warehouse scanning extension paired with a shipping-carrier integration, or a shop-floor portal paired with a PLC connection, are typically scoped and delivered together, since the extension is usually what the integration needs to write into.
Plenty of banking feeds, EDI partners, and legacy line-of-business tools don't. We build file-based, SFTP, or batch integrations through the same Azure layer where an API isn't available, so the connection is still monitored and logged even without a clean API on the other end.