Fabric workspace folder name change leads to sync and deployment issues

[FredrikLundberg]

After having changed a folder name from Entso-e to enstso and merged into the branch that was used in a workspace it could not sync to these new changes. Removing all the files and the folder to sync new files didnt work either. Disconnecting and reconnecting did not work. By deleting the workspace and making a new one we got the proper code into the workspace. However, when we then tried to use the deployment pipeline into the other repo that had the same code as the previous before the merge it again gave an error as below, please advise on a solution:

"

Deployed items with the same name in the target and source stages are not bound. This may be due to recent actions, such as deleting or adding new items, still being in process. Learn more NB_MergeSilver_Entso-e_ATL NB_MergeSilver_Entso-e_AGPT NB_MergeSilver_Entso-e_EP NB_MergeSilver_Entso-e_IP NB_MergeSilver_Entso-e_ICP NB_MergeSilver_Entso-e_TV Please try again in a few minutes. If it still doesn't work, contact support and provide the technical details below. Hide details Activity ID... Request ID... Correlation ID... 

"

[burakkaragoz · Accepted solution]

Hi @FredrikLundberg ,

This issue is related to how Fabric tracks item bindings across deployment stages. When you renamed the folder from Entso-e to entso, the pipeline likely lost the internal binding references between source and target items — even if the item names look the same.

Here’s how you can fix it:

1. In the deployment pipeline, go to the target stage (where the error occurs).
2. Manually delete the items listed in the error (e.g. NB_MergeSilver_Entso-e_ActualTotalLoad, etc.).
3. Then go back to the source stage, and deploy again — this time Fabric will treat them as new items and rebind them properly.

⚠️ Important: Just renaming folders or files in Git doesn’t always update the internal Fabric bindings. If the item ID changes or the system thinks it’s a new object, it won’t auto-bind.

If this keeps happening, consider using deployment rules or binding overrides (if available in your environment) to control how items are matched.

Let me know if you want help scripting this or automating cleanup via API.

If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.

[FredrikLundberg]

Additionally, isn't there a more automatic way of handling this or perferred way? To have to delete these for Fabric to recreated them with deployment pipelines doesn't seem like a solution that we can have in production

[FredrikLundberg]

Hi @burakkaragoz 

Tank you for the information! However, I understand that fabric may not recognize that the renamed folder is the same as the old one but why does it yield an error instead of just writting a new folder and removing the old folder? It seems pretty simple when its only code just for it to delete what it doesnt detect as being there anymore(Entso-e folder) and write what it detect as new (entso-e folder) or am I misunderstanding something? 

[v-priyankata]

Hi @FredrikLundberg 

Thank you for using Microsoft Community Forum.

Even if two items look the same, they might have different internal IDs after you rename or move them. If Fabric automatically deleted the old item and replaced it with the new one, it could accidentally break important links or settings. For example, reports might lose their data source connections, permissions, or refresh schedules, which could affect other users who depend on them.

If this information is helpful, please “Accept as solution” and give a "kudos" to assist other community members in resolving similar issues more efficiently.
Thank you.

[FredrikLundberg]

Hi priyankata!
I understand but at least there should be an override option, because it is not safe or a production based solution to have users go in manual and delete the files. If you can provide me with any input in how to automate a deployment which can deal with such issues as a deleted or renamed folder I will definitely say that you have solved it.

Regards, Fredrik Lundberg

[v-priyankata · Accepted solution]

Hi @FredrikLundberg,
Thank you for using Microsoft Community Forum.

I understand your thoughts, i suggest submitting your detailed feedback and ideas through Microsoft's official feedback channels, such as Microsoft Fabric Ideas. Feedback submitted through these channels is frequently reviewed by the product teams and can contribute to meaningful improvements. Fabric Ideas - Microsoft Fabric Community.

If this information is helpful, please “Accept as solution” and give a "kudos" to assist other community members in resolving similar issues more efficiently.
Thank you

[v-priyankata]

Hi @FredrikLundberg 

I hope you've submitted this as an idea in the Ideas Forum, as of now we are closing this thread, For any further discussions or questions, please start a new thread in the Microsoft Fabric Community Forum  we’ll be happy to assist.

Thank you for being part of the Microsoft Fabric Community.

[burakkaragoz · Accepted solution]

Hi @FredrikLundberg ,

This issue is related to how Fabric tracks item bindings across deployment stages. When you renamed the folder from Entso-e to entso, the pipeline likely lost the internal binding references between source and target items — even if the item names look the same.

Here’s how you can fix it:

1. In the deployment pipeline, go to the target stage (where the error occurs).
2. Manually delete the items listed in the error (e.g. NB_MergeSilver_Entso-e_ActualTotalLoad, etc.).
3. Then go back to the source stage, and deploy again — this time Fabric will treat them as new items and rebind them properly.

⚠️ Important: Just renaming folders or files in Git doesn’t always update the internal Fabric bindings. If the item ID changes or the system thinks it’s a new object, it won’t auto-bind.

If this keeps happening, consider using deployment rules or binding overrides (if available in your environment) to control how items are matched.

Let me know if you want help scripting this or automating cleanup via API.

If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.