Microsoft Fabric is Microsoft's unified data and analytics platform that brings together data engineering, data storage, data transformation, and reporting into a single, integrated environment.

For Business Central clients, Fabric serves as a central data platform where all operational data is automatically replicated into structured tables, making it immediately available for reporting and analysis.

The key benefit is that Fabric removes the need for manual exports, disconnected tools, and complex data preparation processes. Instead, it provides a scalable and governed environment where your data is always available, consistent, and ready for use across Power BI, Excel, and other analytics tools.

Fabric significantly improves on traditional OData-based reporting by changing how data is accessed and processed. With OData, every report query runs directly against Business Central, which can slow down performance, place strain on the ERP system, and limit the volume of data that can be analysed reliably.

With Fabric:

• Data is replicated into a dedicated data platform, separate from Business Central
• Reporting queries run against Fabric instead of the ERP system
• Large datasets and historical data can be analysed without performance issues
• Data transformations are handled centrally instead of in Excel or Power BI

This results in faster report refresh times, improved stability, and the ability to scale reporting across multiple companies and large volumes of data.

Fabric provides both operational and strategic value by turning Business Central data into a structured, reliable, and scalable reporting foundation. From a business perspective, this includes:

• Faster reporting: reports that previously took minutes or hours to refresh can run in seconds
• Reduced manual work: eliminates reliance on spreadsheets, manual exports, and disconnected processes
• Improved data accuracy: a single, governed source of truth ensures consistent reporting across the business
• Scalability: supports multi-company reporting, large datasets, and future system integrations
• Future readiness: enables advanced analytics, automation, and AI capabilities as business needs evolve

Overall, Fabric allows organisations to move from reactive reporting to proactive, data-driven decision-making.

This monthly fee covers infrastructure, hosting and maintenance costs to sustain your reporting environment. New development and direct support are billed separately. There are no user licence fees; to give your team access to Fabric, their usage simply counts towards your total capacity consumption.

Via the Freshdesk ticketing platform at our standard support rates.

In this scenario Linc will manage the BC Export app, including new developments, while the Fabric environment is managed by you.

Linc will install and configure the BC Export App as part of the standard setup.

All tables which are currently used in reports.

The BC Export App provides visibility on table sync date and time, and the Business Central Job Queue indicates the sync schedule, including log entries for each sync run.

The full table, including all rows, will be included in the next Fabric sync, versus the standard incremental sync.

Yes, it will be removed in the next Job Queue run.

We recommend selecting all fields when the table is added to the export list. This reduces the need for schema changes when a field is later required in a report.

You will have full Admin access to the Fabric Workspace, including all databases, lakehouses, data pipelines, and so forth. Admin access is given to authorised users only; additional users can be granted view-only access.

Yes.

Yes. Those users would only have access to the final layer where the report-ready data resides. Only selected admin users would have access to the full workspace.

Yes. Report builders are granted access only to the Power BI reports and Semantic Models (via Lakehouse Viewer roles or a Power BI App), and never to the underlying Fabric workspace, Lakehouse, or Warehouse. Only selected admin and developer users have direct Fabric access.

Within the Semantic Model, access can be further restricted using:

• Row-Level Security (RLS): for example, a user sees only their company's or region's rows
• Object-Level Security (OLS): hides entire tables or sensitive columns from specific roles
• Power BI App audiences: different groups of users see different subsets of reports from the same workspace

Each user requires a valid Power BI Pro (or PPU) licence to consume the content.

You should connect to Views.

FlowFields are live UI calculations rather than physical data stored in the database, so data replication tools skip them. The standard practice is to export the raw transaction tables into Fabric and recreate the flow fields using SQL Views.

Use the SQL Server database connector.

Service principal for Power BI, and a Microsoft Account for Excel.

You change the source in Power Query to the Fabric view.

When a new company is added to the schema in the BC Export App, the data will sync with the next Job Queue run and be added to the existing Fabric tables. We recommend adding a Company and Table Key field to each view used in a Semantic Model. This key field allows for both multi-company reporting and filtered company reporting in a semantic model.

If a semantic model has a company filter applied, the new company will not flow through by default. If no company filter is applied, the new company will flow to the semantic model without any changes to the View or Semantic Model.

You will have access to add companies in the BC Export App, or alternatively a ticket can be logged and we will assist. Adding a new company is as simple as resetting the Schema in the BC App, adding the company, and running the Export Schema function.

On the next scheduled Job Queue run (default every 60 minutes, configurable if required), the company tables will begin to replicate. This replication process will depend on the number of tables and the number of rows within each table.

There is no cost for you to run this process. If changes are required to any existing pipelines or views where the company is filtered, and Linc's assistance is needed, this will follow the standard ticketing process.

