Guides

Architecture

Learn how BC2Fab mirrors Microsoft Business Central data into Microsoft Fabric to deliver governed, analytics-ready datasets for reporting and AI-driven insights.

Solution overview

BC2Fab provides a managed mirroring solution that synchronizes operational data from Microsoft Business Central into the Microsoft Fabric lakehouse. The platform focuses on zero-code connectivity, automated schema handling, and end-to-end observability so finance and operations teams can build Power BI reports or semantic models without managing integration plumbing. The mirroring process captures incremental changes from Business Central APIs, ensuring that the data in the Fabric lakehouse is always up-to-date and reflective of the source system.

Architecture at a glance

BC2Fab orchestrates secure data movement from Business Central tenants into a Microsoft Fabric lakehouse.

BC2Fab components in detail

BC2Fab spans two trust boundaries. The BC2Fab workload is hosted in navida's backend and is responsible for serving installation files and performing the license check. Everything it deploys runs entirely inside the customer's own O365 tenant — no business data ever leaves it.

navida backend BC2Fab workload — hosted by navida

Installer service

Serves install & update files

License check

Validates the customer's entitlement

Delegated permissions

Consent capped at signed-in user

↕  install & update files  ·  license validation  ↕

Customer O365 Tenant all components installed by the workload/BC App

bc2fab_refresh pipeline

Scheduler · triggers the loader notebook

↓ triggers

BC2Fab loader notebook

Orchestrator · calls Python code from internal lakehouse

Business Central

BC2Fab App defines tables & API endpoints · OData / REST

Internal lakehouse

Config · code repository · watermarks · logs

Key Vault · Entra ID

App registration · secret

↓ writes Parquet change files

Landing zone · Mirrored Database

Parquet upserts + delete markers · Open Mirroring

↓ auto-mirrors to delta

bc schema

Mirrored delta tables

bc_silver schema* premium

SQL views · surrogate + relation IDs · BC Model Accelerator

↓ consumed by

Power BI semantic models* premium

Out-of-the-box reports

Install, license & update — the workload boundary

The BC2Fab workload lives in Navida's backend. Everything it deploys runs in the customer's own O365 tenant.

1
Deploy: the workload's installer service retrieves the installation files and provisions all Fabric components — loader notebook, pipeline, lakehouse, mirrored database — into the customer tenant.
2
Ownership handover: once installed, those components belong to and run entirely inside the customer's Fabric capacity. No customer data flows back to Navida — except for the general configuration settings maintained in the workload: Name of BC Environment, BC Companies, Key Vault URI, and Tenant ID.
3
License check: on each run, the loader calls the workload's license endpoint to validate the customer's entitlement before loading.
4
Update check: when a user opens the workload, it checks for a newer version of the BC2Fab components.
5
Update on demand: if a new version is available, an update button appears. The components are updated only when the user clicks it — updates are never applied automatically.
6
Separation: the BC2Fab backend only ever serves install files and answers license and update calls — it never sees BC data, watermarks, or the mirrored tables.

Incremental load engine

Runs inside the customer tenant. Delta detection per endpoint × company, in parallel.

1
The loader reads the last stored watermark to determine which records have changed since the previous run.
2
Only the changed records are retrieved from Business Central, page by page.
3
The records are written as Parquet upserts to the landing zone.
4
The watermark is advanced so the next run picks up only newer changes; endpoints are processed in parallel.

Deletion handling

Business Central reports deleted records through a change feed; the loader turns them into delete markers.

1
The loader reads records deleted in Business Central since the previous run.
2
Each deletion is matched back to the correct mirrored table.
3
A delete marker is written to the landing zone, and repeated deletions are ignored.
4
Open Mirroring applies the delete markers to the mirrored delta tables automatically.

Authentication

Access is granted through an Entra ID app registration set up during installation.

1
The client ID of the app registration is stored in the environment configuration and is set during installation.
2
The app registration's secret is stored securely in Azure Key Vault.
3
The same app registration is used for both the initial load and all incremental loads.