Power BI on Business Central in practice: pitfalls, embedding, and upgrades

The pitfalls, mobile reporting, embedded dashboards, and what actually happens at upgrade time: the practical realities of running Power BI on Business Central once it's live.

Where BC and Power BI implementations actually go wrong

Three pitfalls come up again and again. Underestimating multi-company complexity, consolidation logic is harder than it looks once codes, currencies and structures diverge between entities. Trying to replicate Native BC reports verbatim rather than redesigning for the analytical use case they are actually meant to serve. And building without a Silver layer, so data lands in Gold raw and the inconsistencies surface in reports later, when they are more expensive to fix. Each pitfall is recoverable but adds time and cost when discovered late. Engaging a BC analytics partner who has seen the patterns before reduces that risk meaningfully.

Knowing when direct-on-BC still works, and when it does not

Direct-on-BC is enough when reporting is BC-only or BC-dominant, data volumes are modest, and refresh frequency is reasonable. For a single-source, mid-market BC business doing typical operational analytics, this works well: reports are fast to build, the architecture is simple, and the cost is just the Power BI licence. The limits show up in two places. BC’s API throughput becomes the bottleneck for large data volumes or complex queries. And multi-source reporting struggles because the joins happen in Power BI rather than in a proper data layer. When either constraint shows up, the answer is to add Fabric underneath rather than force the direct approach further than it can go.

Excel and Power Query still have a place

Power Query in Excel works for small-scale, individual reporting, but it does not scale to shared, certified, governed reporting across an organisation. Excel files go stale, definitions drift between users, and the same metric ends up with different numbers in different files. Power BI on a certified semantic model produces one definition, current data, and consistent numbers across everyone using it. Excel remains genuinely useful for ad-hoc analysis and reconciliation. Power BI handles the recurring reporting that needs to be trustworthy across the business, and the two are not in competition so much as doing different jobs.

Bringing dashboards to where decisions happen

Yes, Power BI reports can be embedded directly into BC pages, so a user looking at a customer record in BC can see the related Power BI analytics on the same screen. The integration uses Power BI’s standard embedding capabilities and works for both BC SaaS and BC on-premises with appropriate configuration. The result is that analytical context appears where operational decisions are made, rather than in a separate tool the user has to switch to and remember to check. This is one of the more underused capabilities in BC and Power BI implementations, and one of the easiest wins once the underlying reporting is in good shape.

Mobile reporting deserves its own design

Power BI has mobile apps for iOS and Android with offline support and push notifications. Reports designed specifically for mobile, a different layout from desktop, work well for users who travel or work in the field: sales managers reviewing customer activity, operations leaders checking site performance, executives reviewing KPIs on the move. Mobile is increasingly the primary interface for senior users rather than a fallback. The design discipline that matters here is building mobile-first views deliberately, rather than expecting a desktop report to work well squeezed onto a small screen.

What happens when BC upgrades

Most upgrades happen without breaking analytical reporting, because the architecture insulates Power BI from BC’s internal changes. The Bronze and Silver layers absorb structural shifts, Gold stays stable, and reports keep working. Major BC upgrades occasionally introduce changes that need accommodation in the extraction layer, but these are usually small adjustments rather than rebuilds. Hopton handles BC version updates as part of Continuity. Clients without that kind of ongoing support sometimes see small reporting issues after a BC upgrade; with it, the platform stays in step as BC moves forward.

When BC data needs to sit alongside everything else

Power BI on Fabric is almost always the right answer once BC data needs to sit alongside other systems. Native cannot do it. Jet struggles beyond BC. Power BI direct on BC gets there for a while, but the architecture stops scaling as the number of sources and the complexity of the joins grow. Fabric is built for multi-source analytics, and BC’s data sits comfortably alongside Shopify, Xero, a CRM, or whatever else the business runs. If there is any meaningful multi-source need on the horizon, the long-term answer is Fabric, and it is worth planning for it before the direct approach starts to strain.

None of this is about picking the fanciest tool. It is about matching the setup to where the business actually is, and knowing which signals mean it is time to change that setup. If you recognise any of the pitfalls above, or you are wondering whether your BC and Power BI implementation is missing capabilities like embedding or mobile design, that is a conversation worth having sooner rather than after the next upgrade or the next new data source arrives.