Yes — Looker and Power BI are increasingly direct competitors. Five years ago they served different audiences (Looker for engineering-led data teams, Power BI for business users). The platforms have converged: Power BI added stronger semantic modelling and embedded options, Looker added more business-user accessibility. Today they overlap in the mid-market where both can serve a typical reporting estate, and the choice becomes a strategic one about platform alignment rather than a feature-by-feature comparison.
Big consultancies are sometimes better for big projects, but not always. Big consultancies are better when the project genuinely needs the breadth: multi-country, multi-system, multi-workstream programmes with complex stakeholder management. They are not necessarily better when the project is narrower in scope. A focused mid-market specialist often delivers better outcomes on a Power BI estate rebuild than a big-four team would, because the depth of specialism beats the breadth of capability for that specific work. The match between the engagement and the firm matters more than the absolute size of either.
Yes — individual Microsoft certifications are meaningful, when they are recent and relevant. The relevant individual certifications include the PL-300 (Power BI Data Analyst), DP-600 (Microsoft Fabric Analytics Engineer), DP-700 (Fabric Data Engineer), AZ-400 (Azure DevOps Engineer), and the higher-level architect certifications. Look for currency: the Microsoft certification landscape changes regularly and certifications older than two or three years should be either renewed or matched by recent equivalents. A team where most senior consultants hold relevant current certifications is a stronger team than one where the certifications are concentrated in a few people.
No — public case studies are not a good substitute for references. Case studies are written by the consultancy and present the engagement at its best. References are conversations with people who lived through the engagement and can describe the messy parts. Both have a place. Reading the case studies before the reference call helps you ask better questions. Relying on case studies alone is insufficient diligence for any engagement of meaningful scope.
Smaller consultancies are often better for smaller projects, but with caveats. Smaller consultancies (boutique specialists, individual contractors) are usually more focused, more flexible, and more cost-effective for tactical and mid-sized work. The caveat is delivery resilience: a four-person consultancy depends heavily on those four people, and their availability defines what is possible. Specialist mid-sized firms (typically 10 to 50 people) usually combine the focus of small firms with enough resilience for serious engagements. The shape of the firm matters.
There are three other saving tactics worth knowing. First, periodic capacity rightsizing reviews: workloads change, capacity needs change, the right tier today may not be the right tier in twelve months. Second, certified semantic models: a few well-built models are cheaper to run than many overlapping ones. Third, attentive Pro licence management: quarterly reviews catch the unused licences before they accumulate. None is dramatic. Together they produce the structural savings that compound over years.
Yes — there are free Power BI themes designed for KPI dashboards. Several of Hopton's free Power BI themes are built for exactly this: bold, high-contrast palettes like 149 Degrees (tagged Bold, Executive) that hold up on board-level KPI dashboards, alongside accessible options like Beacon and Spectrum for teams that need colourblind-safe reporting. Each theme sets accent colours, card styling, and typography consistently across the report. Target, at-risk, or variance colour-coding on individual KPI cards is set separately through Power BI's own conditional formatting; the theme provides the consistent base it sits on top of. Themes are free JSON downloads applied via View, then Themes, then Browse for themes in Power BI Desktop.
Yes — there are hidden costs in both platforms. Power BI's hidden cost is usually the F64 inflection point: organisations buy Pro licences and end up paying more than they would on Fabric capacity once viewer counts grow. Looker's hidden costs are usually the implementation work and the BigQuery costs that go with it. Both platforms can be made cheaper than published prices through enterprise agreements. The honest answer is that both have non-trivial total cost of ownership and the published list prices understate it.
F64 becomes economical at around 500 viewers at PAYG list prices. Around 370 viewers with annual reservation discounts (roughly 20 per cent off). Around 250 viewers with three-year Enterprise Agreement discounts (up to 41 per cent off). The crossover comes down as your discount level rises. Below your specific crossover, smaller capacity plus per-user Pro is cheaper. Above it, F64 is cheaper despite the higher capacity cost. Run the maths against your actual viewer count and your actual discount level.
Yes — FP&A reporting can integrate with your auditors, where they are interested. Some clients give their auditors read access to the relevant Power BI workspaces during the year-end audit, so the auditors can see the underlying numbers directly rather than receiving manually-produced extracts. The integration reduces audit cost and improves audit quality. It depends on the auditor being technically comfortable with the platform and the client being comfortable with the access. For some clients this works very well; for others the traditional audit pack remains the right approach.
Yes — Hopton can coordinate with your existing CRM partner, and usually does. Most CRM engagements involve coordination with the CRM administrator (in-house or partner), the marketing automation partner, and sometimes the ERP partner. Hopton runs the analytical workstream specifically. We do not displace the CRM partner; we deliver the analytics layer they cannot deliver themselves.
Yes, although the engagement runs more smoothly when the BC partner is in the loop. We do not need access to BC's transactional configuration. We do need access to BC data via the standard APIs and the Lakehouse Connector. For BC SaaS, this is straightforward. For BC on-premises, the BC partner often helps with the database access setup. Either way, the analytics workstream is independent of the BC partner relationship.
Yes, this is a common request - reworking an existing app's navigation, audience structure, and branding without necessarily rebuilding the underlying reports themselves. It is often a relatively quick, high-value piece of work compared with a full reporting rebuild.
Yes — Hopton can review a Power BI report we have already built. We offer fixed-price UI/UX reviews on existing reports. We work the checklist end-to-end, log issues with screenshots and priorities, and deliver a written report you can give to your team. Most reviews complete in two to three weeks and we typically find fifteen to thirty issues in the first pass on a standard mid-market report.
Yes — Hopton can work with your existing planning tool. Most FP&A engagements involve coordination with the planning tool (Anaplan, Vena, AimPlan, Adaptive, others) or with Excel-based planning if no specialist tool is in use. Hopton runs the analytics workstream and integrates with the planning data wherever it lives. We do not displace the planning tool. Many clients find that their planning tool becomes more useful when the analytical layer on top of it is properly built.
Yes — you can download the Power BI UI/UX checklist. The deck on our website is the full version. You are welcome to use it inside your own organisation. We ask that you keep the credit visible if you publish it onward, but otherwise there are no restrictions. If you want a Word or Excel version for your own checklist tooling, get in touch.
Yes, and this is one of the strongest reasons BC users move to Power BI. Multi-company consolidation in BC's built-in reporting is awkward at best. Power BI on Fabric handles it cleanly because the consolidation logic lives in the analytics layer rather than in BC. We have built consolidations across two, five, and twenty-plus BC companies. The pattern is the same; the scale changes the capacity and refresh design.
Yes, and this is one of the strongest reasons groups move analytics off Sage 200. Multi-company consolidation in Sage 200 itself is awkward. Power BI on Fabric handles it cleanly because the consolidation lives in the analytics layer. Different companies can have different chart of accounts, different currencies, different period structures, and the analytics layer reconciles them into a consistent group view. Groups running multiple Sage 200 companies typically see this as the highest-value early dashboard.
Power BI can handle VAT and tax reporting on Sage 200 for management reporting and reconciliation. Power BI can produce the trended VAT position, by company and by jurisdiction, with the supporting transaction-level detail. For the formal VAT submission itself, Sage 200's VAT module or HMRC-approved third-party tools are usually more appropriate. The Power BI layer supports the management view and helps finance teams understand and reconcile the VAT position; the actual submission happens in the systems built for that purpose. Most clients run both, with each tool used for what it is best at.
Yes, including non-standard fiscal years, 4-4-5 retail calendars, and multiple fiscal calendars in a single group (subsidiaries with different year-ends from the parent). The Date dimension supports the calendar variants and the measures use the appropriate calendar for each entity. The complexity is in the dimension design rather than the reporting. Once the dimension is built correctly, the reports adapt to whichever calendar the user is looking at.
Yes — Power BI can produce a 13-week cash flow forecast. The cash flow model combines opening cash, expected receipts (from the receivables ledger and the sales pipeline), expected payments (from the payables ledger and the operational schedule), and other known cash movements (loans, investments, tax payments). The forecast horizon is typically 12 or 13 weeks because that is the working capital management window for most businesses. The Power BI dashboard shows weekly closing cash, days-of-coverage, and exposure points. The model has to encode payment terms, which is where most businesses currently use spreadsheets.
Yes — Power BI can produce a weighted revenue forecast. The standard approach combines pipeline opportunities (weighted by stage probability) with run-rate revenue and adjustments for known wins and losses. The forecast updates as opportunities move stage. The challenge is calibrating the stage probabilities: most CRMs ship with default percentages that do not match the actual win rates by stage. The Power BI model uses your historical conversion rates to calibrate the probabilities, which produces a meaningfully more accurate forecast than the CRM defaults.
Power BI can replace most of your finance team's Excel analysis, yes. Excel-based finance analysis usually exists because the standard Sage 200 reports do not produce the views finance needs. Power BI dashboards built on a certified semantic model deliver the same analysis with current data, no manual updates, and consistent definitions. We typically retain Excel for ad-hoc deep analysis where it remains the right tool, with Power BI handling the recurring analysis and reporting. The shift saves the finance team several days a month in most engagements.
Yes — Power BI can report on customer profitability, when the ERP data supports it. True customer profitability needs revenue, direct cost, allocated indirect cost, and the customer-specific cost-to-serve. Most mid-market businesses have the first two cleanly and the second two approximately. The Power BI dashboard works with whatever data is available, and the analysis is honest about the assumptions in the indirect allocations. Customer profitability analytics is usually one of the highest-leverage outputs because it surfaces accounts that look attractive on revenue but are unprofitable in reality.
Yes — Power BI can report on debt covenants and lender reporting. The covenant reporting model captures the financial covenants from the loan agreements (leverage ratios, interest coverage, minimum liquidity) and calculates the position monthly. The dashboard shows current ratios against the covenant thresholds, with sensitivity analysis on how close the business is to breaching. For businesses with bank debt or private equity oversight, this reporting is high-stakes and benefits from automation. Many clients still produce covenant reports manually each month and Power BI replaces several days of finance team work.
Yes — Power BI can show multiple forecast scenarios. The Forecast Version dimension carries scenarios (base case, upside, downside, sensitivity scenarios). Reports show the scenarios side by side, allowing the leadership team to see the range of outcomes. For mid-market businesses with significant uncertainty (commodity exposure, regulatory change, contract renegotiations), scenario reporting is genuinely useful. For more stable businesses, the base case is usually enough and scenarios add complexity without value. The right answer depends on the business.
Yes — Power BI can track quota attainment and pacing. The Quota fact carries quota by rep and by period. The pacing measures show actual versus expected cumulative attainment through the period, with the gap to closing the period at quota. The dashboard becomes the standard reference for the weekly sales meeting. The work is in setting up the quota plan in a structured way; many organisations track quotas in spreadsheets that drift, and the data becomes the bottleneck rather than the reporting.
Power BI can read Salesforce Reports and Dashboards via the API, but the better pattern is usually to bypass them and go to the underlying data. Salesforce Reports and Dashboards are designed for in-Salesforce consumption, not as an analytical data source. The Power BI architecture works on the cleaned data in the lakehouse rather than on the Salesforce native reporting layer. Where existing Salesforce reports are well-designed, we use them as a reference for the metrics they produce, but the analytical layer is rebuilt in Power BI.
Yes - Power BI Desktop lets you view a report "as" a specific role before publishing, and the Power BI service supports testing as a specific user post-publication. We always test every RLS role against real user scenarios before go-live, since an untested RLS rule that is too permissive is a data breach waiting to happen, and one that is too restrictive breaks a business user's day.
Yes. Power Apps is available as a native visual in Power BI, so an app can sit inside a report page and read the context of what the user has selected. That means the action a person takes, updating a status, adding a note, approving a figure, happens against the exact record they were looking at, and the report can reflect the change without anyone leaving the page. It closes the gap between spotting something in a report and doing something about it.
Yes — an app can have multiple sections or a custom navigation structure. Apps support organising content into named sections with a custom order, which matters for making a large app genuinely navigable rather than presenting a long, undifferentiated list of reports. Getting this navigation structure right is one of the more overlooked aspects of good app design.
No - a Power BI app is built from a single workspace's content. Where an organisation needs to present content that spans what would naturally be several workspaces to one audience, this needs to be planned into the workspace and app structure from the outset, rather than solved after the fact.
Yes, Power BI can notify users when an app they have access to has been updated, which is useful for keeping a wide audience aware of meaningful changes without you needing to communicate every update manually.
Different audiences within the same app can see different reports, and this is one of an app's most useful capabilities. You can define multiple audiences within a single app, each seeing a different subset of the available reports, which avoids having to build and maintain entirely separate apps for groups that only need partially different content.
Yes — existing SSRS paginated reports can be brought into Power BI Report Server without a full rebuild, in most cases. Existing SSRS paginated reports (RDL format) run on Power BI Report Server largely as-is, which is one of the more practical benefits of choosing it as an SSRS upgrade path rather than migrating SSRS reports directly to the cloud service.
Yes, with the right configuration - Power BI supports external sharing of apps to guest users via Azure Active Directory B2B, subject to your organisation's tenant-level external sharing settings. This needs to be deliberately enabled and scoped, not assumed to work by default.
Yes — machine learning can predict deal win probability, with enough historical data. Models trained on past won and lost opportunities can predict win probability based on deal characteristics: account size, deal value, stage progression speed, activity volume, the rep working the deal. The output is a per-opportunity score that supplements the human judgement of the rep. The trust framework matters: the score is a flag for review, not a decision. We typically deploy these as monitoring agents on top of the certified pipeline model.
Yes — reservations can be combined with pausing, and the combination is powerful. A reserved capacity costs the same whether it runs 24 hours a day or 12. Pausing the reserved capacity outside business hours saves the variable cost on top of the reservation discount. Together they often produce 60 per cent or more savings against PAYG-without-pausing. This is the optimal cost structure for most mid-market workloads with predictable hours.
Both formats work, and we run training sessions either way depending on what suits the client. Deeper report builder training often benefits from at least some in-person time for hands-on pairing, but consumer-level training is frequently just as effective delivered remotely.
Yes — users can access Power BI dashboards from inside Business Central. 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. This is one of the more underused capabilities in BC + Power BI implementations.
Yes — you can apply the architecture without engaging Hopton. The whitepaper covers the patterns and the reasoning. Several internal Power BI teams have used it as their reference. The reason most organisations engage us anyway is that an external review brings perspective that internal teams find hard to develop on their estates they built themselves. We also bring patterns from many engagements that no single internal team will see.
Yes, apps support a custom logo, theme colour, and description, which is worth using properly rather than leaving as defaults. For an app being rolled out organisation-wide, this branding is a small effort that meaningfully affects how seriously business users take the content.
Yes — you can get the Dashboard Wireframe Kit. We share it with clients on request, no commitment required. Email hello@hoptonanalytics.com and we will send the current version along with notes on how to adapt the wireframes to your specific dashboards. The kit is a starting point, not a constraint. Most clients adapt the wireframes to fit their brand and their content, but the underlying patterns hold up across industries.
Yes — you can keep using Sage 200 reports alongside Power BI. Power BI sits alongside Sage 200's built-in reporting, not as a replacement. Many Sage 200 reports remain useful for operational tasks and continue to be used. Power BI handles the dashboards, the cross-source reporting, the multi-company consolidation, and the analytical work that Sage 200 reports do not cover. Most clients run both indefinitely. Some specific Sage 200 reports get retired over time as Power BI versions prove themselves; others stay because they are well-suited to their purpose.
You can migrate from Power BI Report Server to the cloud service later if your requirements change, and this is a common trajectory as data residency requirements evolve or are re-evaluated. Reports built for Report Server generally move to the cloud service with limited rework, though features specific to Report Server's older release cadence should be checked for compatibility.
You can run Power BI Report Server and the cloud service side by side, and this is common for organisations with mixed requirements - some reports that must stay on-premises for regulatory reasons, and others that can benefit from the cloud service's fuller feature set. Managing two platforms does add administrative overhead, which is worth weighing against the benefit of splitting content this way.
Yes — you can run the cost review yourselves, in principle. The whitepaper covers the methodology. The tooling is in the Microsoft admin portal. The five overspending patterns are recognisable once you know what to look for. The reason most organisations engage us anyway is that an external review surfaces patterns that internal teams miss because they are too close to the existing setup, and an external recommendation is easier to act on than an internal one because it is not entangled with last year's budget decisions.
Yes — you can start small and expand, and this is often the right approach. Many BC clients start with one or two priority dashboards (financial reporting and sales analytics are common starters) and extend from there as the foundations prove themselves. The architecture supports this incremental approach: the data layer is built once and serves many dashboards over time. The first eight-to-twelve weeks deliver the foundations and the first set of dashboards. Subsequent extensions are quicker because the foundations are in place.
Yes — you can start with a smaller engagement. Many Sage 200 clients start with a four-week Establish phase, which produces a written architecture and engagement plan with cost and timeline before any commitment to the build. The Establish phase is fixed price and produces value on its own (the architecture document is yours regardless of whether you continue with the build). This is the lowest-risk way to start and is the most common entry point for new clients.
Yes, through sensitivity label enforcement or through tenant-level export settings, both of which can restrict or block export for specified content or user groups. This is a common requirement for organisations with genuinely sensitive financial or personal data in their reports.
Yes — you can use multiple Business Central reporting tools at once, and most BC organisations do. The mix typically looks like: Native for documents, Jet or Power BI for finance, Power BI on Fabric for cross-source analytics. The mistake is using two tools for the same use case. The discipline is using each tool for what it does best, with clear ownership and clear retirement plans for tools that no longer earn their place.
Yes — you can use the Power BI UI/UX checklist as a template for your own reviews. The deck is the full version. If you want it in a Word or Excel format you can adapt for internal use, ask and we will share it. We only ask that you keep the credit visible if you publish a derivative externally.
Yes — migrating from Tableau, Qlik, or another BI tool to Power BI is standard work for us. We regularly migrate clients from Tableau, Qlik, Cognos, SSRS, and Excel-based reporting onto Power BI. The migration approach depends on the complexity of the current estate, the quality of the underlying data, and the number of reports in scope. We always recommend a proper semantic model rebuild rather than a like-for-like migration, because the opportunity to improve governance is best taken at migration time.
Yes — Microsoft did raise Power BI Pro pricing in April 2025. Power BI Pro went from £8 to £11 per user per month in April 2025. The increase was the first significant Pro price rise in years. If you are working from quotes or budgets prepared before April 2025, the per-user numbers will be wrong. PPU stayed at £19. Fabric capacity pricing was not changed at the same time. The Pro increase shifted the maths on the F64 viewer-licensing crossover, making higher capacities relatively more attractive than they were.
Whether app viewers need a Power BI Pro licence depends on the workspace's capacity licensing. Content in a workspace backed by Premium or Fabric capacity can generally be viewed with a free Power BI licence; content in a Pro-only workspace requires viewers to have Pro licences themselves. This licensing distinction is worth confirming during planning, since it materially affects rollout cost for a wide audience.
The core DAX and modelling skills are the same regardless of department, but the practical examples and the specific reports used in training differ significantly, and should reflect what each team will actually be building and using day to day rather than a one-size-fits-all curriculum.
No — we do not have to leave BC to get good reporting. Power BI works alongside BC, not instead of it. BC continues to do what it does well (transactional ERP, financial integrity, operational workflows). Power BI handles the analytical layer on top: dashboards, cross-source reporting, self-service analytics, advanced analytics. The two complement each other. Most BC users we work with end up with both running together permanently. Power BI is not a replacement for BC; it is the analytical layer BC was never designed to provide.
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 necessarily need your Sage 200 partner involved. Hopton can work directly with the client, accessing Sage 200 data through standard interfaces. The engagement runs more smoothly when the Sage 200 partner is informed and supportive, but it is not a hard requirement. We have run Sage 200 engagements with the partner involved, with the partner informed but not active, and without the partner in the loop. The right pattern depends on the client relationship with the partner, not on the technical work.
No — you do not need to already have Power BI before working with us. Many clients come to us before they have invested in tooling. Part of the Establish phase is assessing your current infrastructure and recommending the right platform for your needs and budget. If Power BI is the right fit, we will build it properly from the start. If a different Microsoft platform suits you better, we will say so.
You do not strictly need formal Power BI training - some people will figure out the basics themselves - but that usually produces inconsistent practice across an organisation: different people building reports different ways, some using DAX correctly and others working around it with overly complex Power Query steps, and no shared understanding of what "good" looks like. Structured training gets everyone to a consistent, correct baseline faster than informal self-teaching.
We have working relationships with the BC partner channel and we know the Jet team. We do not resell Jet or take referral fees on it. Our recommendation is based on what fits your situation, not on commercial relationships.
Yes — we do train teams on the Power BI UI/UX checklist. We run training sessions for internal BI teams, usually as a half-day workshop using one of your own reports as the worked example. People learn the list faster on real content than on slides. We can also run periodic refresher sessions as new team members join. Get in touch if you want to discuss.
Fabric capacity does not replace the need for Power BI Pro licences below F64. On any F-SKU below F64, every user who creates or views Power BI content still needs a Pro or PPU licence. F64 and above include free viewing for any user, so viewers no longer need their own Pro licence. Authors always need Pro regardless of capacity tier. This is the most commonly missed cost pattern. Buying F8 thinking it covers everything and then discovering 200 users still need Pro at £11 each is a £2,200 monthly surprise.
Hopton delivers Power BI training both as a standalone service and within projects. Training is built into every implementation engagement as standard, and we also deliver standalone training programmes for organisations that already have Power BI in place but have never had structured training, or that are onboarding a new cohort of users.
Designing the app structure is part of our standard Build phase design work, alongside workspace structure, security, and dashboard design, rather than treated as an afterthought once dashboards already exist. Deciding early who the actual audiences are and what each should see shapes both the workspace and the eventual app structure.
Hopton implements and supports Power BI Report Server deployments where a client has a genuine data residency or regulatory driver for it. We are honest that this is a smaller part of our practice than cloud Power BI and Fabric work, reflecting how much less common a genuine on-premises requirement is across our client base, but we do deliver it properly where it is the right answer.
Security and governance configuration is built into our standard Analytics Acceleration Programme rather than sold as a bolt-on. Security design happens during the Establish phase alongside architecture and dashboard planning, because retrofitting proper RLS and permissions after dashboards are already built and in daily use is materially more disruptive than designing it in from the outset.
Yes — Hopton does run its own FP&A on Power BI. Our FP&A reporting (group P&L, cash flow, working capital, headcount, KPIs) runs on Power BI sitting on Microsoft Fabric, fed from Business Central. The dashboards we use internally are built on the same patterns we deliver to clients. We are happy to walk prospective clients through our internal FP&A estate as part of the early conversation.
Honestly, no — Hopton does not specialise in Salesforce. Our heritage is Microsoft and we have deeper expertise in Dynamics 365 Sales than in Salesforce. We do work on Power BI on Salesforce and the architectural patterns transfer cleanly: the analytical layer is the same regardless of the source CRM. Where the engagement is heavily Salesforce-specific (complex Apex customisation, deep Salesforce admin work), we coordinate with a specialist Salesforce partner rather than overclaiming. Most mid-market CRM analytics work on Power BI does not require deep Salesforce specialism.
Hopton trains your team to be self-sufficient rather than dependent on us; the explicit goal is self-sufficiency. We would rather train your team well enough that they can extend and maintain their own reporting than keep you dependent on us for routine work. Continuity support exists for genuinely complex extensions and strategic development, not for tasks your own trained team should be able to handle.
Yes — Hopton does work with Sage 50, Sage Intacct, or other Sage products. Sage 50 is generally simpler to integrate (smaller scale, simpler data model). Sage Intacct is the cloud-first Sage product, cleanly API-driven, and integrates well with Fabric. Sage 1000 and other older Sage products work too, with extraction patterns adapted to the source system. Sage 200 is the most common Sage product in our work, but we have engagements across the Sage range. Email us if you are on a Sage product not specifically covered here and we will discuss the patterns that apply.
Yes — Hopton works with both Salesforce and Dynamics, with depth varying by platform. Dynamics 365 Sales is closer to our Microsoft heritage and we work on it regularly. Salesforce we work on where the analytical workstream is the focus and the Salesforce admin work is handled by an existing Salesforce partner or in-house team. The analytical patterns transfer between platforms. The architecture, the modelling, and the dashboards look similar regardless of the source CRM. The platform-specific work concentrates in the extraction and the data hygiene.
No — Looker does not only work with Google Cloud, but it works best there. Looker connects to BigQuery, Snowflake, Redshift, Postgres, MySQL, and many other databases. The deepest integration is with BigQuery, which is unsurprising given Looker is owned by Google. If your data warehouse is BigQuery, Looker is the most natural fit. If your data warehouse is on a different platform, Looker still works, but the integration advantages diminish.
No — Power BI Report Server does not get the same features as the cloud service, and the gap has widened over time. Power BI Report Server receives a subset of Power BI Desktop's features on a slower cadence (roughly every few months rather than continuous updates), and cloud-exclusive capabilities - Copilot, Fabric integration, real-time dashboards from streaming sources - are not available on Report Server at all.
Yes — Power BI has an equivalent semantic layer, but it works differently. Power BI's semantic models (formerly called datasets) sit at the workspace level and are built using the Tabular Editor or in Power BI Desktop. They support DAX measures, RLS, and centrally certified definitions. The certification mechanism is the closest equivalent to LookML's enforced consistency. The difference is cultural: LookML enforces engineering discipline by default, Power BI semantic models support engineering discipline if you choose to apply it. A well-governed Power BI estate matches what LookML enforces. A casually-governed Power BI estate does not.
No — Power BI does not only work with Microsoft data sources; it is a similar story. Power BI connects to almost everything, including Snowflake, BigQuery, Databricks, Redshift, Salesforce, and most enterprise data sources. The deepest integration is with the Microsoft stack: Azure SQL, Fabric, Dataverse, Dynamics 365. If your data and applications are Microsoft-centric, Power BI is the most natural fit. The connector library is broad enough that Power BI works with non-Microsoft sources too.
Power BI usually does not replace your budgeting and forecasting tool. Specialist budgeting and forecasting tools (Anaplan, Vena, AimPlan, Adaptive Insights, Workday Adaptive, Oracle EPM) handle the planning workflow itself: scenario building, driver-based modelling, approval cycles, model maintenance. Power BI handles the analytical and reporting layer on top of the planning data. The two work together. Many of our clients run their planning in a dedicated tool and their reporting in Power BI, with the two integrated through the lakehouse. For smaller firms whose planning happens in Excel, Power BI is the upgrade for both planning storage and reporting in one step.
Power BI does not support migrating away from Looker natively. Power BI has no built-in Looker or LookML importer, so there is no automatic conversion path between the two platforms. LookML's modelling layer and Power BI's semantic model are structured differently, which means metric definitions, joins, and dashboards have to be rebuilt rather than migrated file-for-file. That structural gap is why a Looker-to-Power BI move is best treated as a short project rather than a one-off export, even for teams comfortable with both tools.
Yes, through Azure Active Directory (Microsoft Entra ID), which handles authentication for Power BI as it does for the rest of Microsoft 365. Multi-factor authentication and conditional access policies configured at the Entra ID level apply to Power BI access as they do to other Microsoft 365 services.
RLS works largely the same way for Power BI reports built on top of Fabric data sources - the underlying mechanism is the same - but with Fabric, security can also be enforced further upstream at the data source (lakehouse or warehouse) level through Fabric's own security model, giving you a choice of where to enforce restrictions. We generally recommend enforcing security as close to the source as practical, with RLS in the semantic model as an additional, consistent layer.
The app mechanism itself works the same way regardless of whether the underlying workspace sits on Power BI Premium or Fabric capacity. What does change is the scale of content and audience complexity Fabric-based estates tend to reach, which makes deliberate app and audience planning even more important as the estate grows.
A sensitivity label can be both a visual tag and an enforced restriction. A sensitivity label can be purely informational, or it can be configured to enforce real restrictions - blocking export to Excel or PDF for highly confidential content, for example. Whether to enforce restrictions or use labels informationally is a deliberate governance decision, not a default setting.
Choosing Report Server does effectively mean giving up Power BI's AI and Copilot capabilities for content hosted on Report Server itself. Copilot for Power BI and other AI-augmented features are cloud-native and are not available on the on-premises platform. This is one of the most significant trade-offs to weigh against a data residency requirement, and it is one we discuss explicitly before recommending Report Server.
It does not directly matter which Business Central implementation partner you used. Hopton works alongside BC partners rather than replacing them. We do not need access to BC's transactional configuration. We do need access to BC data through standard APIs or, for on-premises, database access. Most engagements run smoothly when the BC partner is informed and supportive, but the analytics workstream is independent of the BC partner relationship. We have several engagements where we work with the BC partner in parallel and several where we work directly with the client without the partner involved.
Moving to Power BI Report Server generally does not reduce your overall IT overhead compared to the cloud service - it increases it, since you take on infrastructure management, patching, and capacity planning that Microsoft handles automatically in the cloud service. The trade-off is deliberate: more operational overhead in exchange for full data residency control. We are candid with clients that this is rarely a cost-saving move relative to the cloud service.
No — publishing an app does not duplicate the underlying reports. An app references the same underlying datasets and reports as the source workspace; publishing an app does not create a separate copy of the data or the report definitions. When the underlying workspace content is updated and the app is republished, app users see the updated version, not a stale copy.
Yes, RLS defined in the underlying semantic model continues to apply exactly as it does for any other consumption method. An app is a distribution and navigation layer; it does not bypass or replace the security already built into the semantic model beneath it.
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.
This applies mostly to BC SaaS, but the patterns work for BC on-premises with adjustments. The biggest differences are around extraction methods (BC SaaS uses APIs and the lakehouse connector; BC on-premises uses direct database access or SSIS) and identity (BC SaaS integrates natively with Entra ID; on-premises requires more setup). The architecture pattern downstream of the extraction layer is the same. We work with both and the whitepaper covers both.
Yes — it does work for project-based businesses on Sage 200. Project-based businesses (professional services, construction, engineering) need project profitability, work-in-progress, cost recovery, and project-level cash flow visibility. The Sage 200 data plus project management tooling (Sage 200 Project Accounting, Microsoft Project, custom systems) feeds the analytics layer. Project P&L, project pipeline, and consolidated multi-project views are common dashboards. Project businesses often find this analytics extension produces meaningful commercial improvement because project visibility in the source systems is usually limited.
Properly structured training covers both, because most real-world reporting problems involve shaping and cleaning data in Power Query before any DAX measure is written. Training that only covers visual report building without the underlying data preparation skills leaves report builders unable to extend or troubleshoot their own models.
Training matters for both people building reports and people just viewing them, though the depth differs considerably. Report viewers benefit from a short session on navigating filters, drill-through, and export options so they get real value from what has been built for them. Report builders need much deeper training in data modelling, DAX, and Power Query.
Using apps reinforces the same discipline around certified or promoted datasets rather than changing it. Certifying the datasets that feed your app's reports gives app consumers (and anyone building further reports against those datasets) confidence that what they are seeing is the trusted, governed version, which matters even more once content is being distributed to a wide, less technical audience.
Microsoft has not committed to a single direction for BC reporting, and that is a feature, not a bug. Microsoft continues to invest in Native (RDLC, Word layouts) for operational reporting and in Power BI for analytics. The architectural direction is clear: operational stays in BC, analytical moves to Power BI and Fabric. Within that, there is room for finance-specific tools like Jet to keep their place.
To avoid cognitive overload on a Power BI page, aim for three to five visuals per page, not nine to twelve. Make one of them clearly the primary insight and let the others support it. Use white space, not borders, to separate areas. Strip every visual that does not earn its place. Cognitive overload comes from too many things competing for attention, and the fix is almost always to remove rather than rearrange.
To choose a Power BI consultancy, look past the dashboard gallery to the engineering and the operating model. Ask about data modelling (star schema), DAX optimisation, deployment pipelines, performance tuning, and governed self-service including certified datasets and row-level security. Confirm who actually does the delivery, and ask them to define success in business outcomes — faster close, fewer reporting disputes, better decisions — rather than dashboard aesthetics. Firms that answer with specifics and can show their delivery method are the ones worth shortlisting.
Download a theme as a JSON file, then in Power BI Desktop go to View, then Themes, then Browse for themes, and select the file you downloaded. The theme applies to the whole report instantly, recolouring visuals, fonts, and backgrounds to match. Hopton publishes a set of free Power BI themes for exactly this purpose; no setup or add-in is required beyond Power BI Desktop itself.
To know if a Power BI report is performant enough, open the report cold from the Power BI Service. If the first page loads in under five seconds, you are in good shape. Five to ten seconds is acceptable but worth optimising. Over ten seconds is a problem and will affect adoption. Performance is part of the user experience, not separate from it. Slow reports get used less, regardless of how good the design is.
Three rules make Power BI reports accessible. Never use colour as the only signal of meaning. Always check that contrast is sufficient, particularly for grey text on light backgrounds. Test the report at different zoom levels and on different screens. Power BI has accessibility tooling built in, and the checklist has a full category dedicated to accessibility. Most accessibility issues are easy to fix once seen, and invisible until pointed out.
You do not score a report against the Power BI UI/UX checklist - we do not score. Each check is binary: pass or needs work. The output is a list of issues, prioritised, with screenshots. Scoring tempts teams to chase a number rather than fix problems. Issues are concrete, scores are not. If you must score for governance reasons, count the items needing work and track that downward over time.
Email hello@hoptonanalytics.com with a brief description of your CRM (Salesforce or Dynamics), your sales team shape, and what you are trying to improve. The first conversation is exploratory and free. If there is a fit, we propose a three to four week Establish phase that produces an architecture and a priority delivery plan.
Email hello@hoptonanalytics.com with a brief description of your finance team shape, your current FP&A cycle, your main systems, and what you are trying to improve. The first conversation is exploratory and free. If there is a fit, we propose a four-week FP&A Establish phase that produces the architecture and the priority delivery plan.
On white-label and embedded customisation, Power BI and Looker differ in that Looker is more flexible. Looker embedded looks more like part of the host application and less like a BI tool. The styling, the colour scheme, the navigation can all be controlled. Power BI Embedded is improving on these dimensions but still feels like Power BI by default. Where the analytics needs to feel native to a customer-facing product, Looker is usually the better answer.
They work together as two ends of the same pipe rather than as rivals. Power BI is the reporting layer that shows what is happening across the business; Power Apps is the action layer that lets someone capture a decision or update a record. The useful pattern is to connect them: a Power App can be embedded directly inside a Power BI report as a visual, so the moment a user spots an at-risk account or an exception, they can act on it in the same place they saw it, without switching systems or raising a separate request.
Word layouts are easier to maintain than RDLC for simple documents. Most modern BC users build customer-facing documents in Word layouts where possible and reserve RDLC for documents needing the additional control. The skill-find for Word layouts is also broader than for RDLC, which matters in mid-market organisations without dedicated BC developers.
The underlying RLS mechanism in the semantic model works the same way, but tenant-level governance features available in the cloud admin portal - centralised usage monitoring through Purview audit logs, some sharing and certification features - are more limited or entirely unavailable on Report Server. Governance has to be designed around what the on-premises platform actually supports, not assumed to match the cloud experience.
Apply sensitivity labels at the dataset level for content that needs them, propagate to derived content automatically. Microsoft Purview is the underlying tool. The discipline is deciding which datasets warrant labels and applying them consistently. The mistake is applying labels inconsistently or not at all, then hoping nothing sensitive ever flows into the wrong report. Labels are a one-time setup with ongoing operational benefit.
Unused Pro licences accumulate slowly, over time. Someone gets a licence for a project that ends. They move to a different role and stop using Power BI. They leave the organisation but the licence persists. A 200-staff organisation often has 30 to 50 inactive Pro licences without anyone noticing. At £11 per user per month, that is £3,300 to £5,500 per year of pure waste. The fix is a quarterly review of licence assignments against active usage. Microsoft provides usage reports for this. Use them.
We control external sharing of Power BI reports outside our organisation through tenant-level external sharing settings in the admin portal, which can be disabled entirely, restricted to specific domains, or left open depending on your organisation's genuine need to share with external parties such as clients or auditors. Most mid-market organisations benefit from restricting this by default and enabling it selectively where there is a real business case.
We control who can access a published Power BI app through defined audiences within the app, each of which can be assigned specific content and specific security groups or individuals, all managed from within the app publishing settings rather than through workspace roles. This lets a single app serve genuinely different audiences with different visible content from one underlying workspace.
We decide whether Report Server or the cloud service is right for you by identifying whether you have a genuine, specific requirement - regulatory, contractual, or security-driven - that rules out the cloud service, rather than assuming on-premises is inherently safer or more controlled by default. In our experience, most mid-market businesses do not have such a requirement and are better served by the cloud service's faster feature pace and lower operational overhead.
We decide who needs deep Power BI training versus a lighter overview by mapping out who will actually build and maintain reports versus who will only consume them, and training accordingly. We usually see this settle at a small group of two to five power users or analysts needing deep training, with a much wider group needing only consumer-level training.
We evaluate a consultancy's pricing transparency by asking specific questions and listening to the answers. A transparent pricing model has clear day rates, clear scope, clear assumptions, and clear handling of changes. An opaque pricing model has vague hourly rates, broad scope statements, hidden assumptions about your team's involvement, and unclear handling of changes. Ask: what is the day rate by grade; what is included in the fixed price; what assumptions about our involvement are baked in; what happens if scope changes. The clarity of the answers is itself the signal.
Email hello@hoptonanalytics.com describing your current Power BI setup and any specific concerns. We regularly review existing estates - built by us or by others - and can scope a focused security and governance assessment independent of any wider engagement.
Email hello@hoptonanalytics.com describing your current workspace and app setup, or the lack of one, and who your different report audiences actually are. We will review your current structure and recommend an audience and navigation design as part of scoping, whether as a standalone piece of work or part of a wider engagement.
Email hello@hoptonanalytics.com describing your specific data residency or regulatory driver and your current reporting setup. We will give an honest assessment of whether Report Server is genuinely the right fit before recommending it, rather than defaulting to it just because it has been asked for.
Email hello@hoptonanalytics.com describing your current Power BI setup (or lack of one), your team size, and roughly how many people need report builder versus consumer-level training. We will scope a training programme, whether standalone or as part of a wider implementation.
Power BI reports that span Business Central and other systems are almost always best handled with Power BI on Fabric. Native cannot do it. Jet struggles beyond BC. Power BI direct gets there but the architecture stops scaling. Fabric is built for multi-source analytics and BC's data sits comfortably alongside Shopify, Xero, CRM and others. If you have any meaningful multi-source need, the long-term answer is Fabric.
We handle Power BI version control when multiple people update a workspace before an app republish through the same workspace-level version history and review discipline that should already govern production content, combined with a clear internal process for who reviews and triggers the app republish. The app republish step is a natural checkpoint to enforce this review, and we build that checkpoint deliberately into governance design.
Three questions decide which Business Central reporting tool you need. Who is the report for? What data sources does it touch? What is the ambition (operational, self-service analytics, advanced modelling)? Match each report to those answers, and the right tool surfaces. The deck has a full decision framework. Most BC organisations do this assessment once and find they are using the wrong tool for at least one use case.
F8 is the most common production starting point for mid-market workloads. F2 and F4 are for trials and very small production environments. F16 makes sense when you have multiple departments running concurrent demanding workloads. The honest answer is to size from real data: run a representative workload on a trial capacity for two to four weeks and monitor utilisation. Microsoft provides a Capacity Metrics app. Guessing produces over- or under-provisioning, both expensive in different ways.
We monitor who is actually accessing what in Power BI through Power BI's built-in usage metrics reports, and more comprehensively through the Microsoft Purview audit log, which records detailed activity across the tenant - who viewed, edited, or shared specific content and when. We set this up as standard on governance-focused engagements, since usage data is also valuable for licensing and content rationalisation decisions.
To run a competitive consultancy selection process well, brief all firms identically. Set clear evaluation criteria in advance and score against them. Make the same time available to each firm for discovery questions. Allow each firm to interview your team to ground their proposal. Compare the proposals against the criteria, not against each other in isolation. Run reference calls before final selection, not after. Negotiate contract terms with the preferred firm, not all of them simultaneously. The discipline of a clean competitive process produces better outcomes than relying on instinct or relationships alone.
To shortlist Power BI consultancies to evaluate, aim for three to five firms as the right shortlist size. Fewer means insufficient comparison; more means too much evaluation effort for the buyer. Sources for the shortlist: the Microsoft Partner Network listings (filtered by Solutions Partner for Data and AI), recommendations from peers and your existing Microsoft account team, the FAQ libraries and content of credible firms (which signals depth of expertise), and named referrals from other consultancies you trust. Avoid shortlists driven by volume of marketing or by which firms appear most prominently in search results; both signal marketing investment more than capability.
We stop someone accidentally deleting or overwriting a critical Power BI report through a combination of workspace role restrictions (limiting who has Contributor or Admin rights on production workspaces), version history (Power BI retains previous versions of reports, allowing rollback), and, for the most critical content, a deployment pipeline process that requires review before changes reach production.
Microsoft Solutions Partner designations are listed on the partner's Microsoft profile and can be verified through the official Microsoft Partner Network listing. Individual certifications can be verified through Microsoft Learn (each certified person has a verifiable transcript). Pyramid Analytics and other vendor certifications can usually be verified through the vendor's partner directory. Verification takes ten minutes and is worth doing for any serious engagement. A consultancy whose claimed credentials cannot be verified deserves a sceptical second look.
We decide what goes into an app versus what stays workspace-only by identifying which reports are genuinely finished, validated, and intended for a specific audience, versus which are still in development or intended only for the report-building team. We treat this as a deliberate curation decision during design, not an afterthought once reports happen to exist in a workspace.
We decide what level of security a given Power BI deployment actually needs by understanding what data is genuinely sensitive (financial detail, personal data, commercially confidential information), who legitimately needs to see what, and what the real consequence of over-exposure would be. This is a discovery conversation, not a checklist applied uniformly to every client.
We handle Business Central schema changes between versions carefully. BC's data structure can change meaningfully between versions, particularly during major Wave releases. Extraction patterns built against one version may need adjustment when the source upgrades. The lakehouse architecture protects you from this: changes are absorbed in the Bronze and Silver layers, with Gold staying stable. Reports continue to work. The maintenance work happens in the data layer, not in the report layer. This is one of the strongest arguments for the architecture.
We handle reforecasts mid-year by treating each forecast as a separate version in the Budget fact, tagged with the forecast date. Reports show the original budget, the latest forecast, and actuals against both. Comparison across forecasts (March forecast versus June forecast) surfaces how the leadership team's view of the year has evolved. For mid-market businesses with quarterly or rolling forecasts, this is usually the right pattern. The model preserves history rather than overwriting, which preserves the audit trail.
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.
BC's API and direct database access can struggle with heavy analytical queries, particularly across long history or large fact tables. The system is optimised for transactional behaviour, not analytical scans. For light to moderate analytics on recent data, BC direct queries work. For heavy analytics across years of history, the load on BC affects transactional users. The fix is to extract the data into a separate analytical layer (lakehouse or warehouse) and run analytics there, which is what Fabric provides.
Copilot fits with Dynamics 365 Sales analytics at two layers. Copilot inside Dynamics 365 Sales helps sales reps with summarisation, opportunity insights, and email drafting. Copilot in Power BI sits on top of the analytical layer and helps sales leadership query the data conversationally. Both run on Fabric capacity. The combination is genuinely useful when the underlying data is governed and the certified semantic model is in place. Without those foundations, both Copilots produce confident-sounding outputs that should not be trusted.
Hopton engages on BC analytics through a phased delivery. Most engagements start with a four-to-six week Establish phase: we audit your BC environment, agree the priority dashboards with your finance and operations leaders, design the architecture, and produce a written engagement plan with cost and timeline for the Build phase. Build is typically eight to twelve weeks for a production first release. Continuity is the optional ongoing engagement that maintains and extends the platform after launch. Most BC clients stay in Continuity because the analytics needs evolve with the business.
Hopton engages on BC implementations starting with a four-week scoping engagement that produces the architecture, the priority domain list, and the cost and timeline. From there, the build is typically eight to twelve weeks. Continuity is the optional ongoing engagement after launch. We work alongside existing BC partners (we do not displace them on the ERP side). Many of our BC clients come to us through their BC partner.
Hopton engages on BC reporting decisions in two ways. A reporting strategy engagement, two to three weeks at fixed price, covering audit and tool selection. We produce a written reporting strategy with tools, audiences, and reasoning. Or full delivery, where Power BI or Fabric is the right answer and we build it. We work alongside whatever else stays in the mix (Native, Jet) without trying to replace it.
Most clients start with a four-week FP&A scoping engagement: discovery of the current cycle, the priority reports, the source systems, and the architecture. The Build phase runs 6 to 10 weeks: the priority FP&A reports, the lakehouse foundations, the semantic models. Continuity is the optional ongoing engagement after launch. We work alongside the existing finance function rather than replacing it. The finance team continues to run the cycle; we deliver the analytical layer that makes the cycle faster and cleaner.
Most clients start with the Power BI Health Check, a two-week fixed-price engagement that audits your existing estate against the architecture standards in the whitepaper. Output is a written report with prioritised recommendations. From there, the work usually splits into modelling improvements, workspace restructure, and governance. The scope depends on what the Health Check surfaces.
A two to three week structured cost review covering all your Power BI and Fabric spend. Output is a written report with: current cost breakdown, sizing recommendations, identified overspending patterns, and a prioritised list of changes with the savings each one delivers. Most reviews surface double-digit-percentage savings without losing capability. Fixed price, fixed output, no obligation to use us for the implementation.
Most clients start with the Self-Service Readiness Assessment, a two-week fixed-price engagement that audits your existing setup against the five foundations. Output is a written report identifying which foundations are in place, which are missing, and a sequenced plan for closing the gaps. From there, the work splits into foundation work (certified models, governance, integration) and rollout work (training, audience tiering, change management).
Hopton's approach is Microsoft-first: we build on the Microsoft stack: Fabric, Power BI, the Lakehouse Connector, and Copilot. The advantage is no third-party dependency: you own the architecture and the platform sits on the same Microsoft stack as your other M365 investment. The disadvantage is more upfront work than a packaged solution like Cosmos. The trade-off favours Hopton's approach when you have multi-source needs or AI ambitions, and favours packaged tools when you have neither and want speed.
Looker is significantly more expensive at typical mid-market scales. Looker pricing is platform-based with per-user add-ons; mid-market deployments commonly run into multiple tens of thousands of pounds per year before user counts get large. Power BI Pro at £11 per user per month is far cheaper for the same audience. Even Power BI Premium or Fabric capacity at the F64 tier (around £6,400 per month) is usually less than a comparable Looker deployment. Looker's pricing reflects its positioning at the engineering-led, embedded-analytics, larger-enterprise end of the market.
Microsoft's Business Central analytics roadmap is increasingly Fabric-centric. The investment is going into Lakehouse Connector improvements, Fabric integration, and Copilot inside BC. If your strategy is BC plus Power BI on Fabric, the roadmap is in your favour. If your strategy depends on Native RDLC for analytics or on third-party tools that compete with Fabric, the roadmap is mostly orthogonal to your plans. The roadmap does not invalidate other approaches but it does signal where the integrated experience will be best.
Power BI connects to Sage 200 through one of three options. Direct database connection (for on-premises or partner-hosted Sage 200, where SQL Server access is available). Sage's web API (for cloud-hosted Sage 200, where direct database access is not). Scheduled exports into a staging area, then loaded into Fabric. Most engagements use the first or second option. The data lands in Fabric Bronze, gets cleaned and structured in Silver, and reaches Gold as business-ready facts and dimensions for Power BI semantic models.
Power BI builds a customer 360 view across CRM and ERP by integrating CRM and ERP data on a common Customer dimension. The CRM provides relationship, opportunity, and activity data. The ERP provides actual revenue, profitability, payment behaviour, and product mix. The Power BI customer 360 dashboard shows both views together: the relationship picture from CRM and the financial picture from ERP. For most mid-market businesses, this is the first time the sales leadership and the finance leadership are looking at the same customer view.
Power BI handles Salesforce custom objects and fields the same way as standard objects. The challenge in Salesforce is rarely the technical extraction; it is the proliferation of custom fields and objects accumulated over years. A typical mid-market Salesforce org has hundreds of custom fields, many of them unused or duplicated in purpose. Part of the early engagement work is identifying which custom fields are operationally meaningful versus which are legacy. Bringing every custom field into the analytical layer produces unusable reporting.
Power BI handles budget versus actual reporting through a Budget fact aligned to the same Account, Department, and Entity dimensions as the Actuals fact from the ERP. The model calculates variance (actual minus budget) and variance percentage. Reports show the P&L with budget, actual, and variance columns, with drill-throughs to the underlying transactions. The standardisation is what most businesses lack: budgets in Excel against actuals in the ERP, with the comparison done manually each month and reconciliation effort consuming finance team time. Encoding the comparison in Power BI makes it routine.
Power BI handles currency translation through the standard accounting conventions: P&L items at average rate, balance sheet items at closing rate, with the difference flowing to a currency translation reserve. The Power BI model encodes the translation logic and the dashboard shows entities in their reporting currency, the group consolidated currency, and the translation impact. For groups with significant overseas operations, currency translation can be a material driver of reported results, and the dashboard makes the impact transparent rather than hiding it in the consolidation.
Power BI handles intercompany eliminations in consolidation through a model that encodes the elimination rules: matching intercompany transactions across entities and netting them off in the consolidated view. The complexity is identifying intercompany transactions reliably, which depends on the source data being tagged appropriately. Some ERPs handle this well (BC, NetSuite, SAP) and some require additional effort. Where the source data is weak, the Silver layer in the lakehouse is where the matching gets done. Once encoded, eliminations run automatically each month.
Power BI handles multi-entity consolidation through the standard consolidation pattern: each entity's actuals and budgets flow into the model with appropriate eliminations (intercompany trading, intercompany debt). Currency translation is applied where entities report in different currencies. Reports show entity-level detail and consolidated views from the same model. For mid-market groups with several legal entities, this is usually one of the highest-stakes uses of Power BI because the consolidated reporting is the basis of the board pack and the lender reporting.
Power BI itself does not automatically apply GDPR-specific protections; it is a reporting tool operating on data that may include personal data, and GDPR compliance depends on how that data is sourced, secured, and governed across your wider estate, not on a Power BI setting alone. RLS, sensitivity labels, and proper access control all contribute to compliance, but the underlying data governance discipline matters more than any single Power BI feature.
Power BI handles sales cycle analytics through cycle time measures: average days from lead to opportunity, opportunity to qualified, qualified to closed-won. The reports show cycle time by deal type, by rep, and by customer segment, with trends over time. Lengthening cycle times are usually an early warning of deal quality issues or pipeline weakness. The analysis depends on the historical stage timestamps, which both Salesforce and Dynamics capture by default.
Power BI handles variance commentary and explanation beyond just the numbers - the variance numbers are the easy part. The harder part is the commentary explaining why the variances occurred. Power BI does not write commentary, but it can structure the data to make commentary easier: variances ranked by size, drill-throughs to the specific transactions driving variance, and historical context (is this variance pattern recurring or new). Some clients use Copilot in Power BI to draft commentary on the largest variances, with the finance team reviewing and refining.
Power BI integrates with Dynamics 365 Sales through Dataverse, the underlying data platform. Dataverse exposes Dynamics data through native Power BI connectors and through Microsoft Fabric's direct integration. The Fabric route gives you the cleanest path: Dynamics data flows into OneLake automatically, with the Dataverse schema reflected as Delta tables, ready for Power BI semantic models. The integration is genuinely tighter than any other CRM-to-BI integration because both products are Microsoft.
Power BI integrates with HR systems through scheduled extraction from the HR system (Workday, Sage People, BambooHR, Personio, BrightHR, or similar) into the lakehouse. The Headcount fact captures position, individual, location, department, and start and end dates. Joining to the payroll or finance data gives the cost view. The integration is straightforward where the HR system has exportable data; for older or bespoke HR systems the extraction is more involved. The pattern is well-established.
Power BI integrates with Salesforce through scheduled extraction from the Salesforce APIs into the lakehouse. Salesforce has a mature API set (REST API, Bulk API, and increasingly the Data Cloud surface) that supports both standard objects (Account, Contact, Opportunity, Lead) and custom objects. The Power BI connector handles smaller volumes directly. For mid-market estates with significant data and a need for good performance, the right pattern is usually scheduled extraction into Microsoft Fabric, with Power BI semantic models on top.
Power BI has mobile apps for iOS and Android with offline support and push notifications. Reports designed for mobile (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. The design discipline is to build mobile-first views deliberately rather than expecting desktop reports to work well on a small screen.
Power BI on BC compares favourably to using Excel and Power Query directly: Power Query in Excel works for small-scale, individual reporting. It does not scale to shared, certified, governed reporting across an organisation. Excel files become stale, definitions drift between users, and the same metric appears with different numbers in different files. Power BI on a certified semantic model produces one definition, current data, and consistent numbers across the user base. Excel remains useful for ad-hoc analysis and reconciliation; Power BI handles the recurring reporting that needs to be trustworthy across the business.
Power BI reports on sales pipeline through an Opportunity fact with stage, value, owner, and time tracking. The pipeline dashboard shows total pipeline value, pipeline by stage, weighted forecast (value times probability by stage), and movement against last week or last month. Drill-throughs show the opportunities behind every number. The work is in defining the stages consistently across the business and tracking opportunities through their stage transitions over time. The historical stage transition data is what enables forecast accuracy analytics later.
Power BI reports on sales rep activity through an Activity fact tagged to rep, account, and opportunity. The dashboard shows calls, emails, meetings, and demos by rep, with the link to outcomes. Activity-only dashboards are common but they have a problem: they reward reps for activity volume regardless of outcome quality. The right pattern is activity in context with outcomes (deals progressed, opportunities created, deals won), so the dashboard supports the right management conversation rather than rewarding the wrong behaviours.
Power BI reports productivity and people-cost ratios through common derivations including revenue per employee, gross profit per employee, people cost as a percentage of revenue, and ratios specific to the business model (in PS firms: utilisation and realisation; in retail: revenue per labour hour). The Power BI dashboard tracks these alongside budget and historical baselines. They are often the most useful productivity indicators for the leadership team because they connect the headcount investment to the financial output.
Power BI reporting often works well alongside your existing BC partner. Most BC partners are strong on the ERP side and lighter on analytics. We work alongside the existing partner rather than displacing them. The ERP work continues in their hands and the analytics work runs in parallel. We have several clients who come to us through their BC partner because the partner does not want to take on the analytics workstream themselves.
Power BI supports sales win/loss analysis through a structured Loss Reason dimension applied at deal close. Reports show win rates by deal type, customer segment, competitor, and rep. The most useful win/loss analytics is loss-reason-by-stage: where in the cycle are deals being lost, and to whom. Patterns surface that inform sales enablement, product positioning, and pricing. The data quality issue is usually that loss reasons are filled in inconsistently or skipped. The reporting can flag missing loss reasons to sales managers, which improves data quality over time.
Power BI tracks lock-up and working capital through a model that captures debtor days, creditor days, and inventory days (where relevant). The dashboard shows the working capital cycle in days, the trend, and the cash impact of changes. For mid-market businesses, every day of working capital improvement is meaningful cash. Surfacing the trend, with the underlying drivers, is one of the most actionable financial outputs Power BI produces. The data lives in the ERP. The integration is straightforward.
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.
Driver-based forecasting builds the forecast from operational drivers (sales volume, conversion rate, average price, headcount, productivity) rather than from financial line items directly. The drivers feed the forecast through documented logic. Power BI shows the drivers and the forecast outputs together, allowing the leadership team to see what assumptions are driving the numbers. The model itself usually lives in the planning tool; Power BI presents it. The benefit is that the conversation moves from 'what is the forecast' to 'what assumptions are we making', which is a more useful conversation.
Multi-company consolidation works cleanly, and it is one of the strongest reasons to move analytics off Sage 200. Multiple Sage 200 companies feed into the same data layer in Fabric, with consolidation logic in Silver and Gold. The consolidated view shows the group P&L, balance sheet, and operational metrics across all entities, with the ability to drill back into specific companies. Multi-company is awkward in Sage 200's built-in reporting. It is straightforward in Power BI on Fabric.
The Business Value Question applies to self-service authors the same way it applies to the central team: self-service authors building content for an audience need the same discipline - name the decision, name the owner, name the action. Without it, self-service produces interesting reports that change nothing. The BVQ does not have to be heavy for self-service. A short version asking the four key questions is enough. The discipline is the value, not the document length.
The Fabric-capacity-without-Pro-licence overspend happens when an organisation buys Fabric F8 expecting it to cover everything. They then discover that every author and every viewer below F64 still needs a Pro licence at £11 per month each. Their actual monthly cost is £1,050 for the capacity plus another £1,500 to £2,500 in Pro licences nobody planned for. The fix is to model the full licensing cost before buying. Decide whether to size up to F64 or stay below and budget for per-user licences.
Power BI has a gentler entry curve and a steeper advanced curve. A business user can be productive in Power BI within days; mastering DAX and the deeper architecture takes years. Looker has a steeper entry curve (you need SQL and LookML) and a flatter advanced curve once the foundations are in place. The right comparison depends on who is going to use the tool. For business users, Power BI's entry curve matters most. For data engineers, Looker's flatter advanced curve matters most.
Both vendors price embedded analytics differently from internal use, so the licensing for embedded compares on that basis. Looker pricing for embedded is more granular and works better for SaaS applications with many end users. Power BI Embedded uses Premium capacity (or Fabric) which can be efficient at scale but expensive for low-volume embedding. The right answer depends on your end-user volume and the unit economics of your SaaS product. Both vendors quote on a case-by-case basis for embedded scenarios; published list prices are not the right starting point.
The Power BI UI/UX checklist is one of the working standards we apply on every Hopton delivery, fitting into the wider Hopton Analytics Acceleration Programme. It runs at three points in our build process: design, review and refine. Clients on the AAP get the checklist applied to every report we ship, by default. The same standards apply to your reports as to the ones we build for our own demonstrations.
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.
Sector experience is more important than buyers usually realise. Sector experience translates directly into faster discovery, better requirement understanding, and architectural patterns that work for the specific data shape your business uses. A consultancy that has done five retail engagements understands retail data; one that has done none will spend the first half of the engagement learning what your business actually does. Sector experience is one of the strongest predictors of engagement success and is worth paying a premium for, where the premium exists.
Decision Adoption Rate is measured through periodic sampling. Every quarter, take a sample of the recommendations from BI content over the previous period, and check whether action followed. Action means: the recommendation was acted on (yes or no). The percentage is the rate. The mechanism is light: an analyst spends a day per quarter walking through a sample with the relevant business owners. The number itself is less important than the trend over time.
Power BI Report Server differs from the regular Power BI service in where content lives and how it is accessed. Power BI Service is a Microsoft-hosted cloud platform with continuous feature releases and cloud-native capabilities like Copilot integration. Power BI Report Server is self-hosted, updated on a much slower, more deliberate release cycle, and lacks many of the newer cloud-only features, in exchange for keeping data entirely within your own infrastructure.
Power BI Report Server is licensed through Power BI Premium (per capacity) licensing or through SQL Server Enterprise Edition with Software Assurance, rather than the per-user licensing model used for the cloud service. This licensing structure should be confirmed directly with Microsoft or your licensing partner, since specific terms and eligibility can change.
RLS is configured through roles defined in the semantic model, each with a DAX filter expression (for example, restricting a sales table to rows where region equals the current user's assigned region), and then mapping specific users or Azure Active Directory groups to those roles in the Power BI service.
A workspace is where content is built, tested, and collaborated on; it is inherently a working environment and usually includes draft or in-progress reports alongside finished ones. An app is a separate, read-focused distribution layer built from a workspace's content, letting you control precisely what a wider audience sees without exposing the workspace itself or requiring workspace-level roles.
FP&A reporting is high-stakes (the board pack, lender reporting, statutory reporting) and the data quality bar is higher. The numbers have to reconcile to the audited accounts, and the variance commentary has to stand up to scrutiny. The architecture is the same as for operational analytics; the testing and certification effort is more intensive. The Trust Storytelling Delivery Checklist applies to every FP&A output and the Business Value Question shapes which reports get built. Both are covered in our Data Governance FAQ.
The Hopton checklist differs from Microsoft's own Power BI design guidance in emphasis: Microsoft's guidance is mostly about what is possible. Our checklist is about what is sensible. The two are different. Microsoft will tell you how to use bookmarks, custom visuals or themes. The checklist tells you when to and when not to. It is opinionated where Microsoft is permissive, and that is where the value is.
Workflow integration is implemented with Power BI in Teams as the default surfacing approach: dashboards visible in the channels users already inhabit. Email subscriptions delivering the headline numbers without requiring navigation. Embedded analytics in the line-of-business application where decisions get made. Mobile views for users who work away from a desk. Each integration point reduces the friction between question and answer. The aim is BI that comes to the user, not BI that requires the user to come to it.
A BC on Power BI implementation takes eight to twelve weeks for a production-ready first release with a single BC source and the priority reporting domains covered. Multi-source implementations or unusual data volumes extend the timeline. The eight-to-twelve week figure assumes a focused engagement with prioritised reporting needs and a working Microsoft estate. Stretched implementations (multiple competing priorities, scope creep, parallel workstreams) take longer.
A Business Central on Power BI implementation takes eight to twelve weeks for a production-ready first release with the priority dashboards covered. Faster if BC is straightforward and the priorities are clear. Slower if multiple BC companies need consolidating, non-BC sources need integrating, or governance overhead is heavy. The eight-to-twelve week range covers most mid-market BC implementations. Larger or more complex environments take longer; smaller and tidier ones can be quicker.
A CRM Power BI rollout takes six to ten weeks for the priority pipeline and rep performance dashboards. Three to six months for a full estate including customer 360, win/loss analysis, and the integrated revenue forecasting model. The pipeline dashboard goes live first because it is the one the sales leadership reviews weekly. The customer 360 work usually requires the ERP integration and is the longer thread.
A governed Power BI environment - with a proper semantic model, certified dashboards, row-level security, and adoption support - typically takes eight to twelve weeks in the Build phase, preceded by a four-week Establish phase. Simpler scopes can be faster; more complex data environments take longer. We scope precisely before committing to a timeline.
A Sage 200 Power BI implementation takes eight to twelve weeks for a production-ready first release. Faster if Sage 200 is straightforward (single company, clean data, focused priorities). Slower if multiple companies need consolidating, additional sources need integrating, or data quality work is significant. Most mid-market Sage 200 engagements come in within the eight-to-twelve week range. Larger or more complex environments take longer.
A successful self-service rollout typically takes nine to twelve months for the change to bed in. Shorter than that, the foundations are not in place. Longer than that, the momentum dissipates and you have to reset. The technology can be deployed in weeks. The behaviour change takes longer, because it depends on user habits, workflow integration, and trust. The framework covers both, because the technology piece without the behaviour piece is the standard failure pattern.
An FP&A Power BI rollout takes six to ten weeks for the priority reports if the underlying ERP and budget data are clean. Longer if data foundations need work first (multi-entity consolidation, currency translation, headcount system integration). The work often surfaces data quality issues that have been quietly tolerated for years. Solving them once is part of the value: the FP&A reporting becomes reliable, and the underlying data becomes useful for everything else.
A first review of a typical mid-market Power BI report takes ninety minutes to two hours. That assumes someone other than the builder is doing the review and is prepared to take notes as they go. A second-pass review after fixes lands at thirty to forty-five minutes. Reports with more than ten pages or unusual visual choices take longer. Reports that have already been reviewed once often need just a quick spot-check.
Report builder training typically takes meaningfully longer — spread across several sessions over two to four weeks, covering data modelling fundamentals, DAX from basic to intermediate level, Power Query transformations, and report design principles. Building genuine DAX competency takes sustained practice, not a single workshop.
Report consumer training typically takes a single focused session, usually two to three hours, covering what most report consumers need: navigating the specific dashboards built for them, using filters and slicers, and understanding what the numbers mean. Longer sessions are rarely necessary for this audience.
The procurement process should take two to six weeks for most mid-market engagements. Shorter than two weeks usually means you are not doing enough diligence; longer than six weeks usually means the procurement is becoming the engagement and the firm you are evaluating is losing momentum. Within that range, the right cadence is: initial conversation, scoping discussion, written proposal, references, contract negotiation, signing. Each phase should produce something concrete. If a phase drags without producing output, that is a signal.
The whitepaper covers more than fifty distinct BC extraction patterns across BC entities and use cases. Sales transactions, inventory ledger entries, item movements, customer aging, supplier aging, dimension breakdowns, multi-company consolidations, currency translations, year-end balances, period-over-period comparisons, and so on. The whitepaper documents the pattern, the entity involved, the typical destination shape, and the gotchas. Most BC implementations use a subset of these patterns, but the library covers most situations.
A report should use one font family, in three or four sizes. Three colours used meaningfully, plus a neutral palette for everything else. The discipline is harder than it sounds. Most over-coloured reports are not built that way deliberately. They drift there over time as different stakeholders ask for different visuals. The annual review is when you pull the colours back into line.
You should have one model per business domain, many reports per model. The pattern is one finance model serving all finance reports, one sales model serving all sales reports, one operations model, and so on. The temptation is one big model serving everything. That works at small scale and breaks at large. The temptation is also one model per report. That guarantees inconsistency. One per domain is the sweet spot for most mid-market organisations.
Neither extreme — one workspace for everything, or many — works well. A single workspace for an entire organisation makes permission management unwieldy and increases the blast radius of a mistake; a separate workspace per report fragments governance and makes reuse of shared datasets harder. We typically structure workspaces around business functions or departments, each with a clear owner and a defined publishing process.
Pausing capacity can save around 50 per cent of compute cost for workloads that only run during business hours. Reports refresh overnight and pipelines run on schedule, but the capacity does not need to be active for the rest of the time. Pausing overnight and at weekends typically halves the monthly bill where workloads allow. The automation is mature and straightforward. This is the single largest unrealised saving in most mid-market Fabric deployments.
Annual reservations save around 20 per cent off PAYG list prices. Three-year commitments through an Enterprise Agreement can save up to 41 per cent. If you are confident in your sizing and you plan to keep the capacity running, reservations are usually the right call. The risk is reserving capacity you do not need. The right approach is to size the capacity from real data first, run it on PAYG for a quarter to confirm, then reserve once the sizing is proven.
The cost of a Power BI consulting project depends on scope, but here is a real anchor. A standalone governed Power BI build, semantic model, certified dashboards and row-level security, typically runs eight to twelve weeks of delivery after a four-week Establish phase. Where clients want ongoing capability rather than a single project, our Analytics Acceleration Programme gives a clearer indicative cost: a Foundation-Focused tier for 25 to 100 people runs around £52.7k, Foundation-Standard for 100 to 500 people around £73.9k, and a full Platform tier for 500-plus people around £114.5k, each over a typical 24-month term including delivery and an ongoing monthly rhythm afterwards. As a rough comparison point, that works out to roughly £34.2k in year one against a full-time analytics hire costing £4.1k to £5.9k a month in employment cost alone, before you have covered BI, governance and architecture skills a single hire will not have. We agree the fixed price and fixed scope with you before any commitment, so there are no surprises once delivery starts.
The cost of a Power BI project in the UK mid-market depends on scope, and few firms publish prices, but as honest ranges: a focused proof-of-value (one governed dataset and a key report) is typically a few weeks and a low-five-figure budget; a departmental rollout with data engineering and training is usually a few months and mid-five figures; an organisation-wide programme runs longer and is best phased. The cost driver is data complexity, number of source systems, stakeholder alignment and governance — not the number of dashboards.
You should rerun the Power BI checklist on an existing report whenever the report changes meaningfully. New page, new measure category, new audience. Also rerun annually as a baseline check, even if nothing has changed. Standards drift and reports that were excellent two years ago may not be now. The annual review is also the right moment to ask whether the report is still being used at all.
Access to workspaces should be governed through Entra ID groups, not individual user assignments. Create groups for each role (Finance Authors, Finance Viewers, Sales Authors, etc.) and assign the groups to workspaces. New starters get added to the right groups based on their role and inherit the right access automatically. Leavers get removed from the groups and lose access automatically. Individual user assignments accumulate and are easy to forget. Group-based access is sustainable.
At scale, workspaces should be structured as Dev, Test, and Prod workspaces per domain. Finance Dev, Finance Test, Finance Prod. Sales Dev, Sales Test, Sales Prod. The pattern protects production from accidental changes and gives you a place to test changes before they affect users. The cost is some workspace overhead and the discipline of using deployment pipelines. The benefit is that change becomes routine rather than risky.
Yes — if you are on Azure or the Microsoft stack, you can pick Power BI with high confidence. The integration of Power BI with Azure, Fabric, OneLake, M365, and Dynamics is deep enough that the choice becomes obvious. Looker on Azure works but you lose most of the integration advantages and add a third-party vendor relationship. The factors that might still pull you to Looker on Azure: a heavy embedded analytics requirement for a SaaS product, an engineering culture that strongly prefers code-first BI, or a deliberate multi-cloud strategy.
On Google Cloud, Looker is a strong default, particularly if your data warehouse is BigQuery. Looker plus BigQuery is one of the cleanest BI architectures available; the integration is deep and the performance is good. The factors that might still pull you to Power BI: a Microsoft-heavy application stack (M365, Dynamics), a cost preference for Power BI's lower licence cost, a preference for self-service authoring, or significant existing Power BI investment. The Google Cloud default is strong but not absolute.
BC Native reporting is included with Business Central, which is not the same as free. The cost is in hours: maintaining RDLC layouts, fixing them when BC versions change, and finding people who can work with them. The skills are scarcer than they used to be. Total cost of ownership is real even when there is no licence line item.
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.
Hopton's training is tailored to your specific environment, not generic. We build training sessions around your actual data models, dashboards, and business context rather than delivering a generic off-the-shelf course, because training that uses real, relevant examples transfers far better than abstract exercises.
Jet is partly a competitor to Power BI. They overlap on BC analytics, but the centre of gravity is different. Jet is finance-led, Excel-shaped, and BC-focused. Power BI is broader, supports more sources, and serves a wider audience. Many BC organisations use both. Jet for finance, Power BI for everyone else. That is a sensible split, not a contradiction.
Yes — Jet is still being invested in. Jet's owner, insightsoftware, continues to ship updates. The product is mature rather than declining. The strategic question for BC organisations is not whether Jet will keep working but whether it remains the right tool as ambitions grow. For the use cases it serves well, it remains a solid answer.
LookML is not strictly better than DAX; the comparison is unfair because they solve different problems. LookML is a modelling language for defining the semantic layer. DAX is a calculation language for defining measures within a model. Power BI uses DAX inside its semantic models; Looker uses SQL aggregations defined in LookML. Both have learning curves. DAX is famously tricky for newcomers; LookML requires SQL fluency. Neither is universally better. The right comparison is between the overall modelling experience, not the languages in isolation.
Whether Looker is worth the higher cost is sometimes yes, sometimes no. For organisations where embedded analytics is a core product capability, Looker's pricing is rational because the alternative is building an analytics layer in-house. For organisations doing internal BI on top of a Google Cloud data warehouse, Looker's cost is harder to justify against Power BI for the same outcomes. The cost-benefit calculation depends on what you actually need the platform to do. Buying Looker for use cases that Power BI handles equally well is paying a premium for capability you do not use.
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.
No, and the LinkedIn posts suggesting Microsoft is moving everyone off ODBC to ADBC have the scope wrong. ADBC is a genuinely faster connectivity option for the systems that support it, but ODBC is not being removed, and the great majority of Power BI connections are unaffected. It is worth understanding the difference so you can take advantage of ADBC where it helps, without acting on a claim that overstates what is actually changing.
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 Report Server is not automatically the right choice just because you already have SSRS. If your current SSRS reports are working well and there is no compelling reason to move to the cloud, Report Server is a reasonable, lower-disruption upgrade path. But if nothing is forcing an on-premises requirement, the cloud service is usually the better long-term choice given its faster feature pace and lower infrastructure overhead.
Power BI Report Server and SSRS are closely related but not identical. Power BI Report Server evolved from SSRS and can host the same paginated reports SSRS ran, alongside Power BI reports, in a single on-premises platform. Organisations already running SSRS often see Power BI Report Server as a natural upgrade path that adds Power BI reporting without giving up on-premises control.
Yes — Power BI is strong enough for CRM-grade reporting. The volume challenge in CRM is rarely the size of the data; it is the data quality and the modelling. Pipeline records that have not been updated for months. Opportunities tagged with the wrong stage. Account hierarchies that have drifted. Power BI handles the volumes well; the work is in the Silver layer where the data quality issues get cleaned and the modelling decisions get made. Most CRM Power BI estates that struggle have a data quality problem (uncleaned source data, no governance) rather than a Power BI problem.
Power BI is the right tool for most mid-market UK businesses on Sage 200, yes. Power BI integrates with the Microsoft 365 stack most Sage 200 users already have, handles the cross-source reporting Sage 200 cannot, and scales economically through to multi-channel and multi-company environments. There are alternatives (Microsoft Excel with Power Query, third-party Sage-specific tools, dedicated BI platforms), and we cover the comparisons on a case-by-case basis. Power BI is the most common answer because it usually fits the requirement and the budget.
Power BI training is not a one-off event; both an initial programme and periodic refreshers work best. Power BI itself evolves with new features, and organisations bring on new staff who need the same grounding the original cohort received. We build refresher sessions into ongoing Continuity support rather than treating training as a single, one-time event.
Yes — it is possible to over-engineer Power BI security for a mid-market organisation. Highly granular, enterprise-grade security models designed for organisations with thousands of users and complex regulatory requirements can be genuinely counterproductive for a fifty-person business, adding maintenance overhead without a matching risk to justify it. We size the security model to the organisation's actual risk profile, not to a theoretical maximum.
Methodology and capability reinforce each other rather than one being more important than the other. Methodology without capability produces consistent failure. Capability without methodology produces inconsistent results. The best firms have both: a defined approach that is genuinely followed by capable consultants. The methodology should be visible in the proposal (described, not just referenced) and visible in delivery (the engagement actually follows the described approach). Methodology that exists only on the website is a red flag rather than a credential.
Self-service BI is not just about giving everyone Power BI, and that confusion is part of why so many rollouts fail. Self-service BI is about matching the right capability to the right audience and integrating it into how people actually work. Giving everyone the same authoring tool produces a small number of users who become productive and a large number who do not. The framework distinguishes between audiences and provides the right experience for each. One size fits no one.
Static RLS (a separate role manually maintained for each user or group) works for small, stable user populations where role assignment rarely changes. Dynamic RLS (where the filter expression references a table mapping users to their permitted data, so no manual per-user role maintenance is needed) scales far better and is what we recommend for any organisation beyond a handful of report consumers.
The Hopton design approach is not solely a Microsoft-led recommendation - there are genuine alternatives. Native BC reporting works for simple needs. Jet Reports (insightsoftware) is mature and Excel-based, well-suited to finance teams. Cosmos (BiE) is a newer cloud-only BC-specific option. Each has its place. We cover the comparison properly in our BC Reporting Options FAQ. Power BI is right for users who need cross-source analytics, self-service capability, or the foundation for AI and machine learning. Power BI is not always the right answer; it usually is when the requirements extend beyond BC-only finance reporting.
Roughly seventy per cent of the checklist applies to any BI tool. Layout, consistency, KPI design, accessibility, storytelling and trust are universal. The remaining thirty per cent is Power BI specific: visual headers, slicer behaviour, refresh dates, custom visuals and similar. If you are using Tableau, Looker or another tool, most of the list still helps you. We may publish tool-specific versions in time.
No — it is not only relevant to organisations on Premium or Fabric. Many of the scale problems show up before Premium or Fabric. The architecture decisions (one model per domain, star schema, deployment pipelines, model-layer security) apply equally to Pro-tier deployments. The capacity decisions matter when you are on Premium or Fabric, but the modelling and governance decisions matter regardless. Wait until you are on Premium and you have already accumulated the technical debt.
DAX training should be built around your own data wherever possible, rather than generic. Teaching DAX concepts using a generic sample dataset is faster to prepare but transfers less effectively than working through real measures against your organisation's actual sales, finance, or operational data, which is what your team will be building against once training ends.
Yes — you should probably read this even if your decision is already made. The most useful part of this FAQ is the section on when each platform is the right answer. If your decision was made on incomplete information (cost only, vendor lock-in concerns only, or a senior stakeholder's preference), the comparison may surface things worth revisiting. If the decision was made deliberately on the right factors, this FAQ confirms the reasoning. Either outcome is valuable.
You should run the Power BI design checklist on every report that goes to a real audience before sign-off. Skip it for sandbox or proof-of-concept work where the review effort would outweigh the value. The risk is in the reports that quietly become production while everyone assumed they were prototypes. The checklist is the moment the report has to declare itself.
Power BI security needs ongoing maintenance, not just a one-off design at launch. Roles change, new data sources get added, and new report consumers join the organisation. We build periodic security review into Continuity support arrangements rather than treating the initial configuration as permanent.
Yes — administrators should be trained separately from report builders, even if it is the same person, because the skill sets are genuinely different. Workspace security, capacity management, and tenant governance settings are administrative concerns distinct from data modelling and DAX, and combining them into one generic session tends to under-serve both topics.
Business users should generally not publish their own reports directly to production workspaces. We recommend separating a development or self-service workspace, where trained users can build and test their own reports, from certified production workspaces, where only reviewed and approved content is published for wider consumption. This preserves self-service flexibility without compromising the trust of governed reporting.
Almost always, yes — every KPI should show a comparison. A KPI without a comparison is a fact. A KPI with a comparison is information. Some metrics are genuinely standalone: cumulative totals for the year, count of open issues, and similar. Most are not. The discipline of asking 'compared to what' for every KPI you put on the page tightens the report considerably.
Not every employee should be able to create their own Power BI workspace by default, in most mid-market organisations. Unrestricted workspace creation tends to produce sprawl - many small, ungoverned workspaces with unclear ownership. We generally recommend restricting workspace creation to a defined group, with a clear request process for anyone else who needs one.
Every report that goes to a real audience should be developed in Dev first. Sandbox or proof-of-concept work can happen wherever. The risk is in content that drifts from sandbox to production without anyone noticing. The discipline is that Prod is for content that has been through Dev and Test, and content that has not been through that cycle does not get into Prod. Enforce this through workspace permissions, not just through process.
No — you should not always size up to F64 if you are close to the crossover. The crossover is a financial threshold, not a target. A 220-staff organisation running F8 plus 180 Pro licences (around £3,030 per month total) is doing the right thing. Moving them to F64 (around £5,400 per month with reservation) makes them spend more, not less, because the viewer count does not justify it. F64 is right when the viewers genuinely outnumber the crossover. Below that, the smaller capacity plus per-user model wins.
It is usually the wrong question, because the two are built for different jobs and most businesses that get value from one eventually want the other. Power BI answers what is happening; Power Apps answers what you do about it. Neither replaces the other, because neither is trying to do the other's job. The better question is where seeing and doing currently live in separate places in your business, because that gap is where connecting the two pays back.
You should almost never move your invoices and statements off Business Central Native reporting. Native does this well, and the alternatives (Power BI Paginated, Jet) are typically more effort for less polish on this specific use case. The exception is if you are already on Fabric and want consolidated reporting. Power BI Paginated on Fabric is a credible alternative there. For most BC organisations, Native stays.
You should usually not pick the cheapest Power BI consultancy that meets your requirements. The lowest day rate is rarely the lowest total cost when you account for engagement length, rework, and the value delivered. A more capable consultancy at a higher rate often produces a faster, cleaner outcome than a less capable one at a lower rate, and the total cost is similar or lower. The right question is not 'which firm has the lowest rate' but 'which firm produces the best total outcome for the budget available'. The two answers are often different.
Native reports for operational documents stay. Native reports that are doing analytical jobs (sales summaries, inventory analysis) often move to Power BI. The split is by use case, not by tool. The migration is the moment to ask whether a Native report is doing the right job for it, not just whether to migrate it.
You probably should not standardise on one Business Central reporting tool. Most BC organisations end up using two or three tools deliberately, each in its lane. Native for operational documents, Jet or Power BI for finance, Power BI on Fabric for cross-source analytics. That is normal, not a failure of standardisation. The discipline is being deliberate about which tool serves which use case, rather than letting tools accumulate by accident.
You probably should not wait for Business Central 2026 Wave 1 before starting. The new features are improvements, not prerequisites. Implementations using earlier BC versions still work and can be upgraded. Waiting for the next release usually means waiting forever, because the next release is always coming. Start with what is available now, design the architecture to take advantage of new features as they ship, and upgrade routinely. Most of our BC clients run on the current Wave with one Wave behind on test environments.
No — you should not wait until your central reporting is fully established before doing self-service. Self-service depends on certified semantic models, but the broader reporting estate does not have to be complete. The right approach is usually to certify the models in the priority domains first, roll out self-service in those domains, and extend domain by domain. Waiting for everything to be perfect produces nothing for years. Working domain by domain produces visible value within months.
UI/UX reviews fail to stick for two common reasons. First, the review was a one-off rather than a working discipline, so standards drifted as soon as the project ended. Second, the review surfaced too many issues at once, and the team triaged them informally without proper sign-off. Reviews work when they are routine, the issues are tracked formally, and sign-off is gated on the must-fix list being empty.
The relevant designation is Microsoft Solutions Partner for Data and AI. This is one of six Solutions Partner designations Microsoft awards (alongside Modern Work, Security, Business Applications, Infrastructure, and Digital and App Innovation). The Data and AI designation requires the partner to demonstrate technical capability, delivery success, and customer reach in the data and analytics space specifically. A firm that holds it has cleared a real bar. A firm that does not is not necessarily incapable, but the certification is one useful signal.
Hopton has delivered Sage 200 engagements for mid-market clients across distribution, manufacturing, professional services, and consumer goods. Engagements have covered finance reporting, multi-company consolidation, sales analytics, stock and inventory dashboards, and integration of Sage 200 with CRM and ecommerce sources. The Sage 200 patterns transfer well across engagements; the differences are in the secondary sources and the specific dashboard set.
Microsoft has shipped tooling to make BC-to-Fabric integration smoother, including direct connectors and analytics extensions. These reduce the build effort. They do not change the architectural decision. If you need Fabric, the connectors help. If you do not need Fabric, the connectors do not change the answer.
Copilot in BC and Copilot in Power BI are both real and both have their place. Copilot in BC is useful for the operational BC user (drafting purchase orders, summarising customer activity, asking questions about specific transactions). Copilot in Power BI is useful for the analytical user (generating visuals, drafting DAX, exploring data). The two complement each other. Both work better when the underlying data foundations are right, which is the broader theme of our AI and Copilot guidance.
Dynamics 365 Sales custom entities flow through Dataverse alongside the standard entities. The same proliferation issue exists as in Salesforce: mid-market Dynamics estates accumulate custom entities and fields over time, many of them legacy. Part of the early engagement is the same triage work: which entities are meaningful, which are unused, which are duplicates. Bringing the cleaned set into the analytical layer makes the reporting genuinely useful rather than overwhelming.
The same principles apply to NAV and earlier Dynamics products. NAV (the predecessor to BC) and earlier Dynamics products can be analysed using the same Power BI on Fabric pattern. The extraction is more involved because the systems are older and the APIs are less developed, but the architecture downstream is identical. Hopton has experience working with NAV environments through to BC migrations and has clients running on both. If you are on NAV and considering options, Power BI on Fabric is a viable route regardless of whether you are also planning a BC migration.
Power BI for sales and operations teams using Sage 200 is often higher value than the finance use cases. Sales teams want customer-level analysis (who is buying, who has stopped buying, what margin each customer generates). Operations teams want stock and supply chain visibility. Both audiences struggle to get this from Sage 200's standard reports. Power BI on top of Sage 200 typically expands BI usage well beyond finance into sales, operations, and management. The total value of the platform usually exceeds the original finance-led business case.
Pyramid Analytics and other vendor accreditations are useful where they reflect specific capabilities relevant to your situation. Pyramid Analytics certification is relevant where you are using Pyramid for governed self-service on top of Power BI. Other vendor certifications (Snowflake, Databricks, Tableau, Salesforce) are relevant where those tools are part of your stack. The general principle is that the right accreditations for your engagement match the technologies you are actually using or evaluating, not a long list of impressive-looking logos.
Some Sage 200 deployments expose ODBC drivers that Power BI can connect to directly. This works for simpler reporting needs but does not scale well: query performance depends on Sage 200, ODBC connections add load to the operational system, and the lack of a dedicated analytical layer limits what you can build. ODBC is a fine starting point for proof of concept; for production reporting, the recommended pattern is to extract data into Fabric and run analytics from there.
Your existing Jet Reports can stay or go. Some BC users keep Jet for finance-team-led Excel reporting alongside Power BI for dashboards and operational reporting. Others retire Jet entirely and consolidate on Power BI. Both paths work. The decision depends on how heavily Jet is used, how comfortable finance is with Power BI's financial reporting capabilities, and the cost of running both tools in parallel. We have helped clients on both paths and are happy to advise on the right answer for your situation.
BC ships with predefined analytics views and a Power BI app. They are a useful starting point. They are not usually the end state. Most organisations outgrow the standard app within a few months and need custom semantic models tailored to their specific KPIs and definitions. Use the standard app to start, plan to evolve from it.
Year-end is a high-stress period for finance teams using Sage 200, with the standard reports often unable to produce the consolidated, multi-period, multi-company views that statutory and management reporting need. Power BI on a properly built data layer handles year-end naturally because the data is already modelled with year-over-year comparison, multi-company consolidation, and audit trails in mind. The work shifts from a frantic month of report-building to a routine process of running existing dashboards. This is one of the most-cited benefits by finance directors after the first year-end on the new platform.
A Power BI theme is a JSON file that sets a report's colours, fonts, and visual styling in one go, rather than formatting each chart individually. Hopton publishes a library of free Power BI themes, covering styles from bold and executive to accessible and colourblind-safe, plus Microsoft-branded options for Fabric, Copilot, and Dynamics 365 Business Central reporting. They're free to download and use, no account or sign-up required; apply one via View, then Themes, then Browse for themes in Power BI Desktop. If you need more than a colour scheme, such as a governed data model behind the report, that's where our consulting work starts.
Deployment pipelines are Power BI's mechanism for moving content between Dev, Test, and Prod workspaces in a controlled way. They handle the workspace mapping, the dataset rebinding, and the deployment of related items together. Deployment pipelines are essential at scale because manual moves between environments produce mistakes and inconsistency. Without pipelines, every change is risky. With pipelines, change is routine.
Sensitivity labels, part of Microsoft Purview Information Protection, classify reports and datasets by confidentiality level (for example, Public, Internal, Confidential) and can enforce protections such as restricting export or requiring encryption based on that classification. They matter most for organisations with genuine confidentiality tiers to enforce, or regulatory requirements around data classification.
The Fabric capacity tiers start at F2, around £200 per month (entry, suitable for trials and small workloads). F4 around £400 per month (small production with light usage). F8 around £1,050 per month (most common starting point for mid-market production). F16 around £2,100 per month (multi-department, more demanding refreshes). F32 around £4,200 per month (active data engineering). F64 around £6,400 per month (free viewing kicks in here). F128 and above start around £12,800 per month and scale to enterprise volumes.
There are five essential FP&A reports every mid-market business needs. Budget versus actual P&L by entity and department, with variance analysis. Rolling forecast showing the latest expected outturn against budget. Cash flow forecast covering the next 12 to 13 weeks for working capital management. Headcount and people cost reporting for the largest cost line in most businesses. Executive KPI dashboard tying financial performance to a small number of operational drivers.
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.
Self-service BI needs five foundations to work. First, certified semantic models. Tiered audiences. Governance basics applied to self-service authors. Workflow integration rather than portal navigation. The Business Value Question for self-service authors. Each foundation addresses one of the five reasons rollouts fail. They are not optional. They are not steps to do later. The successful rollouts have all five in place before the broader user base is invited in. The failed rollouts skip foundations and try to retrofit them.
The five reasons self-service BI rollouts fail are no certified content, so users cannot tell trustworthy answers from unreliable ones. No audience tiering, so the platform serves nobody well. No workflow integration, so users have to leave their normal tools to use BI. No success measure beyond logins, so nobody can tell whether the investment is working. And no governance for self-service authors, so the estate becomes the same kind of sprawl users were trying to avoid. Each is preventable. Most rollouts fail on three or four at once.
Five things change when Power BI scales. First, numbers stop matching across reports. Performance degrades. Sprawl accumulates. Security gets messy. Change becomes risky. Each is a recognisable failure mode and each has a specific architectural response. The list is not exhaustive but it covers most of the symptoms organisations describe when they tell us their Power BI estate is not working anymore.
The four storage modes in Power BI are import, DirectQuery, Direct Lake (Fabric only), and Composite. Import loads data into the Power BI engine for fast query performance. DirectQuery passes queries through to the source system in real time. Direct Lake reads directly from the Fabric lakehouse without import or pass-through, combining performance and freshness. Composite combines Import and DirectQuery in one model for specific use cases. Each has a place. Each has costs.
There are three limits of Jet. Multi-source reporting, where Jet's BC focus becomes a constraint. Large data volumes, where Excel's shape limits performance. And dashboard-style analytics, where Power BI does the visual job better. If your reporting needs grow beyond BC alone, beyond Excel volumes, or into self-service dashboards, Jet ceiling becomes visible.
The main limit of Power BI direct on BC is API throughput: BC's API is the most common constraint. For large data volumes or complex queries, the API can become the bottleneck. Multi-source reporting also struggles with the direct approach 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.
There are two main BC analytics products beyond Microsoft's own. Jet Reports (now insightsoftware) is mature, Excel-based, BC-focused, with a long heritage in the BC partner channel. Cosmos (BiE) is a newer entrant, cloud-only, BC-only, with a faster install time. Both are credible products. Both have specific strengths and specific limits. Either can be the right answer depending on your situation. Neither is the right answer for multi-source analytics or AI ambitions, where Power BI on Fabric is the better fit.
There are five main gaps in BC's built-in reporting. Multi-company consolidation is awkward at best and impossible at worst depending on tenant structure. External data integration is limited (BC reporting is BC-only). Semantic modelling is absent (no certified definitions, no shared model). Performance suffers on heavy queries against the live system. Formatted financial reporting (the kind finance teams need) is constrained. None of these are fatal individually. Together they are why most BC organisations end up looking at Power BI for analytical workloads.
BC extraction has several common gotchas. Posting groups affecting how transactions roll up (often missed). Dimensions in BC (the analytical type, not data dimensions) requiring careful translation. Closing entries at year-end producing apparent duplicates if not handled. Currency revaluations affecting historical comparability. Item ledger entries that are technically reversals but appear as separate transactions. Each is recoverable. None is obvious if you have not encountered it before. The whitepaper has a section dedicated to these.
There are five most common mistakes buyers make. Buying on day rate alone rather than on total cost of the engagement. Believing the pitch team is the delivery team without verifying. Skipping the references because they feel like a formality. Choosing a generalist Microsoft partner because of an existing relationship rather than a specialist who fits the work. Picking a big-name consultancy for a small engagement, where the buyer becomes a low-priority client and the assigned team is junior. Each of these is recoverable but expensive when it happens. Avoiding them is cheaper than fixing them.
There are three most common pitfalls in BC + Power BI implementations. Underestimating multi-company complexity (consolidation logic is harder than it looks). Trying to replicate Native BC reports verbatim (better to redesign for the analytical use case). And building without a Silver layer (data lands in Gold raw and the inconsistencies surface in reports). Each pitfall is recoverable but adds time and cost when discovered late. Engaging an experienced BC analytics partner reduces the risk meaningfully because the patterns are well-known.
The three Power BI audience tiers (Consumers, Explorers, Authors) are Consumers, Explorers, and Authors. Consumers want answers presented to them: dashboards, reports, scheduled emails. Explorers want to filter and slice within an existing structure: change the time period, focus on one product line, drill through to the underlying detail. Authors want to build new content: new measures, new visualisations, new reports. Most users sit in the Consumer tier. A smaller number are Explorers. Authors are the small minority. Each tier needs different capability.
The three main licensing options are Power BI Pro at £11 per user per month (raised from £8 in April 2025). Power BI Premium Per User (PPU) at £19 per user per month, adding Premium features on a per-user basis. And Microsoft Fabric capacity, starting at F2 around £200 per month and scaling to F2048 for enterprise workloads. The three are not mutually exclusive. Most organisations use Pro for authors and either PPU or Fabric for additional capability, depending on user count and workload.
You can do quite a lot in parallel with the implementation. Existing BC operations continue unchanged. Existing Native reports continue to run. Finance can keep using Jet if they have it. The new analytics layer goes live alongside existing tools, and the existing tools get retired (or kept) deliberately rather than by accident. The implementation does not require disrupting day-to-day BC use. This is one of the practical advantages of the Power BI approach over Native rebuilds.
A structured cost review typically saves double-digit percentages in the first year, without losing capability. Most mid-market organisations carry several of the five overspending patterns at once. A structured review usually surfaces them in two to three weeks and the fixes are implementable inside a quarter. The savings come from sizing capacity correctly, removing unused Pro licences, pausing capacity outside business hours, and avoiding the jump to F64 before it is justified.
At F64 and above, viewers do not need their own Pro licence to see content. Below F64, every viewer needs a Pro licence at £11 per month. F64 is the tier where the maths changes. The decision at F64 is not whether you need the capacity (F32 or smaller is often enough technically) but whether your viewer count justifies the additional cost in exchange for free viewing across the user base.
BC users typically build five dashboards first. Sales analytics by customer, product, and channel. Financial reporting (P&L, balance sheet, working capital, multi-company consolidation if relevant). Inventory and stock position. Aged debt and collections. Profitability by line of business. Each is a recognisable need that BC's built-in reporting handles partially or awkwardly. Power BI versions land within the first eight to twelve weeks of an implementation. The remaining dashboards extend from these foundations.
Sage 200 users typically build five dashboards first. Sales analysis by customer, product, and territory. Aged debt and collections with cash position. Stock and inventory with replenishment alerts. Profitability by line of business or product group. Cashflow and treasury position. Each is a recognisable Sage 200 user need that the standard reports handle partially. Power BI versions land within the first eight to twelve weeks of an implementation. The remaining dashboards extend from these foundations.
Day rates span a wide range by firm category. Big-four and major systems integrators: £1,500 to £3,000 per day for senior consultants, with junior team members at £900 to £1,500. Mid-tier firms: £1,200 to £2,000 senior, £700 to £1,200 junior. London-based boutique specialists: £900 to £1,500 senior. Regional specialists with London presence: £700 to £1,200 senior. Freelance contractors: £500 to £900 individual. The cheapest is rarely the right answer for complex engagements, and the most expensive is rarely the right answer for mid-market work. Pay attention to the cost-per-outcome rather than just the rate.
With the issues the review finds, log them with screenshots, prioritise them, and put them on the build backlog before sign-off. We use three priority levels: must-fix before release, should-fix soon, and nice-to-have. Most reviews surface fifteen to thirty issues in the first pass. After the second iteration, that drops to a handful. The review is not done until the must-fix list is empty.
"Power BI direct on BC", as a reporting option, means treating BC's own APIs as the data source and letting Power BI handle the modelling directly, with no warehouse, lakehouse, or ETL layer sitting between BC and the report. It's one of two patterns we see regularly, the other being BC data landed in Fabric first. Direct-on-BC tends to suit smaller data volumes and single-entity setups; the Fabric route suits multi-entity, multi-source, or governance-heavy requirements. Which one is right depends on scale and reporting complexity, not preference alone.
A report has clarity and purpose when a new user can answer three questions inside ten seconds: what is this report for, who is it for, and what is the headline. If any of those takes longer, the report is failing on this category. Clarity is harder than it looks. Most reports fail not because they say too little but because they say too much, all at once, with equal emphasis.
Bronze, Silver, Gold means Bronze is the raw extract from BC, landed in a lakehouse or warehouse without transformation. The data looks like BC's internal structure. Silver is the cleaned and structured version: tables joined, codes resolved, naming standardised, history made consistent. Gold is the business-ready layer: facts and dimensions that match how the business thinks about the data, ready for Power BI semantic models. Each layer serves a purpose. Skipping Silver is the most common mistake.
Fabric capacity covers everything in Fabric: data pipelines, lakehouses, warehouses, real-time analytics, data science, and Power BI. OneLake storage is included. The capacity is shared across all workloads. This is genuinely different from buying separate licences for each component. The capacity buys you the whole platform, sized to the workload it has to support. The challenge is sizing it correctly, because the same F-SKU can comfortably handle one workload and choke on another.
Hopton's Power BI vs Looker assessment covers your data platform alignment (GCP, Azure, multi-cloud, on-premises), your audience (business users, engineers, mixed), your use case mix (internal BI, embedded, both), your engineering culture, and your cost sensitivity. The assessment maps these to the platform that fits, with reasoning. Output is a written recommendation. We do not always recommend Power BI. We recommend the platform that fits, even when the recommendation costs us the build engagement.
Power BI Premium Per User (PPU) adds Premium features on a per-user licence. Larger dataset sizes, more frequent refreshes (up to 48 per day), paginated reports, AI features in Power BI, and access to Premium-only capability without buying capacity. Useful when you need Premium capability for a small number of users but cannot justify the capacity cost. PPU at £19 per user per month is roughly twice Pro and gives you Premium features for that user. Sharing requires the recipient to also have PPU or be on Premium capacity.
Power BI adds a proper analytical layer on top of BC. Multi-company consolidation handled cleanly. Integration with non-BC sources (CRM, ecommerce, custom systems). Certified semantic models with one definition of every metric. Heavy analytical queries running outside BC, so the operational system is not affected. Formatted financial reporting that matches what finance teams need. Dashboards and self-service analytics that BC's built-in reporting does not provide. The same data, with materially better tooling around it.
Power BI at scale means more users, more reports, more authors, more domains, and more dependencies. The shift from one-person Power BI (where one BI developer can hold the whole estate in their head) to scaled Power BI (where the estate has its own architecture and governance). The transition is not gradual. There are five specific things that change, often suddenly, and organisations that do not adapt the way they work end up with a sprawl that is hard to govern and easy to mistrust.
Power BI direct on BC means connecting Power BI to BC using the standard BC connector, with no separate data warehouse or lakehouse. Power BI pulls data via BC APIs, models it semantically, and serves reports. It is the simplest path from BC data to Power BI dashboards. For straightforward use cases, it is also the right answer.
A Power BI and Fabric cost review looks at capacity tier and utilisation. Pro and PPU licence assignments and active usage. Refresh and pipeline schedules. Pause/resume automation. Reservation status. Workspace structure and capacity sharing. Usage patterns by user type. The review combines data from the Microsoft admin portal with usage reports and sometimes interviews with the data team. Two to three weeks is enough to do this properly. Less is a quick scan rather than a review.
Implementation cost varies by complexity but most mid-market engagements come in between £40,000 and £120,000 for the build phase plus the architecture work that precedes it. Ongoing licensing depends on user count and capacity sizing: typically £200 to £6,400 per month for Fabric capacity, plus Power BI Pro licences for authors. The True Cost FAQ covers licensing in detail. Total first-year cost is usually visibly less than what the BC implementation itself cost, with returns in finance team productivity and decision quality.
A Power BI on BC implementation leaves BC itself untouched - BC continues to run unchanged. Data flows from BC into Microsoft Fabric (a lakehouse architecture with Bronze, Silver, and Gold layers). Power BI semantic models sit on Gold and present certified definitions of revenue, margin, customers, and so on. Reports are built on the semantic models and delivered to users through a structured workspace. The platform supports the dashboards finance and operations need plus self-service for users who can build their own reports.
A Sage 200 Power BI engagement runs phase by phase. Most engagements start with a four-to-six week Establish phase: we audit Sage 200 and any related sources, agree the priority dashboards with finance and operations leaders, design the architecture, and produce a written engagement plan with cost and timeline. Build phase is typically eight to twelve weeks. Continuity is the optional ongoing engagement that maintains and extends the platform after launch. Most Sage 200 clients stay in Continuity because needs evolve as the business grows.
Implementation cost varies by complexity but most mid-market Sage 200 engagements come in between £40,000 and £100,000 for the build phase plus the architecture work. Ongoing licensing depends on user count and whether you need Microsoft Fabric: typically £200 to £2,100 per month for Fabric capacity at the typical mid-market scale, plus Power BI Pro licences for authors. The True Cost FAQ covers licensing economics in detail. The total first-year cost is often less than what businesses currently spend on manual finance reporting effort.
A defined methodology, in practice, is phases that follow a logical structure (discovery, design, build, test, deploy, support). A clear scope and acceptance criteria for each phase. Defined deliverables and roles. Standard architecture patterns that apply across engagements rather than being recreated each time. A defined approach to data quality, semantic modelling, and governance. The methodology should be opinionated. A methodology that says 'we adapt to whatever the client needs' is not a methodology; it is the absence of one.
A genuinely good proposal has specific scope, specific deliverables, specific team named with verifiable backgrounds, specific timeline with milestones, specific assumptions and dependencies, transparent pricing structure, honest articulation of risks and how they will be managed, defined acceptance criteria for the deliverables, and clear next steps. The good proposal reads like a working document the engagement will follow, not a marketing brochure. The volume of words matters less than the specificity of the content.
A reporting strategy engagement covers an inventory of existing reports, tools and audiences. Active versus inactive use map. Tool fit analysis per use case. Recommendations on what to keep, what to migrate, and what to retire. A target architecture and a sequencing plan. The deliverable is a written strategy you can take to anyone, including in-house. The engagement is independent of any subsequent build.
A typical Business Central on Power BI implementation runs phase by phase. Weeks 1 to 3: discovery and architecture (audit BC, agree priority reporting, design the Bronze/Silver/Gold structure). Weeks 4 to 8: build (extraction, Silver layer, Gold layer, semantic models, priority reports). Weeks 9 to 11: testing and refinement (reconciliation against BC reports, performance tuning, user acceptance). Week 12: go-live and handover. The timeline maps to a typical mid-market scope. Larger or smaller engagements adjust proportionally.
A typical CRM Power BI estate centres on a pipeline dashboard for the leadership team showing total pipeline value, weighted forecast, and movement against target. Sales rep performance dashboards with activity and outcomes. Win and loss analysis. Sales cycle analytics. Customer 360 reporting that combines CRM, ERP, and marketing data for a complete account view. A monthly board pack with the consolidated revenue forecast. The estate grows in that order in most engagements because the pipeline dashboard is the one the sales leadership team uses every Monday.
A typical CRM analytics engagement runs phase by phase. Most start with a three to four week Establish phase: discovery of the CRM data, the priority reporting needs, the architecture. The Build phase runs 6 to 12 weeks: pipeline dashboard, rep performance, win/loss, customer 360 if ERP integration is in scope. Continuity is the optional ongoing engagement after launch. The work fits alongside the existing sales operations and IT functions.
An executive FP&A dashboard is six to ten KPIs on a single page, with comparisons to budget and prior year. The KPIs are business-specific but typically include revenue, gross margin, EBITDA, cash position, working capital, and the two or three operational drivers most relevant to the business model. The dashboard is built for a five-minute scan, not for detailed analysis. Detailed analysis lives in the supporting reports. The discipline is restraint: an executive dashboard with thirty KPIs is not an executive dashboard, it is a confused report.
For years, getting a chart Power BI did not offer, or a layout the canvas would not allow, meant reaching for an SVG measure, an HTML content visual, or a stack of overlapping objects held together with hope. Those hacks work, but they take hours, break when someone resizes the page, and cannot be maintained by anyone who did not build them. Code-first reporting in Fabric makes most of them unnecessary: if you can specify a visual properly, you no longer need to smuggle it in through a workaround, which removes both the effort and the fragility.
Governance for self-service authors starts, in practice, with naming conventions for new content. Required ownership before content can be promoted. A review path before content reaches the main audience. A retirement process for content that no longer earns its place. The discipline is the same as central-team governance, applied lightly to fit how self-service authors work. The mistake is either no governance (sprawl) or heavy central-team governance (kills the self-service value). The middle path is fast review against a clear standard.
F64 includes free viewing, which sounds like a clean answer to licensing complexity. But at £6,400 per month PAYG, F64 is only economical if you have hundreds of viewers (the crossover is around 500 at list prices). Organisations sometimes jump to F64 before reaching the crossover because the licensing simplicity is appealing. The simplicity costs real money. Stay below F64 with smaller capacity plus per-user Pro until your viewer count actually justifies the move.
In evidence, sector experience looks like specific examples described credibly. The consultancy should be able to describe the data sources, the dashboard patterns, the typical KPIs, the common pitfalls, and the engagement timeline for businesses in your sector. Vague references to 'we have done lots of retail' are not evidence; specific descriptions of how retail engagements actually work are. Ask for examples and listen for specificity. A consultancy with genuine sector experience will produce specifics; one without will hedge.
Sprawl looks like twenty workspaces nobody can describe the purpose of. A hundred reports that mostly overlap. Five datasets doing roughly the same job. Authors who built something useful three years ago and have since left, with their content still running. Sprawl accumulates because adding new content is always easier than retiring old content. The annual review is the moment to push back on it deliberately.
The Business Central on Power BI implementation guide covers the technical work of building Power BI reporting on top of Business Central. The other FAQ is about tool selection: when to use Native, Jet, Power BI direct, or Power BI on Fabric. Read the tool selection FAQ first if you have not yet decided which approach is right for you. Read this one if you have decided on Power BI (with or without Fabric) and want to understand what the build actually involves.
The Power BI Consumer experience is dashboards delivered to the user, not retrieved by them. Headline numbers visible at a glance. The most common questions answered without interaction. Subscriptions delivering daily or weekly summaries via email. Mobile views for users on the move. The Consumer experience optimises for zero training and zero friction. The best Consumer experiences feel like reading a newspaper, not like operating software.
The Power BI Explorer experience is reports with rich filtering, drill-through, and bookmarks for common views. The Explorer can change the time period, switch between regions, focus on a specific product line, all without building anything new. The Explorer experience requires more report design effort up front but multiplies the reach of each report. One well-designed Explorer-tier report serves many Consumer-tier views without proliferating the underlying content.
The Power BI Health Check covers modelling patterns (star schema versus flat tables, model count, measure quality). Storage modes and refresh patterns. Workspace structure (Dev/Test/Prod or flat). Security model (RLS at model layer, group-based access, sensitivity labels). Performance (refresh times, report load times, capacity utilisation). Sprawl (overlapping content, unused workspaces). The Health Check is fast because it follows a structured methodology, not because it cuts corners.
The Self-Service Readiness Assessment covers a certified content audit (how much content has named owners, certified status, and active use). Audience analysis (who would be Consumers, Explorers, Authors). Workflow integration review (where BI currently lives versus where the audience works). Existing self-service authoring patterns (who is building what and how). Governance state for self-service authors. The assessment is fast because it follows a structured methodology and is calibrated to mid-market.
Workflow integration means the BI capability lives where users already work. Embedded in Teams. Linked from the CRM. Auto-delivered via Outlook subscriptions. Available in the meeting view of the operational tool. Self-service that requires users to navigate to a separate portal, log in, and find the right report fails because users do not have time to do that ten times a day. Integration brings the BI to where the work is, rather than asking users to come to the BI.
A Power BI domain model holds everything reports in that domain need, defined once. The metrics with their precise definitions. The dimensions used to slice them. The relationships between facts and dimensions. The measures expressed as DAX, with the business logic encoded. Reports point at the domain model and inherit the definitions. New reports do not redefine the metrics. The model is the source of truth for the domain and the reports are the views into it.
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.
When self-service authors are ungoverned, the estate becomes sprawl. Different authors build different reports answering similar questions with different definitions and different time windows. The certified semantic models get bypassed. The same problems that drove the original push for self-service reappear, but distributed across many more authors. Self-service authors need the same governance discipline as the central team, applied appropriately to their level. Without it, self-service is a sprawl factory.
After the initial implementation comes ongoing extension. The first release covers the priority domains. Subsequent releases add other domains, refine the existing ones based on user feedback, and extend into ML or AI use cases when the foundations are stable. Most clients move into the Continuity phase after launch, with regular small releases keeping the platform aligned with the business. The initial implementation is the start of the work, not the end.
If you choose Report Server now but your data residency requirement changes later, migrating to the cloud stays feasible - we design with that possibility in mind where practical, structuring semantic models and reports so they can move to the cloud service with reasonable effort if your requirements change. This is one of the reasons we discourage treating Report Server as a permanent architectural decision if the underlying driver is not itself permanent.
Nothing automatically - changes to workspace content do not appear in the published app until someone explicitly republishes it. This gives you a controlled release point, letting you finish and validate changes in the workspace before pushing them out to the wider app audience.
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.
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; reports continue to work. Major BC upgrades occasionally introduce changes that need accommodation in the extraction layer, but these are usually small adjustments rather than rebuilds. We handle BC version updates as part of Continuity. Clients without Continuity sometimes see small reporting issues after BC upgrades; with Continuity, the platform stays in step.
A consultancy reluctant to provide client references is a red flag, but a soft one. Some clients genuinely do not allow public reference for confidentiality reasons (private equity, sensitive industries, competitive concerns). A reluctant consultancy might have legitimate constraints. The follow-up is to ask specifically: are there any clients we could speak to confidentially, with appropriate NDAs in place? A firm that cannot produce a single contactable reference under any conditions is signalling that the references do not exist or would not be positive.
Two patterns help when your Power BI viewer count fluctuates. First, base the decision on average rather than peak viewer count. Sporadic viewers who log in once a quarter rarely justify the licence cost. Second, F64 with reservation locks in the predictable monthly cost regardless of viewer count, which protects against growth surprises. If you are confident the user base will grow past your crossover within twelve months, the move to F64 is often worth making slightly early.
A previous Power BI self-service rollout that failed is a common situation. Most failed rollouts are recoverable with the right framework. The honest assessment usually shows that several foundations were missing and the failure was structural rather than personal. We have helped multiple clients restart self-service rollouts that had been previously declared failures, with the same audience, the same data, and the same tools, but with the foundations corrected. The relaunch is usually faster and lighter than the original.
Planning to migrate from Sage 200 to BC eventually is a common situation. The Power BI on Fabric architecture transfers cleanly. The data layer is independent of the source system, so when the migration to BC happens, the analytics layer is rebuilt to point at BC instead of Sage 200. The historical data accumulated in the analytics layer survives the migration, which preserves the years of history that BC migrations often lose. This is a strong argument for building the analytics layer before the ERP migration rather than after: the analytics platform delivers value during the migration period and protects the historical data through the change.
Not yet knowing who your internal Power BI power users will be is common, particularly for organisations new to Power BI. We help identify likely candidates during the Establish phase, usually based on who currently owns spreadsheet-based reporting or shows clear aptitude and interest, rather than assuming it should default to whoever holds a specific job title.
Running Power BI Report Server needs your own Windows Server infrastructure to host the Report Server instance, along with a SQL Server database to store report metadata and configuration. Sizing depends on your report volume, refresh frequency, and concurrent user count, and should be planned properly rather than assumed from a generic template.
ADBC stands for Arrow Database Connectivity, built on Apache Arrow, the columnar format that has become standard for moving data between analytical systems. It is faster than ODBC because data moves in columns rather than row by row, with fewer type conversions, less copying in memory, and better use of modern CPUs, and it brings security improvements like memory safety. On a big refresh of tens or hundreds of millions of rows that is a real cut in overhead, so ADBC is worth using where the source supports it and the volumes are large; for smaller or simpler connections the difference is marginal.
Cosmos has a faster install time than the alternatives because it is BC-specific and cloud-only. For organisations that want operational BC reporting quickly, with minimal setup, Cosmos is a credible answer. The trade-off is that it is BC-only and cloud-only, which means it does not extend to multi-source analytics or to on-premises BC environments. It also locks you into a specific vendor's analytical model rather than letting you build your own.
Decision Adoption Rate is the percentage of recommendations from BI outputs that result in confirmed action by the business. The metric measures whether the BI investment is changing behaviour, which is the actual point. Login counts measure activity. Decision Adoption Rate measures impact. The metric is harder to track than logins but more honest. It tells you whether the work is producing the value the business case promised.
Direct Lake is a Fabric-specific storage mode that reads directly from Delta tables in OneLake without copying data into the Power BI engine. It combines Import-like query performance with near-real-time freshness, because the lake is the storage layer rather than a separate copy. Direct Lake works only on Fabric and only against Delta tables in OneLake. For organisations on Fabric with a lakehouse architecture, it is increasingly the default choice for new models.
Jet Reports is a third-party reporting tool that lives in Excel and works directly on BC data. Finance teams have used it for years because they spend their working day in Excel anyway. Jet adds BC-aware functions and a refresh model that keeps the data current. It is sold separately from BC.
LookML is Looker's modelling language. Data engineers and analysts define the semantic model (dimensions, measures, joins, aggregations) in LookML files that live in a Git repository. The model is version-controlled, code-reviewed, and deployed like software. Reports are built on top of the LookML model and inherit its definitions. This is genuinely strong: it forces consistent definitions, prevents the drift that Power BI estates often suffer from, and supports a code-quality discipline that is rare in BI.
Power BI Report Server is an on-premises reporting platform that hosts Power BI reports, paginated (SSRS-style) reports, and Excel workbooks on servers you control, rather than in the Power BI cloud service. It is a different product to Power BI Service, licensed and deployed differently, aimed specifically at organisations that cannot or do not want their reporting data leaving their own infrastructure.
A Power BI app is a curated, packaged collection of reports and dashboards from a workspace, published as a single, polished landing experience for a defined audience. Instead of giving a business user access to the workspace itself - with all its in-progress content, development clutter, and workspace-level permissions - an app presents only the finished, approved content in a clean, navigable format.
A Translytical Task Flow lets a Power BI report write back: update, delete, or trigger actions in other systems without the user leaving the report. It reached general availability in the March 2026 Power BI update, and it changes what a report is for, because seeing the problem and doing something about it no longer live in different places. Instead of spotting an at-risk renewal or a data quality issue and then switching to an email, a ticket, or a spreadsheet, the user can act on it in place.
Certification and promotion are Power BI's way of signalling that a dataset has been reviewed and is safe to build on. Encouraging report builders across the organisation to build against certified datasets, rather than each recreating their own version of the same data, is one of the single most effective governance practices for preventing metric drift.
A good Decision Adoption Rate is above 60 per cent. 40 to 60 per cent is normal for organisations early in a self-service rollout. Below 40 per cent indicates a trust problem (the recommendations are not being trusted) or a workflow problem (the recommendations are not reaching the right people at the right moment). The rate rises as the foundations bed in. The trend matters more than the absolute number, because the baseline depends on the maturity of the existing capability.
A rolling forecast extends a fixed period forward (typically 12 or 18 months) and is updated regularly (monthly or quarterly), so the forecast horizon does not shrink as the year progresses. Power BI shows the rolling forecast against actuals and budget, with the forecast period clearly marked. The work is in maintaining the forecast inputs: the planning tool or finance team updates the forecast monthly, and Power BI presents the latest version. The discipline is more about the planning cycle than the reporting tool.
A semantic model is the governed layer that sits between your raw data and your reports. It contains the business logic, metric definitions, relationships, and security rules that all reports share. Without a well-governed semantic model, every report developer applies their own logic, which leads to inconsistency. A single, certified semantic model is the foundation of trustworthy reporting.
A semantic model is the layer where measures, relationships and row-level security are defined once and reused across every report built on top of it. In a Fabric estate a certified semantic model typically sits on top of the Gold layer, queried through Direct Lake mode, so every report and dashboard inherits the same definitions rather than each author writing their own.
A star schema is a modelling pattern with fact tables (the events: sales, transactions, page views) and dimension tables (the descriptors: customer, product, date). The star schema is the standard pattern for analytical models because it produces fast, predictable performance and intuitive measures. It is not the only pattern, but it is the one that holds up at scale. Departure from it should be deliberate, not accidental.
Governed self-service analytics is the balance between letting the business build its own reports and keeping everyone working from trusted, consistent numbers. In Power BI that means certified datasets, a semantic model that defines each measure once, clear workspace ownership, and row-level security applied consistently. Supported by training and a Centre of Excellence operating model, it lets self-service scale without descending into conflicting versions of the truth.
The main analytics-relevant features in BC 2026 Wave 1 are improvements to the Lakehouse Connector (faster initial sync, better incremental refresh handling), expanded analytics extension capabilities, deeper integration with Microsoft Fabric, and tighter Copilot integration in BC itself. The cumulative effect is that the BC-to-Fabric path is meaningfully easier in 2026 than it was even twelve months ago. The friction points that affected earlier integrations have been progressively addressed.
RLS restricts which rows of data a given user can see within a shared report, based on rules defined in the semantic model - for example, a regional sales manager seeing only their region's data while a national director sees everything, from the same underlying report rather than separate copies of it.
Self-service BI is an approach where business users can find answers in data without going through a central data team for every request. The promise is faster decisions, broader adoption, and lower demand on scarce BI resources. The reality is that most rollouts deliver none of these. Gartner data consistently shows self-service BI adoption below 20 per cent across organisations that invest in it. The gap between promise and outcome is wide enough to warrant a deliberate framework.
The Dashboard Wireframe Kit is a set of wireframe templates we share with clients for the most common dashboard shapes: executive summary, operational KPI, financial review, sales pipeline, customer health. The wireframes are the starting point for new dashboards, with the layout, the visual hierarchy, and the typical content blocks already worked out. The kit reduces design effort and produces consistent, scannable dashboards across an organisation.
The Hopton FP&A architecture pattern is Bronze, Silver, Gold in Microsoft Fabric. Bronze captures actuals from the ERP, budgets from the planning tool or Excel, headcount from the HR system, and operational data from elsewhere. Silver cleans, structures, and consolidates. Gold contains the certified semantic models for FP&A: the Group P&L model, the Cash Flow model, the Headcount model. Power BI semantic models point at Gold. Reports inherit certified definitions. The architecture is the same as for any analytical workload, applied to the FP&A use case.
The MCP server in Microsoft's Power BI Agentic tooling is a component that lets an AI agent inspect a Power BI semantic model and run DAX queries directly against it, so the agent can check its own output against the model rather than just generating a formula in isolation and hoping it's correct.
The Power BI Desktop Bridge in the new Agentic tooling is a component that lets an AI agent drive Power BI Desktop directly: reloading a semantic model and capturing a screenshot of the result so the agent can verify its own build before a human reviews it.
The Power BI UI/UX checklist is a working standard for reviewing Power BI reports before they go live. Sixteen categories cover everything from clarity and layout to accessibility, performance and storytelling. Just over one hundred individual checks. It is the same list we use internally at Hopton, written down so other teams can use it too. It is not a scoring matrix. It is not a maturity model. It is a list of questions a second pair of eyes should ask before sign-off.
The Power BI admin portal controls tenant-wide settings: export restrictions, external sharing rules, workspace creation permissions, and usage monitoring, among others. Access should be restricted to a small number of genuinely responsible administrators, since tenant-level settings affect every workspace and user across the organisation.
The biggest risk of rolling out Power BI without proper training is self-service sprawl: well-meaning business users building their own disconnected reports against ungoverned data, each with slightly different definitions of the same metrics. This recreates the exact "whose number is right" problem that migrating off spreadsheets was supposed to fix, just inside Power BI instead of Excel.
The bottleneck in CRM-ERP customer matching is account record matching. CRM accounts and ERP customers usually start as separate records and drift over time: the CRM account is the parent group, the ERP carries multiple billing entities, the names do not match exactly, and there is no shared identifier. The Silver-layer work in the lakehouse is where the matching gets done, often using a combination of name matching, address matching, and manual reconciliation for the high-value accounts. Once done, the matching becomes part of the standard data flow and stays maintained.
The cost of not adapting to scale is that numbers stop matching across reports. Performance degrades unpredictably. Security gets messy. Change becomes risky because you cannot tell what depends on what. Sprawl accumulates: many reports doing similar things slightly differently, with no clear authority for the right answer. Most organisations recognise the symptoms before they recognise the cause. The cause is usually that the architecture has not kept pace with the user base.
The difference between report consumer, report builder, and administrator training is that report consumer training covers navigating dashboards, using filters and slicers, drilling into detail, and exporting data - typically a short session for a broad audience. Report builder training covers data modelling, DAX measures, Power Query transformations, and report design - a deeper, longer programme for a smaller group of power users or analysts. Administrator training covers workspace management, security configuration, capacity management, and tenant governance - for the small number of people who will actually administer the platform.
The difference between workspace roles and RLS is that workspace roles (Admin, Member, Contributor, Viewer) control what a user can do with content - build, edit, publish, or only view - within a workspace. RLS controls what data a user can see within a report they already have access to. The two work together: workspace roles gate access to content, RLS gates access to specific rows within that content.
The headline difference between Looker and Power BI is that Looker is a code-first BI platform with a strong semantic modelling layer (LookML), tight integration with Google Cloud, and a heritage in embedded analytics. Power BI is a broader BI platform with a heritage in self-service authoring, deep integration with the Microsoft stack (M365, Dynamics, Azure, Fabric), and a much wider user base. Both are credible enterprise BI tools. The right choice depends less on tool features and more on which cloud platform your data lives on, the engineering culture of your team, and your licensing economics.
The most common Power BI security mistake you see in mid-market organisations is treating workspace access as the only security control and not implementing RLS at all, on the assumption that "everyone in the department should see everything." This usually turns out not to be true on closer inspection, and retrofitting RLS onto reports that were built without it in mind is more disruptive than building it in from the start.
The most common UI/UX mistake you see in Power BI is trying to fit too much on one page. The discipline of removing visuals is harder than the discipline of adding them. Builders feel that more visuals show more effort, and stakeholders often ask for additions but rarely for removals. The result is pages that try to answer ten questions at once and end up answering none of them clearly.
The most common mistake you see in how organisations use apps is publishing a single, flat app with every report in one undifferentiated list, rather than deliberately curating sections and audiences. This tends to happen when apps are set up quickly after reports are built, rather than planned as part of the reporting architecture from the outset.
The right amount of white space is more than feels comfortable. Power BI's default canvas tempts you to fill it. Resist. White space tells the eye where to rest and where to look next. A report that feels slightly empty when you build it usually feels right when someone else opens it. A report that feels right when you build it is often too dense for everyone else.
The right way to design a KPI card is to show the value, the unit, the comparison and the direction. Comparison means against what: previous period, target, year on year. Direction means is up good or bad. Without those four elements, a KPI card is just a number. The best test is to imagine showing the card with no other context and asking yourself: would the reader know whether to be pleased or concerned?
References from clients in your sector, with similar engagement scope, where the engagement has been live in production for at least six months. References that are too recent (less than three months post-go-live) miss the operational reality. References from very different sectors are less useful than they appear. A consultancy that cannot produce references matching your engagement profile is signalling that they have not done work like yours before, even if they say they have.
Five recognisable categories of Power BI consultancy exist in the UK. Big-four and major systems integrators (Deloitte, EY, KPMG, PwC, Accenture, Capgemini) for enterprise scale. Mid-tier consultancies (BDO, Grant Thornton, RSM, similar) for upper mid-market with broader services. Microsoft data specialists (boutique firms focused on Power BI, Fabric, and the Microsoft data stack) for mid-market focused engagements. Generalist Microsoft partners (Dynamics or M365 firms with a smaller BI practice) for clients with existing partner relationships. Freelance contractors and individual consultants for tactical work or interim capacity. Each category has a place. Knowing which one fits your engagement is the first decision.
The organisations that most commonly need Power BI Report Server are those in regulated sectors with explicit data residency requirements, businesses with specific client or contractual obligations to keep data on-premises, and organisations with security policies that restrict cloud service use for particular data categories. For most standard mid-market businesses without one of these specific drivers, we would recommend the cloud service instead.
Hopton has deep practical experience delivering Business Central analytics engagements — BC is one of the source systems we know best. Several Hopton team members come from the BC partner channel. We have completed many BC analytics engagements across mid-market clients. We have a working library of BC extraction patterns, certified semantic model templates, and dashboard reference designs. The BC Implementation FAQ covers the technical depth in detail. We are not a generalist Power BI partner with some BC experience; BC is a substantial part of what we do.
Power BI consultancies use three main pricing models. Fixed-scope, fixed-price for defined deliverables (typically used for discovery phases and well-scoped builds). Time and materials at a day rate (typically used for ongoing or open-ended work). Outcome-based or value-based pricing (less common, used where the consultancy takes some risk on the outcome in exchange for higher upside). Most engagements use a combination: fixed price for the early phases where scope is clearer, time and materials for ongoing work where the demand fluctuates.
You should ask six questions in a discovery call. What is your understanding of our situation based on what we have shared? What kind of engagement do you think this is? Who would be on the team and what is their experience? What methodology would you apply, in concrete terms? What would you expect from us during the engagement? What does the next step look like? The answers to these six questions, in a 45 to 60 minute call, give you a clear sense of whether the firm fits. If the answers are vague or generic, the firm probably is too.
You should ask references five questions. What did the consultancy actually deliver versus what they promised? What was the experience of working with the team day to day? What went wrong, and how did the consultancy handle it? Would you engage them again, and for what kind of work? What advice would you give us in setting up the engagement to succeed? The fifth question is often the most useful because it surfaces what the reference has learned that we should know.
Named Hopton clients have achieved real, published results — a few examples from case studies: Evara Developments consolidated 66 live residential developments, around 1,500 homes, from manual spreadsheet reporting into a single live Power BI view built on Business Central. Wasabi had an underperforming Microsoft estate across restaurants, central kitchens and grocery partnerships; we rebuilt it into governed reporting spanning 40-plus P and Ls in one place, and the relationship has since extended into a machine learning programme. Conspicuous Recruitment had a Power BI tool that had fallen out of use; after rebuilding the model and interface it moved to daily reliance for performance and financial reporting. Remous Print replaced manual, multi-step reporting with a live dashboard available on web, mobile, SharePoint and Teams. These sit alongside the aggregate picture across our client base: 62 organisations supported, with an average 70% reduction in reporting time and 94% data accuracy across governed reporting environments.
There are a few red flags to watch for in a pitch. Vague answers about Microsoft accreditations. Reluctance to share named team CVs or arrange conversations with the prospective delivery team. Methodology described in marketing terms rather than operational ones. References that on inspection are old, peripheral, or not actually comparable. Day rates dramatically below or above the market without clear justification. Promises that match what the buyer wants to hear too closely without surfacing genuine risks. Pitches that minimise the work the client team has to do; engagements always require client commitment, and a pitch that hides that is hiding it for a reason.
Write-back is easy to turn on and easy to regret if you skip the governance, so a few things are worth settling before the first function is written: who is allowed to trigger a write and against which records, how those actions are authenticated and logged so they can be audited afterwards, what happens if a write partially fails, and which decisions genuinely belong inside the report rather than in the system that owns the data. Getting those agreed up front is what separates a task flow that earns its place from one that quietly becomes a governance problem.
A short-form template exists for the Business Value Question for self-service authors, designed to take two minutes to fill in rather than the full BVQ. Four blocks: who is this for, what decision will it inform, what action follows, when is the deadline. Self-service authors complete the short BVQ for any content they intend to promote to a wider audience. Internal use can skip it. The discipline is light enough to actually be used. The full version of the BVQ is in the Data Governance whitepaper.
This applies to Sage 200 Standard, Sage 200 Professional, and Sage 200cloud. The technical extraction approach varies depending on which version and how it is hosted (on-premises, partner-hosted, Sage-hosted), but the architecture downstream is the same. Power BI on Fabric works for all current Sage 200 deployments. We work with clients on each variant and have established extraction patterns for each.
A good example of a well-designed Power BI theme is 149 Degrees: a warm, bold palette built around deep amber and charcoal tones, tagged Bold and Executive, designed to hold strong contrast on board-level dashboards. Other examples in Hopton's free theme library cover different needs, such as Evergreen for sustainability-themed reporting, Maple for finance teams, and Beacon and Spectrum for accessible, colourblind-safe reports. Each is a downloadable JSON file with a defined accent colour and a five-colour swatch, applied via View, then Themes, then Browse for themes in Power BI Desktop.
We recommend skipping the Power BI design checklist in a few specific cases. For genuinely throwaway prototypes where the audience is one person and the report will not survive the week, the review effort is more than the report deserves. The trap is in the reports that say they are throwaway but then do not get thrown away. If there is any chance a report will go to a real audience, run the list.
Composite mode makes sense when most of your model can sit in Import for performance but a small slice genuinely needs real-time. The classic example is fact data updating overnight (Import) combined with a small live dimension table (DirectQuery). Composite gets you the best of both. The cost is complexity. Models with two storage modes are harder to reason about, harder to optimise, and harder to maintain. Use Composite sparingly and with clear documentation of why.
Jet still makes sense in 2026 when your finance team's natural environment is Excel and your reporting is BC-centric. Jet's strength is finance-team-led reporting on BC data, with the familiarity of Excel as the canvas. The product is mature, widely supported in the BC partner channel, and well-understood by finance teams who have been using it for years. For finance reporting on BC alone, Jet remains a viable answer. The limits show up when you need multi-source, dashboard-style, or AI-augmented analytics.
Power BI Pro on its own makes sense when the workload is purely Power BI, the user count is up to a few hundred, and you do not need Premium features (large datasets, frequent refreshes, paginated reports, AI features, free viewing). Pro is the right starting point for many mid-market organisations and remains viable as the business grows. The threshold for moving beyond Pro is usually one of: a workload that needs Premium features, a viewer count that justifies F64, or a wider need for Fabric workloads beyond Power BI.
An organisation starts to need scale-aware Power BI usually around the point where there are multiple authors building reports, several business domains using Power BI, and some reports that are mission-critical to operations. The threshold is rarely about user count. It is about complexity. A 50-person organisation with three authors across finance, ops, and sales is at scale. A 500-person organisation with one BI team owning everything may not be. The shape of the team matters more than the headcount.
You should apply the Power BI design checklist three times in the build cycle. At design, before any visuals are built, to set the bar for what good looks like. Mid-build, when there is enough on the page to spot direction-of-travel issues. And before sign-off, as the last thing that happens before release. Late-stage reviews catch the most issues but the cheapest issues to fix are the early ones.
BC Native reporting is the right answer for operational documents that need pixel-perfect output: invoices, statements, packing slips, credit notes, regulatory documents. Native is built for this and nothing else does it as well within BC. It runs real-time on BC data. It handles print and PDF cleanly. It is included with BC, so there is no additional licence cost. For its narrow use case, Native is hard to beat.
Jet is the right answer when your finance team's natural environment is Excel and the reporting is BC-centric. Jet is pragmatic, fast, and finance-team-led. The fight to move finance teams off Excel is rarely worth winning, and Jet meets them where they are. For finance reporting on BC alone, Jet is often the lowest-friction answer.
Power BI direct on BC is enough when your reporting is BC-only or BC-dominant, your data volumes are modest, and your refresh frequency is reasonable. For a single-source, mid-market BC business doing typical operational analytics, this works well. The reports are fast to build, the architecture is simple, and the cost is just the Power BI licence.
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.
A custom visual is a bad idea almost always, unless you have a specific reason the standard visuals cannot meet. Custom visuals add performance overhead, accessibility risk, and dependency on a third party who may stop publishing updates. Most reports do not need them. If you find yourself reaching for a custom visual, ask first whether a different standard visual would serve as well. The answer is usually yes.
Code-first reporting removes the technical limits that used to stop you building a bespoke visual, but removing a limit is not the same as needing to cross it. A custom visual is the wrong choice when a standard one would answer the question just as well, because every bespoke element is something your team has to understand, maintain, and carry forward when the person who built it moves on. The discipline is to reach for code when the requirement genuinely needs it, not simply because you now can.
You should not use Fabric capacity reservations when your sizing is uncertain. When you anticipate scaling up or down significantly within the reservation period. When the workload is genuinely seasonal and you would benefit from being able to pause for months at a time. PAYG is more expensive per month but more flexible. For organisations still finding their workload pattern, the flexibility is worth the premium. Reserve once the pattern is stable, not before.
You should use DirectQuery in Power BI when real-time or near-real-time data is genuinely required, such as operational dashboards monitoring live processes. DirectQuery has costs: query performance depends on the source system, many DAX patterns are limited or unavailable, and the source system bears the load of every report query. For genuine real-time needs, DirectQuery is the right answer. For 'we want fresh data' that turns out to mean 'within 24 hours', Import with frequent refresh is usually better.
Hopton's free Power BI themes page has a set of ready-made themes built for clean, modern report design: restrained colour palettes, consistent typography, and card and KPI styling that avoids the cluttered look of default Power BI reports. Each is a downloadable JSON file you apply through View, then Themes, then Browse for themes in Power BI Desktop. They're a starting point for visual consistency, not a substitute for a proper data model underneath the report.
You can find more on Hopton at hoptonanalytics.com. The website covers our team, our methodology, our published frameworks (the Hopton Insight Series), and our FAQ library across the technical and methodological topics that matter for Microsoft data and analytics work. Email hello@hoptonanalytics.com to start a specific conversation. We are happy to participate in a competitive process and equally happy to be passed over for engagements where we are not the right fit. The buyer's interests come first, even when that means we are not the answer.
You can find out more about Business Central reporting options on hoptonanalytics.com under Resources, including the BC Reporting Options FAQ (tool selection between Native, Jet, Power BI, and Fabric), the BC Implementation FAQ (technical depth), the True Cost FAQ (licensing), and the Power BI at Scale guide. Email hello@hoptonanalytics.com to discuss your specific BC situation or to book an Establish-phase engagement.
You can find out more about Power BI for Sage 200 on hoptonanalytics.com under Resources, including the related True Cost, Power BI at Scale, and Self-Service BI guides which cover topics Sage 200 users ask about regularly. Email hello@hoptonanalytics.com to discuss your specific Sage 200 environment or to book an Establish-phase engagement. We are happy to share anonymised reference architectures relevant to your sector and scale.
Power BI themes control report backgrounds as part of the overall design, including page colour, header bands, and visual containers, so a professional background usually comes from applying a proper theme file rather than editing backgrounds visual-by-visual. Hopton's free Power BI themes include neutral, business-appropriate backgrounds designed to sit behind KPI cards and charts without competing with the data. Download the JSON file and apply it via View, then Themes, then Browse for themes in Power BI Desktop.
Hopton's full position on platform selection is set out across our FAQ library on hoptonanalytics.com. The Fabric vs Snowflake and Fabric vs Databricks FAQs cover the data platform comparison. The Tableau, Qlik, and SSRS migration FAQs cover the leaving side of the conversation. This Looker vs Power BI FAQ covers the modern visualisation tool comparison. Email hello@hoptonanalytics.com to discuss your specific situation or to book a Reporting Modernisation Assessment.
You can see the full BC and Power BI implementation guide on hoptonanalytics.com under Resources. The whitepaper covers the gaps in BC reporting, the data architecture (Bronze/Silver/Gold for BC specifically), the extraction pattern library, the comparison against Jet and Cosmos, and the implementation timeline in detail. Email hello@hoptonanalytics.com to discuss your situation or request a copy of the extraction pattern library.
The full BC reporting comparison deck is on hoptonanalytics.com under Resources. The deck covers the six dimensions that decide it, the common myths and pitfalls, six clear scenarios for picking each tool, and two real BC organisation worked examples. To discuss a specific situation, email hello@hoptonanalytics.com.
The full Power BI at Scale whitepaper is on hoptonanalytics.com under Resources. The whitepaper covers the five things that change at scale, modelling patterns, storage modes, workspace structure, deployment pipelines, security, and the Health Check methodology. Email hello@hoptonanalytics.com to discuss your situation or to book a Health Check.
You can see the full Self-Service BI whitepaper on hoptonanalytics.com under Resources. The whitepaper covers the five reasons rollouts fail, the five foundations, audience tiering, Decision Adoption Rate, and the rollout pattern in detail. Email hello@hoptonanalytics.com to discuss your situation, request the Dashboard Wireframe Kit, or book a Self-Service Readiness Assessment.
The full True Cost whitepaper is on hoptonanalytics.com under Resources. The whitepaper covers all three licensing options, the F64 inflection point with worked examples, the five overspending patterns in detail, sizing methodology, and reservation strategy. Email hello@hoptonanalytics.com to discuss your specific licensing position or to book a cost review.
The full UI/UX checklist deck is on hoptonanalytics.com under Resources. It covers all sixteen categories and the full set of individual checks. If you want to discuss applying it to your own reports, or have a specific question this FAQ has not answered, you can email hello@hoptonanalytics.com.
Row-level security should live at the model layer, not the report layer. RLS defined in the model is applied consistently across every report built on the model. RLS defined in individual reports has to be replicated everywhere and is easy to miss. Model-layer RLS is one of the foundational disciplines for Power BI at scale. It gets less attention than capacity sizing but matters more for actual security outcomes.
Which category to pick for your business depends on three things. Scale: enterprise and FTSE-scale businesses usually fit the big-four or major systems integrator pattern; mid-market businesses usually fit specialist or mid-tier firms; small businesses usually fit freelance or generalist Microsoft partner relationships. Specialism: if you need deep specific expertise (sector or technical), a specialist firm usually delivers better outcomes than a generalist one. Existing relationships: if you have a Microsoft partner already doing related work, extending that relationship sometimes makes sense, with the caveat that BI is a meaningful specialism in its own right.
Looker has the stronger version control for semantic models, by some distance. LookML files live in Git natively and the deployment workflow is built around code review and merging. Power BI's version control story is improving (Fabric Git integration, Power BI Project files) but is not yet at the same level of maturity. For organisations where engineering discipline around the data model is paramount, this is one of Looker's strongest advantages. For organisations where the BI team works more like analysts than engineers, the Looker workflow can feel heavy.
Power BI is better for self-service business users, by a clear margin. Power BI Desktop, in-Excel analysis, and the Power BI service give business users a path from connecting to a data source to building a useful report in a single afternoon. Looker is harder for business users to author in because the workflow assumes the LookML model exists first. For organisations where self-service authoring by business users is a goal, Power BI is the more natural fit. For organisations where authoring is concentrated in a small data team, the gap matters less.
Looker is better for technical analysts and data engineers, in many cases. The LookML workflow, the Git integration, and the SQL-first approach suit data engineers who want to treat BI as code. Power BI works for technical users but feels more like a tool for analysts than for engineers. For data teams that come from a software engineering culture, Looker can feel more natural. For data teams that come from a finance, business, or analyst background, Power BI is usually more comfortable.
Looker is stronger for embedded analytics, particularly for product-embedded analytics in SaaS applications. Looker's embedding model, white-labelling capabilities, and licensing model are designed for the embedded use case from the ground up. Power BI Embedded is capable but feels more like a Power BI report rendered inside another application. For ISVs building analytics into their product, Looker has a meaningful advantage. For internal embedding (analytics in your own intranet or operational systems), the gap is much narrower and Power BI Embedded is usually fine.
Each BC module has its own data structures and operational reporting needs. Manufacturing analytics covers production scheduling, work order completion, BOM accuracy, and material usage. Service module analytics covers service contracts, technician productivity, parts usage, and customer satisfaction. The architecture pattern is the same for each module; the data domains and dashboard sets differ. We have engagements that have included each of these modules and the patterns transfer well.
Use Import mode by default, for almost everything. Import gives the fastest query performance, the most predictable behaviour, and the widest feature support. The cost is data freshness: Import data is only as current as the last refresh. For most analytical workloads, this is fine. Daily refresh is usually enough. The need for real-time data is overstated in most analytical contexts. Use Import unless there is a specific reason to do otherwise.
Keeping Power BI Report Server updated and secure is the responsibility of your own IT team, or a managed infrastructure partner, since this is self-hosted software rather than a Microsoft-managed cloud service. This includes applying Report Server updates, maintaining the underlying Windows Server and SQL Server infrastructure, and managing your own backup and disaster recovery process, none of which Microsoft handles for you as it does in the cloud service.
The Power BI UI/UX checklist is for Power BI developers, analytics leads, and the people who sign off on reports. It is most useful in mid-market organisations where one person often builds, reviews and ships the same report. The discipline of a second-pair-of-eyes review is the value, and the list makes that review consistent. Internal BI teams, consultancies and freelance Power BI developers all use lists like this. We just decided to make ours public.
Publishing or updating an app should generally be limited to a small, defined group — typically the same people responsible for the certified content in the underlying workspace — rather than every workspace contributor. Uncontrolled app publishing rights can lead to unreviewed or incomplete content reaching a wide audience prematurely.
Authors should be a small, deliberately chosen group with the right combination of business knowledge and analytical aptitude. Typically finance analysts, operations leads, and a few power users in other functions. Author-level access requires training, governance discipline, and ongoing review. Most organisations enable too many Authors, hoping for democratisation, and end up with sprawl. Better to enable a smaller group well than a larger group poorly.
Only viewers (read-only) should have access to Prod workspaces. Authors should not have direct write access to Prod. Changes go through deployment pipelines from Test. Service accounts or specific governance roles can have admin rights to Prod for emergency changes, but the default should be that Prod content is changed through the pipeline, not through direct edits in the workspace. This is the discipline that protects the production estate.
Someone other than the builder should run the review. The builder is too close to the work to see what a new user will hit first. They have already absorbed the report's quirks. A second consultant, a peer reviewer, or a senior team member should run the list. If your team is too small for that, run the review yourself but step away for a few days first. Fresh eyes are the asset, not just the second pair.
Certified semantic models are the first foundation because they are the source of trustworthy answers. A self-service author building a new report against a certified model inherits the metric definitions, the relationships, and the security model. The new report joins the trusted estate automatically. A self-service author building against raw data starts from zero and produces something that has to earn trust independently. Certified models are the multiplier that makes self-service work at scale.
There are so many Business Central reporting options because BC reporting needs span genuinely different use cases. Operational documents (invoices, statements, picking lists) need pixel-perfect output. Finance teams need flexible, Excel-shaped analysis. Operations need self-service dashboards. AI and forecasting need a modern data layer. No single tool serves all four well. The result is four credible options, each strong for different use cases.
BC users look beyond BC for reporting for five recurring reasons. BC's built-in reporting struggles with multi-company consolidation. It does not integrate well with non-BC data sources. It has no semantic modelling layer for shared definitions. Heavy queries can slow down the operational system. And formatted financial reporting is constrained relative to what finance teams expect. None of these are fatal individually. Together they explain why most growing BC users end up with Power BI in the picture within two or three years.
CRM users move to Power BI for analytics because both Salesforce and Dynamics 365 Sales have built-in reporting that handles the basics but struggles with three things: cross-source analytics (combining CRM with ERP, marketing, and finance), executive-grade dashboards that match how leadership reads numbers, and self-service analytics for the sales team. The built-in reporting is fine for operational sales management. Power BI is what most mid-market businesses end up using when they want strategic sales analytics, accurate pipeline forecasting, and a single view of the customer across systems.
Power BI makes it very easy to publish reports quickly, which is both its strength and the source of most governance problems. Without defined metric standards, certified datasets, and workspace governance, the environment grows organically with each person applying their own definitions. The result is multiple reports showing different numbers, leadership unable to trust any of them, and data teams spending more time reconciling than analysing.
Power BI reports often have inconsistent design because reports usually accumulate over months, with different builders, different stakeholders and different deadlines. Without a written standard, each addition follows the local convention rather than a global one. Consistency is the easiest thing to lose and the most visible thing when it is gone. Set a standard early, write it down, and review against it before anything new ships.
Sage 200 users look for alternatives to built-in reporting for several recurring reasons. Sage 200's standard reports cover the basics but struggle with multi-dimensional analysis, ad-hoc questions, and visual dashboards. Excel exports are heavily used and accumulate the usual problems: stale data, broken formulas, definitions drifting between users. Multi-company consolidation is awkward. Cross-source reporting (Sage 200 plus CRM, ecommerce, or warehouse data) is not what Sage 200 was designed for. Sage 200 does the operational ERP job well; the analytical layer benefits from a different tool.
Flat tables fail at scale on three fronts: performance, ambiguity, and maintainability. Flat tables (one wide table containing everything) are easy to build and feel intuitive for a single use case. They become slow as data volumes grow because every query has to scan the whole table. They become ambiguous because the same dimension appears in multiple denormalised forms. They become hard to maintain because changes ripple unpredictably. Star schemas avoid all three problems and are usually faster to build correctly the first time.
Numbers stop matching as the estate grows because the same business term gets defined slightly differently in three different reports built by three different people at three different times. 'Revenue' includes returns in one report and excludes them in another. 'Active customer' uses a 12-month window in one place and 6-month in another. Each definition is defensible in isolation. Together they produce inconsistent numbers across the business and undermine trust in the whole estate. The fix is a certified semantic model with one definition each.
So many Power BI reports become walls of charts because adding charts is easier than thinking about which ones earn their place. A wall of charts is what you get when you say yes to every stakeholder request without asking what the page is actually for. The fix is editorial discipline. Each page should have one main message, and every visual on the page should support that message or be removed.
Business Central reporting needs a separate guide because BC is a meaningfully different source from generic ERPs. The data model has its own conventions. The API has specific limitations. The historical data behaviour requires careful handling. The integration with Microsoft 365 and Fabric brings opportunities other ERPs cannot offer. Generic Power BI guidance covers the common ground. The BC-specific guidance covers the patterns that make the difference between a build that works and one that fights the source system at every step.
Dynamics integrates more cleanly than Salesforce for three reasons. The data lives in Dataverse, which is built on the same Azure platform as Fabric. Dataverse-to-Fabric integration is increasingly first-party (link to Fabric directly from Dataverse, no separate extraction needed). And the security and identity models share Entra ID, so user-level access governance is consistent across the stack. The result is less data engineering work and more time on the actual analytics. For Microsoft-stack organisations, the integration advantage is meaningful.
Power BI UI/UX matters because reports that are hard to use do not get used. Reports that do not get used cannot inform decisions, no matter how clean the data underneath. Most of the value of a BI investment is realised at the last mile: whether a person looking at the screen on a Wednesday morning understands the message and acts on it. UI/UX is what decides whether that happens.
Adoption matters more than capability because capability without adoption produces nothing. A self-service platform with extensive features used by 8 per cent of the intended audience is a more expensive failure than no platform at all. People do not wake up excited to use dashboards. They use them when the dashboard fits cleanly into the work they were already doing. The framework matters because the default outcome is non-adoption, regardless of how good the technology is.
Change becomes risky as the estate grows because nobody can tell what depends on what. A change to a measure in one model breaks five reports across three departments, and you find out when the affected teams complain. Without lineage and without proper test environments, every change carries unknown risk. Deployment pipelines and proper environments solve this. Most mid-market organisations skip them at first and then add them painfully after a high-profile incident.
Over-provisioning happens for three reasons. A vendor recommended a tier larger than needed. The project sponsor wanted headroom. Nobody knew how to size from real data. We see F32 capacities running at 15 to 25 per cent utilisation. That is paying twice what is needed. The fix is to start smaller. Fabric capacity is elastic and you can scale up in minutes. You cannot easily get back the money paid for capacity that was never used.
Performance degrades at scale for three typical reasons. Models grow and do not get refactored, so refresh times balloon. More users hit the same models concurrently, exposing query patterns that were fine for one user. And capacity gets shared across many workloads, so one badly-written query affects everyone. Performance degradation is usually a sign of architectural debt rather than a need for more capacity. More capacity papers over the symptom but does not fix the cause.
Security gets messy at scale because access tends to accumulate. Someone gets added to a workspace for a project and stays there. New starters get added to the workspaces their predecessors had access to, even if those predecessors had different roles. Row-level security gets applied report-by-report rather than at the model layer. Over time, the security picture diverges from what would be granted today if you started fresh. Periodic access reviews are the answer.
Treating every audience the same fails because Consumers do not want to learn an authoring tool. Authors are frustrated by tools designed for Consumers. Explorers fall in the middle and need both the simplicity of Consumer experiences and the flexibility of slicing. A platform sized for Authors overwhelms Consumers. A platform sized for Consumers frustrates Authors. Tiering matches the right capability to the right audience and lets each group succeed at their level.
Users often don't adopt the reports we build usually because the report does not match how they actually work. The data may be right, the visuals correct, but if it does not answer the questions they have on a Tuesday morning, they will not open it on Wednesday. Adoption is a design problem more often than a training problem. Talk to the users before building, and rerun the checklist with their workflow in mind.
Headcount analytics belong in FP&A reporting because for most mid-market businesses, people costs are the largest single line in the P&L and the most predictable driver of future spend. The headcount dashboard shows actual headcount versus budget, the cost of that headcount in salary and on-costs, leavers and joiners, and the forward view of approved hiring. Many businesses manage headcount through HR systems and people cost through finance systems with the two never properly reconciled. The FP&A view brings them together so the headcount conversation and the cost conversation are the same conversation.
Business Central built-in reporting is limited for external data integration because it is not designed for it. BC reports work on BC data. Integrating with other systems (Shopify, Xero, CRM, custom warehouse) requires bringing the data outside BC, into a separate analytics layer. BC's strength is operational reporting on BC data. Multi-source analytics is a different problem and requires a different tool. This is one of the strongest signals that Power BI on Fabric is the right answer.
Power BI and Fabric licensing is confusing because of three options, three pricing models, and a critical inflection point at F64 capacity. Power BI Pro is per-user. PPU is per-user with Premium features. Fabric capacity is consumption-based and covers the whole platform. The interactions between them produce wildly different total costs depending on user count, viewer-to-author ratio, and your appetite for committing to reservations. The pricing is logical once explained, but the explanation is rarely on a slide.
Power BI is the right tool for FP&A because FP&A combines actuals from the ERP, budgets and forecasts from planning systems or spreadsheets, and contextual data (headcount, sales pipeline, KPIs) from elsewhere. Power BI integrates all of these and presents them in a single set of analytical views. The alternatives are usually Excel-heavy or rely on the ERP's built-in reporting, which struggles with multi-entity consolidation, scenario comparison, and the visualisation finance teams want.
Logins are the wrong success measure because logins measure whether someone visited a page, not whether the visit produced a different decision. Login counts can rise without any actual behaviour change in the business. The metric to track is whether decisions get made differently. Decision Adoption Rate is the framework's specific metric for this. Logins are a vanity metric. They feel like progress because they are easy to measure. They are not progress.
Multi-company consolidation is such a problem in Business Central because BC is structured around tenants and companies, and consolidated views across multiple companies require either configuration most BC implementations do not have or workarounds that involve manual data manipulation. For a single-company BC user, the issue does not arise. For a group with five companies in BC, getting a consolidated P&L is genuinely hard within Native reporting. Power BI on Fabric solves this cleanly because the consolidation happens in the analytics layer, not the source system.
The last refresh date is so important because a report without a visible refresh date is asking the user to trust without being able to verify. The first thing a user does when they think the data looks wrong is to check when it was last refreshed. If they cannot find that information, they assume the worst. A small, dated label in the top right corner solves this for almost no effort.
The Power BI vs Looker comparison is less common than Power BI vs Tableau because Looker is newer, smaller in the UK installed base, and concentrated in technology-forward and US-based organisations. UK mid-market BI conversations have historically been Power BI versus Tableau versus Qlik. Looker is now showing up more often, particularly in organisations with a Google Cloud strategy or a strong engineering team. The comparison is becoming more relevant; the search audience for it is growing.
This adoption metric is better than logins because logins can rise without any business impact. A platform with rising logins and falling Decision Adoption Rate is producing more interest and less action: the worst combination. A platform with steady logins and rising Decision Adoption Rate is the goal: the same audience getting more value. Decision Adoption Rate ties the BI investment to business outcomes in a way logins cannot. It is also the right metric to put in front of finance when justifying ongoing investment.
Uncertified content is such a problem because users cannot tell trustworthy answers from unreliable ones. They look at a report, do not know who built it, do not know whether the underlying data is the official source, and rationally choose to ignore it. Or worse, they act on it without checking. Either way, the self-service value disappears. Certification is the discipline of marking content that has been reviewed and approved as the source of truth. Without it, every report has the same status as every other report, which in practice means none of them are trusted.
You can give report viewers Viewer access to the workspace directly, and for a small number of trusted, technically comfortable users this is sometimes simpler. But workspace Viewer access exposes everything in the workspace, including anything still in development, and does not give you the same curated navigation experience, custom audience grouping, or update-notification behaviour that an app provides. For any broader or less technical audience, an app is the better-designed option.
For simple BC-only reporting, you can point Power BI at BC directly. The direct path works. The reasons to introduce Bronze/Silver/Gold are: multi-source reporting (BC plus other systems), large data volumes (BC API performance), historical data preservation (BC archives differently from a lakehouse), ML and AI workloads (need a stable analytical layer), and consistent semantic modelling (Gold is the source of truth, not BC tables). Each reason justifies the architecture by itself. Several together make it essential.
You can trust our recommendation, even though we are a Power BI consultancy, because we genuinely recommend Native and Jet when those are the right answers. BC reporting is the area where we see most consultancy waffle, and our reputation rests on cutting through it. We have written reports for clients telling them not to migrate Jet, not to replace Native, and to slow down on Fabric ambitions. We do not benefit from selling you the wrong answer.
Hopton is a strong fit for Business Central analytics work because BC is one of the source systems we know best. Several team members come from the BC partner channel (Simon spent years at Azzure IT before founding Hopton). We have done many BC implementations across mid-market and we have the extraction pattern library, the architecture, and the field experience. The whitepaper covers the methodology. The engagements deliver it.
Hopton is a strong fit for Sage 200 work for three reasons. We have done Sage 200 engagements before and have the extraction patterns documented. We are a specialist Microsoft data partner, so the Power BI and Fabric side is core to what we do. And we are mid-market focused, so the engagement scale, cost, and timeline match what Sage 200 users typically need. We are not a generalist consultancy with some Sage experience; the Microsoft data stack is what we do, and Sage 200 is one of the source systems we know.
An organisation would choose Power BI Report Server over the cloud service most commonly for data residency and regulatory reasons: some organisations are contractually, legally, or by internal policy required to keep reporting data on infrastructure they directly control rather than in any cloud service, even a well-governed one like Power BI Service. Others have specific security postures (heavily air-gapped networks, for example) that make cloud connectivity impractical.
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.
Yes — Hopton will honestly tell us if Looker is the right answer for our situation. We have written assessments recommending Looker over Power BI where the embedded analytics requirement, the GCP alignment, or the engineering culture made Looker the better fit. We are a Microsoft-focused consultancy and our commercial bias is towards Power BI, but recommending the wrong tool damages us reputationally far more than the lost engagement helps us commercially. The four-week Reporting Modernisation Assessment is the structured way to get an honest recommendation.
Properly designed, integrating Power BI with Sage 200 will not affect performance. We extract data on a schedule (often nightly for most domains, hourly or more frequent for stock or sales where appropriate), with the heavy work happening in Fabric rather than against Sage 200. Direct database queries during business hours are minimised or eliminated. The Sage 200 system continues to support transactional users without measurable performance impact. Bad implementations can affect Sage 200 performance; good ones are designed to avoid this.
No — it will not slow down Business Central, when designed properly. The data extraction is structured to minimise load on the BC system: incremental refreshes for changed data, scheduled extracts during off-peak hours, and the use of BC's standard APIs rather than direct database access in most cases. The heavy analytical queries run on Fabric, not on BC. We have built BC analytics layers on top of operational BC environments without measurable performance impact. Bad implementations can affect BC; good ones do not.
Still have questions?
Can’t find what you’re looking for?
The first conversation is exploratory and carries no obligation. We’ll give you an honest answer to any question you have.
Book a free audit