Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Learn more

Reply
stef_gallo
New Member

SysRowVersion indexes created in D365 SCM / FO during tables synchronization in Fabric

Hello,

 

On our BI solution, we are using a Fabric link configuration to load D365 F&SCM tables data into Dataverse on the Bronze layer.

 

In D365 F&SCM you have to enable "Allow Row version tracking" on each table that you want to select for synchroonization.

This will enable the SysRowVersion field on the D365 F&SCM that is modified to keep track of all the table updates and guarantee incremental logic for transferring only the delta changes to Fabric at each synch refresh.

 

When you select the table in the Fabric link, one or more indexes that include SysRowVersion are created in D365 F&SCM as soon as the table is synchronized.

 

As these indexes get updated in D365 on every record change, highly concurrent updates on large tables that have these indexes can causes locks on the ERP database.

This scenario can cause performance degradation on the ERP system and this can only get worse as the tables size grow.

Once again, this behavior can influence only highly concurrent transactional processes, which is the case for ERP OLTP databases.

 

Has anyone used this configuration and noticed a degradation of the D365 SCM / FO performance before ?

 

Any feeadback/suggestion ?

 

Thank you

Best Regards

Stefano G.

1 ACCEPTED SOLUTION
Anonymous
Not applicable

Hi @stef_gallo 

Thanks for the detailed explanation — you're absolutely right that enabling the Fabric link with row version tracking can create additional indexes (like on SysRowVersion and RecId), which may impact performance on high-transaction tables such as INVENTTRANS and INVENTSUM.

This is a known behavior, and under high-concurrency workloads, these indexes can cause locking and slow down insert/update operations.

To reduce the impact, consider syncing only essential tables, or using filtered/custom views to limit data volume. If real-time sync isn’t critical, running the sync during off-peak hours can help. It’s also worth reviewing and tuning index configurations where possible. In some cases, alternatives like Data Export Service (DES) have been used for heavy tables to offload the load from the ERP system.

If this solution helps, please consider giving us Kudos and accepting it as the solution so that it may assist other members in the community.

Thank you.

View solution in original post

4 REPLIES 4
Anonymous
Not applicable

Hi @stef_gallo 

Thanks for the detailed explanation — you're absolutely right that enabling the Fabric link with row version tracking can create additional indexes (like on SysRowVersion and RecId), which may impact performance on high-transaction tables such as INVENTTRANS and INVENTSUM.

This is a known behavior, and under high-concurrency workloads, these indexes can cause locking and slow down insert/update operations.

To reduce the impact, consider syncing only essential tables, or using filtered/custom views to limit data volume. If real-time sync isn’t critical, running the sync during off-peak hours can help. It’s also worth reviewing and tuning index configurations where possible. In some cases, alternatives like Data Export Service (DES) have been used for heavy tables to offload the load from the ERP system.

If this solution helps, please consider giving us Kudos and accepting it as the solution so that it may assist other members in the community.

Thank you.

Anonymous
Not applicable

Hi @stef_gallo 
Thank you for reaching out microsoft fabric community forum. 
Please have a look at the documentation which has a similar issue; that might help you get an idea:
Product-specific guidance for optimizing performance - Dynamics 365 | Microsoft Learn

If you need any further assistance or have any questions, please feel free to reach  us.

 

If this solution helps, please consider giving us Kudos and accepting it as the solution so that it may assist other members in the community.

Thank you.


Hi v-shamiliv,

 

Thank you for your feednack.

We are sure that the performance degradation has nothing to do with a D365 system or db that is not optimized.

The reported performance issues with D365SCM AXDB, relates to insert and update operations due to indexes created on SYSROWVERSION and RECID after enabling the Dynamics 365 Fabric Synapse link with Microsoft Fabric. 

The synchronization of a table from Fabric triggers the creation of b-tree indexes on the related D365 table.

With sceanrios of higly concurrent updates on D365 ERP tables such us INVENTTRANS or INVENTSUM that contain milions of records, such b-tree indexes can cause severe perofrmance degradation on the D365 ERP system.

 

Does anyone have experience with such configuration (D365 ERP + Fabric link) and can provide a feedback on if and how this default synch behavior in the D365 and Fabric  integration with change tracking can be optimized so that the D365 ERP performance doesn't suffer?

Thank you. 

stef_gallo
New Member

I'd like to rephrase the last question:

 

Does anyone have experience with such configuration (D365 ERP + Fabric link) and can provide a feedback on if and how this default behavior in the D365=>Fabric  incremental logic with change tracking influenced the ERP performance ?

Helpful resources

Announcements
Fabric Data Days Carousel

Fabric Data Days

Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!

October Fabric Update Carousel

Fabric Monthly Update - October 2025

Check out the October 2025 Fabric update to learn about new features.

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.