Power BI Power BI and Microsoft Fabric - FAQs

Both Microsoft Fabric and Power BI alone can work. Power BI alone (Pro or PPU) is usually fine for simpler BC-only reporting. Power BI on Fabric becomes the right answer when you have multiple data sources, larger data volumes, AI ambitions, or you want a single platform for all analytical workloads. Most mid-market BC users we work with end up on Fabric because the integration tax of running multiple BI tools usually outweighs the Fabric capacity cost. The True Cost FAQ covers the licensing maths in detail.

You do not always need a data warehouse before Power BI: one system with standard questions can start from a semantic model connected directly to the ERP or CRM. You do need one when reports combine three or more systems, when the ERP's API is too slow for the query volume, or when finance wants self-service over governed data. We scope the sequence in the Establish phase. See the layered lakehouse explained.

The BC-to-Fabric lakehouse architecture applies to both BC SaaS and BC on-premises. The architecture is the same: extract data from BC into a lakehouse, build certified models, expose Power BI reports. The extraction mechanism differs (Lakehouse Connector and BC APIs for SaaS, direct database access or scheduled extracts for on-premises). The outcome is the same. Most new BC implementations are SaaS, but Hopton has experience with both. The whitepaper and the BC Implementation FAQ cover the technical detail.

BC data gets into Fabric through BC's APIs, with the data landing in a lakehouse layer. Most projects use a Bronze, Silver, Gold pattern: raw API data into Bronze, cleaned and modelled in Silver, business-ready facts and dimensions in Gold. Power BI semantic models point at Gold. The architecture is more substantial than direct connection, but it scales and supports multi-source analytics cleanly.

Data gets from BC into the lakehouse through three main mechanisms. The Lakehouse Connector (Microsoft's native option for BC SaaS to Fabric, with periodic full and incremental loads). Power Query refresh against BC APIs (for smaller volumes or specific entities). Custom extraction via BC's standard APIs or, for on-premises, direct database access. Most modern BC SaaS implementations use the Lakehouse Connector for the bulk of the data and supplement with Power Query for specific gaps.

Training fits into a wider Power BI or Fabric implementation project as a defined phase, not an afterthought. We build structured training into the Enable stage of every implementation, timed close to go-live so the concepts taught are immediately reinforced by using the actual reports the organisation will rely on day to day.

Yes. Fabric is often overkill for a BC-only business. If you are BC-only, modest in volume, and not pursuing advanced analytics, Power BI direct on BC is enough. The integration tax of Fabric does not earn its keep. The threshold for Fabric being the right answer is usually one of: a second material data source, a data volume problem, or a clear analytics ambition beyond standard reporting.

No. Microsoft Fabric is not required for Business Central reporting, but it usually pays back. Power BI direct on BC works for single-source, modest-volume scenarios. Once you have multiple sources, larger data volumes, or AI ambitions, Fabric becomes the right answer. Most mid-market BC implementations we work on now use Fabric, because the integration tax of running multiple BI tools usually exceeds the cost of Fabric capacity. The decision is covered in the BC Reporting Options FAQ.

Yes. For specific use cases, PPU is a good middle ground between Pro and Fabric. For broader use cases, often not. PPU is best when you have a small number of users who need Premium features and the rest of the organisation is fine on Pro. Once you have more than fifteen or twenty PPU licences, Fabric capacity usually becomes more economical and gives you broader capability. PPU is a tactical answer for a specific need rather than a strategic platform decision.

Power BI should read from a modelled star schema in a warehouse or lakehouse gold layer rather than directly from the source system, because source tables are the wrong shape for reporting, put query load on the operational system, and force every report to re-implement business rules. Direct connection to a source is acceptable for a small single-system proof of concept and little else. Getting your Business Central data into Power BI compares the routes for one common source.

There are five Power BI and Fabric overspending patterns. First, buying capacity without realising Pro is still needed. Over-provisioning capacity at launch. Never pausing capacity outside business hours. Paying for Pro licences that nobody uses. Jumping to F64 too early. Each is recoverable. Most mid-market organisations carry several at once. Together they account for most of the savings we find in cost reviews.

The Gold layer of a Business Central lakehouse holds business-ready facts and dimensions. A Sales Fact table with one row per transaction, with proper grain. A Customer dimension with the attributes the business cares about. A Product dimension. A Date dimension. Each fact and each dimension is the certified definition. Power BI semantic models point at Gold. Reports inherit consistency. New reports do not redefine measures because Gold is the source of truth. Gold is what makes the rest work.

The Silver layer of a Business Central lakehouse is where cleaning and structuring happen. BC tables are joined where logical (item ledger entries with their items, customer ledger entries with their customers). Codes are resolved to descriptions. Date fields are normalised. Currency conversions are applied if the business needs reporting in a single currency. History is reconciled across BC versions (because data structure can change between BC versions). Silver is the layer that turns BC's internal representation into something analytical work can build on.

What happens to existing Jet reports when you move to Power BI on Fabric depends on what those reports do. Reports that are genuinely finance-team-owned, BC-only, and Excel-natural usually stay in Jet. Reports that have grown into multi-source territory or need dashboard-style presentation move to Power BI. The migration is not all-or-nothing. Audit per report and decide what stays.

The best data warehouse architecture for Power BI reporting is a star schema built in the gold layer of a lakehouse or warehouse: fact tables at a clear grain for sales, invoices, stock movements and ledger entries, conformed dimension tables for date, customer, product, department and company, and business measures defined once in the Power BI semantic model that reads them through Direct Lake or import. The layered lakehouse explained shows where the star schema sits.

A data warehouse or lakehouse gold layer stores modelled tables, the facts and dimensions, while a semantic model sits on top of those tables and adds the business meaning: relationships, measures defined once, hierarchies, security and descriptions. The warehouse holds the data; the semantic model holds the definitions every consumer shares. In Fabric the two are separate items, with Direct Lake letting the model read the tables without copying. The layered lakehouse explained shows the layers.

Power BI on Fabric is the right answer for BC in three scenarios. Multi-source reporting, where BC is one of several systems feeding analytics. Heavy data volumes, where BC's API would struggle on direct connections. AI and forecasting ambitions, where the modern Microsoft AI stack lands first. If any of these describes you, Fabric usually pays back the additional setup cost.

In Microsoft Fabric, data should be reshaped for reporting in the curated layer, usually called Gold, of a lakehouse or warehouse. Raw data lands untouched first, is cleaned and conformed next, and only then is it reshaped into facts and dimensions for a Power BI semantic model to use. See our Microsoft Fabric page for how we approach it.

In Microsoft Fabric, the star schema should be built in the curated Gold layer of a lakehouse or warehouse, not separately inside each report. The Power BI semantic model then sits on top of it, so every report shares the same facts, dimensions and definitions.

BC reporting will not eventually all move to Fabric; operational reporting, in particular, will not. Invoices and statements stay in Native. Analytical reporting is moving to Power BI on Fabric, and that direction is clear. The intermediate cases (finance reporting, BC-centric analytics) split between Jet, Power BI direct, and Power BI on Fabric depending on the specific use case. The long-term picture is two or three tools, each in its lane.