Forum Discussion
Enable Incremental Refresh Support for Dynamics 365 Business Central in Power BI
Improve Power BI Performance with Business Central Incremental Loading
The demand for Incremental Refresh support between Power BI and Dynamics 365 Business Central has been raised for several years, yet it remains a significant challenge for organizations working with large datasets.
While Power BI supports Incremental Refresh, its effectiveness with Business Central is limited because the connector and standard APIs/OData endpoints do not provide a straightforward mechanism for detecting newly inserted or modified records.
A valuable enhancement would be the inclusion of standard system-managed "Created Date/Time" and "Last Modified Date/Time" fields across key Business Central tables, such as:
- G/L Entries
- Value Entries
- Item Ledger Entries
- Sales Invoice Lines
- Purchase Invoice Lines
- Customer Ledger Entries
- Vendor Ledger Entries
- Items and Master Data tables
Having these fields available by default would enable Power BI Incremental Refresh scenarios without requiring partners and customers to develop custom extensions for each implementation.
Currently, many organizations are forced to implement workarounds such as custom APIs, date-based query splitting, historical/current data separation, or custom audit fields, which increase development effort and maintenance costs.
Native support for change tracking and incremental data loading would significantly improve refresh performance, reduce resource consumption, and make Business Central a more scalable data source for Power BI reporting and analytics.
It would be greatly appreciated if Microsoft could provide an update on the roadmap and future plans regarding Incremental Refresh support for Business Central.
Thank You
Agreed, your pain is real. It's worth noting though that the missing piece isn't just timestamp fields. Business Central's OData APIs also lack robust support for server-side change detection (e.g., delta tokens or CDC), which means even if those fields existed natively, incremental refresh would still require significant client-side logic to work reliably at scale.
The deeper ask here is for Microsoft to treat Business Central as a first-class analytical data source and not just a transactional system. Until then, orgs serious about performance should consider bypassing the connector entirely and moving to a proper data integration layer (Fabric pipelines, Azure Data Factory, etc) that can handle delta loads more gracefully than OData ever will.
Hi sumitmanjarme ,
Incremental Refresh in Power BI works well when source tables expose reliable “Created Date/Time” or “Last Modified Date/Time” fields, but Business Central’s standard APIs and OData endpoints don’t consistently provide these. Try to use custom APIs, audit fields, or splitting historical vs. current data.
At present, there’s no native change tracking for Business Central tables, so refresh scenarios can be complex. The best practice is to add custom date fields or extensions that allow Power BI to detect new/changed records. Many users have requested Microsoft to add system-managed fields across key tables, which would make incremental loading much more seamless.
Until native support is introduced, custom extensions or API-based workarounds remain the recommended approach.
Thanks,
Sai Teja
6 Replies
- andrewsommer
Super User
Agreed, your pain is real. It's worth noting though that the missing piece isn't just timestamp fields. Business Central's OData APIs also lack robust support for server-side change detection (e.g., delta tokens or CDC), which means even if those fields existed natively, incremental refresh would still require significant client-side logic to work reliably at scale.
The deeper ask here is for Microsoft to treat Business Central as a first-class analytical data source and not just a transactional system. Until then, orgs serious about performance should consider bypassing the connector entirely and moving to a proper data integration layer (Fabric pipelines, Azure Data Factory, etc) that can handle delta loads more gracefully than OData ever will.
- tayloramy
Hi sumitmanjarme,
I recommend putting in an Idea for this to see if it gains traction: https://community.fabric.microsoft.com/t5/Fabric-Ideas/idb-p/fbc_ideas
Once you post one, come back here and post the link. You have my vote.
SaiTejaTalasilaHi sumitmanjarme ,
Incremental Refresh in Power BI works well when source tables expose reliable “Created Date/Time” or “Last Modified Date/Time” fields, but Business Central’s standard APIs and OData endpoints don’t consistently provide these. Try to use custom APIs, audit fields, or splitting historical vs. current data.
At present, there’s no native change tracking for Business Central tables, so refresh scenarios can be complex. The best practice is to add custom date fields or extensions that allow Power BI to detect new/changed records. Many users have requested Microsoft to add system-managed fields across key tables, which would make incremental loading much more seamless.
Until native support is introduced, custom extensions or API-based workarounds remain the recommended approach.
Thanks,
Sai Teja
- GilbertQ
Would it not be possible to pass through the daytime or the required daytime format through to the API and Odata connector in Business Central? In doing that you could then pass through the incremental refresh dates which will then only return the data that you need to incrementally refresh your semantic model.
Hi sumitmanjarme ,
Thank you andrewsommer for the response provided!
Has your issue been resolved? If the response provided by the community member addressed your query, could you please confirm? It helps us ensure that the solutions provided are effective and beneficial for everyone.
Thank you.Hi sumitmanjarme ,
I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.
Thank you.
