Integrationer

Fewer dependencies, more stability. Integrations are rarely the problem in themselves. The problem is when nobody has the overview.

The goal is not more integrations. It is fewer, better managed ones.

Integrations are rarely the problem in themselves. The problem appears when nobody has an overview: when logic, ownership and data sources are not clear, and a change in one system sends shockwaves through the rest. We know this. It is what we clean up.

Fragmented ownership

When responsibility is spread across teams, data flows become nobody's land. Errors are discovered late and nobody knows exactly what happens when.

Hidden dependencies

Small changes in one system can affect multiple steps without being documented or tested. BC updates break integrations nobody knew were connected.

Unclear data sources

When the source of truth is not defined, parallel truths emerge. The webshop shows one stock level, BC shows another. Nobody knows which is right.

When the source of truth is not defined, parallel truths emerge. The webshop shows one stock level, BC shows another. Nobody knows which is right.

What we map before we build

Before the first integration is written, we map your existing systems:

  • Which systems exchange data, and in what order?

  • Who is the "source of truth" for each data object?

  • Which integrations are critical enough that a failure stops the business?

  • What happens when an integration fails, and who knows about it?

  • Where is there manual handling that can be automated?

This is not paperwork. It is what makes the implementation predictable.

Our approach

We build integrations designed to change:

  • API-first: integrations via open, versioned endpoints, not file transfers

  • Event-driven: systems react to events rather than polling

  • Error handling by design: errors are logged, alerts sent, the system retries

  • Observability: you can see what ran, when, and what went wrong, without contacting us

Direct connections or a data middleware layer?

Most BC partners build integrations direct system-to-system: webshop talks directly to BC, CRM talks directly to BC, EDI talks directly to BC. It works for two integrations and becomes unmanageable at eight.

Curabis introduces ODS (Operational Data Store) as a middleware layer. BC synchronises master data to ODS, and all external systems communicate with ODS rather than BC directly. Concrete consequences:

  • BC is not loaded by external queries and runs undisturbed

  • All channels see the same prices, stock status and customer data

  • A new channel or app is connected to ODS, BC is not touched

  • A single monitoring and troubleshooting point for all integrations

Most BC partners build integrations direct system-to-system. ODS is Curabis' architectural choice, and we believe it is the right one for companies with more than two to three critical integrations.

Vibe coding: build against your own data

ODS is a standard SQL database. That gives your own developers or an AI assistant like Claude or Cursor direct access to live BC data, without needing to know BC's internal API structure.

A sales manager who wants a daily report of customers who have not ordered in the past 90 days can ask their AI assistant for it. The data is in ODS, the permissions are set up, and it requires no IT support ticket.

We call it vibe coding. It is the approach that makes business data accessible without IT as a bottleneck. No BC partners in Denmark offer this today.

Pricing and what is included

ODS costs DKK 1,000 per month as a standalone product. Included:

  • Managed SQL SaaS on Azure

  • Live synchronisation from Business Central

  • Standard data sets: items, prices, customers and orders

  • Full API documentation and schema overview

The Cross Channel Platform is added for DKK 1,500 per month. Entry point with both is DKK 2,500 per month. Typical total spend including Azure hosting: DKK 5,000-6,000 per month.

That is less than two hours of consulting per month and gives your organisation permanent access to your own data.

The ODS data flow: what happens, step by step

ODS is a buffer and distribution point between Business Central and all external systems. The architecture has three movements:

  • 1. Master data out (BC to ODS): BC synchronises master data to ODS: items, prices, customers, inventory and locations. ODS is near-live updated.

  • 2. Apps and channels fetch (ODS to apps): Webshop, Power BI, CRM and AI assistants pull data from ODS. BC is not loaded.

  • 3. Transactions back (apps to BC): Orders and status updates from apps are sent asynchronously to ODS and then to BC. BC processes them when capacity allows.

The result is that BC runs undisturbed with finance, orders and operations, while all external systems see consistent data from ODS. A new channel is connected to ODS, not BC, and BC is not changed.

ERP ↔ Webshop

Orders, stock status, prices and customer master data synchronised live. Umbraco and Business Central speak the same language, no overnight batch jobs.

ERP ↔ CRM

Quotes, orders and invoices in CRM, customer history and payment status in the sales process, and one customer view across systems.

ERP ↔ Third party

EDI (PEPPOL, EDIFACT), WMS, payroll, shipping booking. Standard connectors where they exist, custom solution where they do not.

Azure Functions as the integration engine

Most of our integrations run on Azure Functions: serverless, event-driven and billed per execution.

  • No server to maintain

  • Scales automatically under load

  • Costs nothing when it is not running

  • Full logging and monitoring via Azure Monitor

  • Deployment via GitHub Actions, changes are safe and repeatable

EDI and e-invoicing

We have specialist expertise in EDI: PEPPOL and EDIFACT. Our VAX Transfer solution automates document exchange directly from Business Central: order confirmations, invoices and credit notes, without manual work.

When an order document is sent automatically seconds after it is created in BC, it is not an integration you think about. It is silent infrastructure.

You do. Code, documentation and credentials are handed over. We handle operations and monitoring through our Keep Current agreement, but you are not technically locked in to us. That is a deliberate part of our approach.

Error handling is part of the design: critical integrations retry automatically, logs are captured in Azure Monitor, and you or we receive an alert. You do not need to wait for a customer complaint to discover it.

ODS (Operational Data Store) is a data middleware layer that mirrors your BC master data in a standard SQL database and gives all systems, apps and AI assistants access to live business data without loading BC. ODS makes sense from two to three critical integrations onwards, and when you want to give the business access to data without IT as a bottleneck. The price is DKK 1,000 per month.

For master data (items, prices, customers, inventory) ODS is near-live synchronised from BC. For most business purposes the delay is under one minute. Transactions sent back from apps to BC are processed asynchronously and are typically in BC within a few minutes, depending on volume and BC's processing capacity.

BC updates automatically as part of your SaaS subscription. CURABIS maintains the ODS sync that moves data from BC to ODS. When BC updates its data structure, we update our side as part of the service agreement. You will not notice it in your apps or reports.

Usually yes. We have experience with the systems most common in the market: Salesforce, HubSpot, Shopify, shipping integrations and EDI networks. If you have something more specialised, we do a technical assessment before making any promises.

A PTE extension adds logic inside Business Central. An integration connects Business Central to an external system. Typically it is a combination: the BC logic ensures the right data is ready, and the integration sends it on.

No. For our customer segment, enterprise ESB platforms add unnecessary overhead in cost and complexity. We use Azure Functions, Service Bus and Logic Apps, the Microsoft stack we know inside out and can troubleshoot quickly. A simpler architecture is a more reliable architecture.