How to build a Business Central integration that lasts

You’ll probably recognise the situation. One screen shows orders, prices and stock in Business Central. Another shows the website, and the numbers don’t quite match. That’s when it becomes clear that a Business Central integration is part of your business infrastructure.

That is where many projects start to go wrong. The problems begin with ownership. You need to decide who owns item numbers, prices, stock levels, and changes when fields are altered in an upgraded business system or in a portal.

Why the Business Central integration is your new infrastructure

A commercial manager opens Business Central and sees one stock level. A colleague on the website sees another. Both think they’re working with the same truth, but they’re looking at different snapshots in time. When this happens in production, the problems usually come down to an unclear integration contract.

Swedish companies already use digitalisation widely for administration. According to the Swedish Agency for Economic and Regional Growth’s survey, 55.3 percent said they used IT or digitalisation to a large extent for administration, while 16.2 percent did so to a large extent for business development. That says a lot about where the value usually ends up. Many have already digitalised the internal flow but haven’t connected it to sales, product data and self-service.

A Business Central integration often starts as an export of customers or orders. It works, but it only carries a small part of reality. As soon as prices, stock status, order lines and feedback need to move in both directions, the solution becomes an infrastructure question.

That is also why large companies often see the benefit later than they expect. Administration is already digital in many cases, but the business value comes when the same foundation is used for more channels and more flows. The systems then need to agree on what is true, when it is true and who may change it.

Start with a canonical data model

You only start saving time once you decide what the shared truth should be. For items, customers, prices, stock and orders, you need a canonical data model before anyone starts building. Otherwise every channel ends up with its own interpretation of the same business object.

Start with the Swedish business rules. Customer numbers, units, VAT and price lists should be mapped to Business Central’s standard entities. Then decide what belongs in the business system, what should be enriched in the PIM and what should be governed on the website or in the portal.

Microsoft’s API guidance for Business Central points to the REST API stack as the recommended integration route. That is the starting point, and it requires you to document every field, every owner and every write rule.

This is where things often go wrong in practice: VAT and units are interpreted differently between systems, price lists follow different rules in the channel and the business system, stock fields are confused with reserved stock or available balance, and order status becomes a local language that no other part of the flow understands.

You also need to know what should not sit in the standard objects. If a business object is missing, it should get its own AL-based API surface. Microsoft’s documentation on API development in Business Central shows that API pages and API queries can’t be extended directly. If fields are missing, a copied and customised AL API solution is required.

For anyone who wants to go deeper into working with product data, there is our article on product data management systems, where the same principle of ownership and structure applies to product flows.

How products, prices, stock and orders flow

According to Statistics Sweden, digital sales are already established in several Swedish industries. In total, 30 percent of companies sold via their own website, app or e-commerce platform, and 8 percent sold via a shared marketplace. In manufacturing, the share was 21 percent via their own digital channel, with a further 4 percent via shared marketplaces. That makes the flow itself business-critical.

Product data and item numbers are often master data and should therefore have a clear owner. Prices more often need a different setup, since customer-specific price lists change continuously. Here the LastModifiedOn field is useful for incremental synchronisation in Business Central online, according to Microsoft’s documentation on extracting data.

The first full load and the ongoing sync must be kept separate. This is one of the most common mistakes. The first run builds the base. After that, changes should flow with clear filters and limited updates.

Stock status is time-critical. If it lags, the purchase loses credibility immediately. The order flow also requires idempotency, an external key and a clear status, since the same order can arrive several times when a network or an interface misbehaves.

Microsoft describes webhooks as the way to be notified when an entity changes in Business Central. Webhooks work for the entities that support them. The ongoing sync should be built on changes and events.

Even when the flow works, problems usually show up in three places, described in more detail in our article on ERP integration. Duplicates occur when the order lacks a stable key. Price leaks occur when the price is calculated in the wrong system. Lagging stock occurs when the balance is sent too rarely or from the wrong source.

Choose a middleware pattern based on ownership

The choice of middleware is about responsibility, traceability and how much work comes with each change.

File transfers suit flows that rarely change and have low business criticality. Ownership when something fails is often split between two parties, and traceability is usually low to medium.

A managed integration platform suits cases with many flows, many failure paths and requirements for continuous monitoring. Responsibility is then more clearly contracted with an operator, and traceability is high.

Your own middleware suits cases where you want to own mapping, versions and reuse over time. Ownership then sits with you or your delivery partner, and traceability can be high if logging and queue handling are well designed.

What matters is that the mapping lives separately from the transport. If you later move from files to APIs, or from a simple solution to more governed operation, the business rules should carry over. Otherwise every technology change becomes a rework of the same problem.

This is also where a productised delivery model can help. We deliver functions and integrations as fixed building blocks in the Function Library, where scope and price are defined before development starts. It suits cases where you want clear ownership of functions and reuse, but don’t want to lock yourselves into a single operating model.

Test as if it were an upgrade

An integration test should prove that the flow can be re-run. You therefore need idempotent writes with an external key, re-runnable test cases and a version matrix covering the business system, the web platform and any extensions.

Start by creating the order. Change it. Cancel it. Deliver it partially. Run the same scenario again. If the result is two orders or incorrect lines, there is a contract problem.

It is wise to set your own quality targets. In this way of working, 100 percent matching on item number, price list and stock level in the test dataset is a project goal, as are zero duplicate orders after a re-run. These are your targets, and they make deviations clear.

You also have to test Swedish local fields. VAT, currency, payment and accounting don’t behave like generic text fields. When an upgrade arrives, contract tests should catch issues early, before they turn into support tickets.

Anyone who only runs a demo before go-live is usually testing functionality. That is enough for a first showing, but a long-lived integration contract requires the solution to handle change over time as well.

Deployment and management over time

Once the Business Central integration is live, the real work begins. Microsoft documents in its API limits that a client can receive HTTP 429 when limits are exceeded and that retries with a cool-down period are required. A single long-running request also gets at most 10 minutes before the service returns HTTP 504. Microsoft also sets limits on how many calls per minute an environment accepts. That is why ongoing management is part of the architecture.

You need correlation IDs, a hash of the payload, the number of attempts, the response code and the queue state. Without them, troubleshooting becomes guesswork. Permanent errors should go to a dead-letter queue, meaning a separate error list or queue where messages that can’t be processed automatically are captured for manual, traceable handling.

Regional update packages and version differences require their own release plan. That is why an agreement on ongoing responsibility, such as Glanser Care, can be the right model when you want version tracking, compatibility through upgrades and bug fixing as an ongoing function. The cheapest Business Central integration at go-live often becomes the most expensive after the first major upgrade, because the cost then shifts from building to regression testing, data mapping and incident handling.

For anyone who wants to see how integration work connects to the breadth of a solution, there is our article on Business Central and Magento integration, where operations and boundaries get the same weight as the connection itself.

Three questions to ask your supplier

Ask which version of the integration contract applies when Business Central, your web platform or an extension is upgraded. The answer shows whether the supplier takes responsibility over time or only for the delivery itself.

Ask which parts are based on standard and which require a customer-specific AL extension. The answer shows how much of the solution is version-safe and how much risks regression when business rules change.

Ask how permanent errors are handled and who owns the dead-letter queue. The answer shows whether there is a real operational commitment or just a handover with a nice name.

On the ERP and integrations page, you can see how we work with integration setups, division of responsibility, and management that holds up over time.