Power BI Data & Connectivity - FAQs

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, a good Power BI consultancy builds certified, governed semantic models rather than ad hoc reports: a model built to signed definitions, reconciled to the source with tests, documented, secured, described for people and Copilot, deployed through development, test and production from Git, certified by people your tenant authorises, and owned by a named person in your business, with thin reports built on top. If a proposal lists reports and not a model, it is selling ad hoc reports. Our Power BI page describes how we build them.

Yes, you can stop users exporting sensitive data from Power BI to Excel or PDF 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, we connect Power BI to Microsoft Dynamics 365 Business Central, NetSuite, Sage, SAP, Salesforce and most mid-market systems, through their APIs, through Fabric mirroring and connectors, or through a lakehouse when the data needs combining and modelling first. Business Central's connector is import-only, so real-time needs a different route; see real-time financial reporting from Business Central.

Yes, we migrate reporting from Tableau, Qlik, QlikView and Excel to Power BI by rebuilding the data model as a star schema and a semantic model rather than copying scripts and worksheets, then recreating the reports people actually use. Migrations typically take eight to sixteen weeks depending on the estate. See should you rebuild or lift and shift your reports?

No, data source credentials do not deploy with a Power BI deployment pipeline. Credentials, gateway mappings and the refresh schedule must be set in each target stage, usually after the first deployment. Later deployments leave them in place.

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.

Yes, 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.

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. Our Power BI page covers how we build and support it.

To connect a Fabric workspace to source control, enable the Power BI Project format in Power BI Desktop preview features and save reports as .pbip, create a repository in Azure DevOps or GitHub, then use the Fabric workspace settings to connect to that repository and branch. The workspace can then sync changes in both directions.

Parameter rules switch data sources between DEV, TEST and PROD by setting a Power Query text parameter, such as a server name or file path, to a different value in each stage. The same semantic model is deployed everywhere, and each copy connects to its own stage's data.

You refresh a Power BI model automatically after a pipeline runs by adding a semantic model refresh activity as the final step of a Fabric pipeline, or by calling the Power BI REST API from Azure Data Factory in an older estate, so the refresh starts only when the gold tables have been rebuilt. If the model uses Direct Lake over Delta tables in OneLake there is no refresh to trigger, because the report reads the new tables as soon as they are written. Deploy only what changed covers deployment alongside refresh.

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 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 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.

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.

No, Microsoft is not deprecating the ODBC connector in Power BI, 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.

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.

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.

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. Our Power BI page covers how we build and support it.

Import is faster for most reporting because the data sits in memory. DirectQuery earns its place when data must be real-time or is too large to import, but it pushes load onto the source and can be slower, so it is a deliberate trade-off rather than a default.

It is worth reading our guide to Your Power BI Report Is Slow. Power BI Is Probably Not The Problem..

Yes, keep using Excel after moving to Power BI, but connected to the governed semantic model through Analyse in Excel rather than rebuilding numbers from exports, so analysts keep the flexibility they value while every figure comes from the same definitions as the reports. See our Power BI page.

BC's analytics extension and Lakehouse Connector are part of the tooling Microsoft has shipped 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.

Cosmos is a Business Central reporting connector, and it is the right choice when you want operational BC reporting quickly with minimal setup. 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. See our post What is new in Cosmos for Business Central in 2026.

A certified dataset, now called a certified semantic model, in Power BI is a model endorsed by a person or group the tenant administrator has authorised to certify, marking it as the trusted source for its domain so it appears first when people look for data to build on. Certification is a tenant-controlled label; what gives it meaning is the agreed definitions, reconciliation tests, documentation, security and ownership behind it. What is a semantic model? explains the model itself.

A certified or promoted dataset is one marked through certification or promotion, which 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 scheduled refresh runs the Power BI model refresh at a fixed time whether or not the upstream extract worked, so it can silently show stale data; an orchestrated pipeline runs extract, transform, model build and refresh in order and only moves to the next step when the previous one succeeded, so a failed extract stops the refresh and raises an alert. Fabric pipelines include a semantic model refresh activity for this. Orchestration is not scheduling explains the dependencies.

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.

Use a Fabric pipeline to orchestrate and to copy data, a Dataflow Gen2 when the transformation is Power Query and the volumes are modest, and a notebook when the transformation needs joins across sources, history handling or scale. Most automated estates use all three: a pipeline that runs a copy activity, then a notebook or dataflow, then a semantic model refresh. Notebooks, Dataflows Gen2 or pipelines sets out the rule.

Businesses still export Business Central data to Excel because its built-in reports were designed for operational lists, not cross-functional management reporting. They struggle with trend analysis over multiple periods, consolidated reporting across several companies, and combining Business Central data with CRM, payroll or project systems, so teams fall back on Excel. The better fix is to connect Business Central to Power BI, either directly through the OData API for smaller volumes or through a Microsoft Fabric and OneLake data layer when you have larger volumes, several data sources, or need finance-team self-service. That gives you live, governed dashboards and a single source of truth instead of monthly manual exports. Hopton Analytics builds Power BI and Fabric reporting on top of Business Central for mid-market businesses.

A semantic model often fails to refresh after deployment because credentials, gateway mappings and the refresh schedule are not copied by the deployment pipeline. Set them in the target stage, then trigger a refresh and confirm it completes.

Your Power BI refresh is being rejected by surge protection because semantic models now report capacity usage continuously, so a large refresh is recognised and stopped earlier rather than allowed to run and throttle everyone afterwards. Check the refresh in the Capacity Metrics app, move it to a quieter window, and remove unused measures and columns to reduce its cost. Why your Power BI report is slow covers the model side of the same problem.

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. Our Power BI page covers how we build and support it.