The table must first be enabled for export in the source system, ensuring that all required fields are selected. Once configured, the table is automatically ingested into the Mirrored Database, where it is stored as a raw one-to-one representation of the source data.

The turnaround time and effort depend on the complexity of the data and its role in the reporting model. For simple tables that align well with existing structures and require minimal transformation, the process can typically be completed within one to two business days. For tables that require moderate transformation, integration into existing models, or minor redesign, the effort may extend to two to five business days. In more complex scenarios, where significant transformations, aggregations, or data modelling changes are required, the process may take longer.

When a new field is added to an existing table in the source system, it does not automatically flow into the reporting pipeline. The field must first be explicitly enabled in the export configuration (for example, in the BC Export App) by selecting it for export.

Once enabled, a schema refresh or re-export must be triggered to push the updated structure through to the Fabric environment. After this process, the new field becomes available in the database as part of the raw table structure. At this stage, the field exists in the data platform but has not yet been incorporated into any transformations or reporting models.

The field must be manually incorporated into the downstream data layers. This involves updating the SQL Views to include the field, applying any required cleaning, standardisation, or business logic.

Finally, the semantic model is updated to expose the field for use in reporting tools such as Power BI and Excel. This controlled approach ensures that the field is meaningful, accurate, and consistent within the broader reporting framework.

For simple fields that only need to be enabled in the source system and passed through to existing models with minimal transformation, the effort is low and can typically be completed within the same day to one business day. If the field requires updates to transformation logic in the SQL Views, the effort increases slightly and may take one to three business days. Where the field introduces new business logic, impacts existing measures, or requires changes to the data model and semantic layer, the effort is higher and may take several days depending on complexity.

Yes, you can add or remove tables in the BC Export App.

Yes, external data sources can be integrated into Microsoft Fabric for unified, combined reporting. This is one of Fabric's core strengths.

Setting up a foundational Fabric architecture prepares the landing zone for this data, but connecting external platforms requires building dedicated ingestion pipelines. Owing to third-party systems having widely different API structures, licensing, and security protocols, the development of these external connectors is typically scoped and quoted as a separate phase of a project.

Yes, Fabric is highly flexible and handles a wide range of data formats, including CSV, Excel, and JSON, and can connect directly to transactional databases or external APIs.

Yes, provided you have a minimum Microsoft Fabric F2 capacity.

Logical and code-based components can be migrated between workspaces. This includes views, notebooks, dataflows, pipelines (via export and import), and semantic models and reports. These components represent the more complex logic and transformation layers, making them the most important to retain during migration, while the underlying data layers can be rebuilt separately.

Several components will need to be rebuilt due to dependencies on data, connections, and workspace-specific configurations:

• OMDB (Open Mirroring Database) must be fully recreated
• Storage layers (Lakehouses and Warehouses) need to be re-established, including schemas and data
• Data ingestion and pipelines require reconfiguration (connections, credentials, parameters), even if exported and imported
• Data itself (tables and files) must be reloaded or copied, as it is not automatically migrated
• External connections and shortcuts need to be recreated manually
• Security and access control (workspace roles, permissions, RLS) must be redefined in the new workspace

The level of effort is generally moderate, rather than a full rebuild, as many logical and code-based components (such as notebooks, views, and pipelines) can be reused through export and import. Additional effort is required to recreate data layers, reconfigure pipelines, reconnect data sources, and reapply security and permissions, which adds complexity to the migration process.

There are several limitations and risks to consider during migration:

• Incomplete migration of data: only metadata and logic are migrated; underlying data (such as Lakehouse tables and files) must be copied or reloaded separately
• Manual reconfiguration required: pipelines, data sources, and connections may still reference the original environment and need to be manually updated
• Dependency risks: pipelines and notebooks may fail if dependent components (such as Lakehouses and databases) are not properly recreated or mapped
• Security and access risks: permissions, roles, and access controls are not migrated and must be reconfigured, increasing the risk of incorrect access setup
• Limited migration support: not all Fabric components can be migrated automatically, requiring partial or full rebuilds

Yes. In Phase 1 (Foundation) we set up the core pipeline for the first few companies, and Fabric standardises the data structure upfront.

Phased rollout: Adding the remaining companies is highly repeatable. Given that they share the same Business Central tenant, the underlying data structure is identical. Adding a new company simply means pointing the existing pipeline to the new company's ID.

Unified reporting: Fabric consolidates the data from all companies into a single, centralised Lakehouse. Your Semantic Models can then report on individual companies or aggregate them automatically for group-wide, consolidated financial reporting.

The main requirement for a successful move is internal training. Once your team is comfortable managing the Fabric workspace independently, the transition to your own tenant will be straightforward. We will provide support as your team builds this internal knowledge.

Please note: if Linc's assistance is required for any changes, additions, or errors within the Fabric workspace, billing will follow the standard ticketing process.