Slow Power BI Updates from Business Central—Where Is the Bottleneck?

Start by clarifying the issue. A report may open quickly with outdated data. It may also display up-to-date data but respond slowly to the user’s selections. Therefore, consult both the person responsible for updating the data and the employee who uses the report.

Select an identifiable record and track it through the solution. In the illustration, T1 is the record in BC, T2 is the point in time when the extract is available in SQL, T3 is the completed processing in the data warehouse, T4 is a completed import model update that contains the record, and T5 is the display in the report. The architecture is an example; your solution may have fewer or different steps.

Record the start, end, and wait time between runs. A quick extract won’t improve the freshness if the next model update doesn’t start until later. Use the Power BI update history and relevant integration logs; for API extracts, BC telemetry can be helpful. Compare timestamps within the same time zone. The time from T1 to T5 indicates the freshness of the tracked change. The report’s load time is measured separately from the user’s action until the report is fully displayed.

When performing direct API or OData extracts, you should examine the tables, columns, historical data, and companies. Records spanning several years from numerous financial statements present a different challenge than a limited sales extract. Also check for errors, repeated attempts, and system load during the relevant runs.

Query folding means that supported Power Query steps are translated into queries that are executed at the source. Filters and column selections can thus limit the data that is retrieved. Transformations and joins can alter this behavior, so the effect must be verified in the specific query. A filter in the report does not prove that less data was transferred.

A delta extract limits the data transfer between the source and the next data layer to relevant changes. BC2SQL can be part of this process. Power BI incremental refresh, on the other hand, divides tables in the model and updates the partitions covered by the policy. One mechanism does not automatically trigger the other.

Incremental refresh requires proper configuration, date filtering, and control over how the filters are handled at the source. The initial load may still be extensive. In particular, clarify how changes, deletions, and retroactive entries outside the selected update period are handled. Otherwise, you risk a process that runs too quickly and does not accurately reflect the necessary changes.

In Import, the report works with data that has been loaded into the Power BI model. New source data will not become visible simply by reloading the report in the browser. The model must first contain that data. The update schedule, processing time, and any errors are therefore critical.

With DirectQuery, queries are sent to the supported data source when the report is used. This places demands on, among other things, the source’s response time, architecture, and load. It does not make old data in an intermediate SQL layer new, and an open report page is not automatically updated in real time. The choice also depends on the connector, capacity, and licenses.

If delays occur with filters and visualizations, Performance Analyzer can help you distinguish between queries, DAX calculations, and the rendering of visuals. Examine relationships, calculations, and the number of visuals rather than assuming that the BC extract is the cause.

If the solution uses a gateway, its capacity, availability, and connection must be included in the analysis. Not all cloud connections require a local gateway. Also, check access credentials, source availability, and concurrent tasks. A queue or a failed run can result in outdated figures, even if the data processing itself is normally fast.

Determine the necessary update requirements based on the decision: Should the employee respond to an incident, or should management review yesterday’s results? The possible frequency depends on the entire chain as well as the model type, data volumes, capacity, and licenses. A scheduled start time does not guarantee that the report will be ready.

A data warehouse is not a prerequisite for all Power BI use cases. Microsoft’s standard apps for Business Central Online can serve as a relevant starting point for specific needs at each company. An existing data extract or model can also be improved without replacing the platform.

BC2DWH is Zealand Data’s SQL-based data warehouse solution built on top of BC2SQL. It is worth considering for large data volumes, SQL as a backend, or consolidated management reporting across financial statements, currencies, and dimensions. SQL extracts, data processing, and Power BI must continue to be organized collectively; the solution itself does not guarantee a specific speed.

Learn about BC2DWH and a common data foundation for Business Central. As your trusted advisor, we start by assessing your needs and conducting an analysis. The result should be a well-reasoned prioritization of improvements, an agreed-upon framework for monitoring, and a clear division of responsibilities.