Deployment Rules for Semantic Models - Change connection from DEV to TEST

[LopesN]

Hello everyone,

After setting a deployment rule (fabric deployment pipelines) to dynamically change the Semantic Model source (Lakehouse) from DEV to TEST workspace, I cannot use the compare feature anymore, since I am receiving an error.

Everything is working, the model was correctly deployed and the lineage is correct, but no matter what I try, the "Compare" option in the deployment always return an error now.

Don't know if this is due to changing location of the destination workspace that might have "messed up" the way the Compare gets the files. But is very anoying to not be able to see schema changes now.

Anyone has any idea of what this could be or how to correct this?

My objective is just to have the Semantic Model automatically get the data from TEST Workspace, after deployment.

Thank you in advance!

[Rufyda]

Hi
Glad that your query got resolved. Please continue using Fabric Community for any help regarding your queries.

[v-ssriganesh]

Hello  @LopesN,
Sorry for the inconvenience caused. Please consider raising a Microsoft support ticket for further investigation. You can explain all the troubleshooting steps you have taken to help them better understand the issue.

You can create a Microsoft support ticket with the help of the link below:
https://learn.microsoft.com/en-us/power-bi/support/create-support-ticket

If this helps, please accept it as a solution and drop a "Kudos" so other members can find it more easily.

Thank you.

[v-ssriganesh]

Hello @LopesN,

We are following up once again regarding your query. Could you please confirm if the issue has been resolved through the support ticket with Microsoft?

If the issue has been resolved, we kindly request you to share the resolution or key insights here to help others in the community. If we don’t hear back, we’ll go ahead and close this thread.

Should you need further assistance in the future, we encourage you to reach out via the Microsoft Fabric Community Forum and create a new thread. We’ll be happy to help.

Thank you for your understanding.

[LopesN]

Hello @v-ssriganesh ,

After further testing, the problem is still happening.
I will follow up and create a ticket or a new thread on the Community Forum to see if I get some feedback.
Thank you.

[LopesN]

Update:
I deleted the Lakehouse and any Semantic Models connected to it, re-deployed everything from DEV --> still not working, cannot see Compare feature!

Alternative (it might help someone in a similar situation):
To point the Semantic Model to the TEST Workspace (instead of DEV) I used semantic link library in a pyspark notebook with the following code:

%pip install semantic-link-labs

from sempy_labs.directlake import update_direct_lake_model_lakehouse_connection

dataset_name = "Lakehouse_Test_NL_SM" #dataset after deployment (in TEST but refering to DEV lakehouse)

workspace_name = None

lakehouse_name = None

lakehouse_workspace_name = None

update_direct_lake_model_lakehouse_connection(

    dataset = dataset_name,

    workspace = workspace_name,

    lakehouse = lakehouse_name,

    lakehouse_workspace = lakehouse_workspace_name

)

To be clear, this issue is not solved, any Semantic Models I create on top of this Lakehouse cannot preview the changes in metadata with Compare feature!
If someone can provide some help I would appreciate it, just so in the future I (or anyone else) don't have to delete this Lakehouse and create a new one to be able to use this Compare feature again!

[burakkaragoz]

Hi @LopesN ,

Yeah, I’ve seen this happen when using deployment rules to switch data sources in semantic models. The deployment itself works fine, but the Compare step breaks because it tries to diff the model against a version that now points to a different Lakehouse path or workspace.

A couple of things you can try:

• Go to the deployment pipeline settings and double-check if the rule is applied before or after the compare step. If it’s applied after, the compare might still be looking at the old connection.
• Try removing the rule temporarily and running Compare again. If it works, then re-add the rule and deploy.
• Also, make sure the TEST workspace has the same schema and metadata as DEV. Even small mismatches can cause Compare to fail silently.

This might be a limitation in how Fabric handles Compare when dynamic data source switching is involved. You can track known issues or raise a ticket here:
https://support.fabric.microsoft.com

Let me know if you want to test this with a stripped-down model to isolate the issue.

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.

Translation and formatting supported by AI

[LopesN]

Hello @burakkaragoz, thank you for your answer!

Regarding your points:

• Go to the deployment pipeline settings and double-check if the rule is applied before or after the compare step. If it’s applied after, the compare might still be looking at the old connection.
  A: I think the rules are applied before Compare, since after changing rule it detects changes from DEV to TEST
• Try removing the rule temporarily and running Compare again. If it works, then re-add the rule and deploy.
  A: I removed the rule but still doesn't work. And what is truly worst is that now I cannot use Compare with any other Semantic Models that use the same Lakehouse as source!
  Without rules, it still points to DEV and as you can see in the following image, now even in this case I get an error, so if I want to use Compare feature, I would not be able to create Semantic Models from this lakehouse (which seems like a really bad news, since now I can't even "revert this" situation)
  
  
• Also, make sure the TEST workspace has the same schema and metadata as DEV. Even small mismatches can cause Compare to fail silently.
  A: Only Compare feature is failling, so if the schema is the same I cannot see that feature.
  I need to force some changes (in my case I removed a table in DEV) so that Compare feature detects a change and shows the option to see changes (which is where the error is shown).
  I will try to make some more tests but I'm not sure what further steps to take honestly.
  

[burakkaragoz · Accepted solution]

@LopesN ,

Thanks a lot for the update — and for sharing the PySpark workaround using semantic-link-labs, that’s super valuable for others who might hit the same wall.

From what you’ve described, it really looks like the Compare feature is holding onto some internal metadata reference tied to the original Lakehouse, and even after deletion + redeployment, it doesn’t fully reset.

Here’s a quick recap of what you tried (and a small tweak others might try too):

✅ What you did:

• Deleted the Lakehouse and all related Semantic Models
• Re-deployed from DEV
• Used this code to redirect the model to TEST:

%pip install semantic-link-labs
from sempy.labs.directlake import update_direct_lake_model_lakehouse_connection

dataset_name = "Lakehouse_Test_NLSM"  # Name of the deployed dataset
workspace_name = None                 # Optional: specify if needed
lakehouse_name = None                 # Optional: specify if needed
lakehouse_workspace_name = None      # Optional: specify if needed

update_direct_lake_model_lakehouse_connection(
    dataset = dataset_name,
    workspace = workspace_name,
    lakehouse = lakehouse_name,
    lakehouse_workspace = lakehouse_workspace_name
)

This is a solid approach — but unfortunately, as you said, Compare still fails, even with a clean redeploy.

---

🔍 What else to try:

• Try creating a completely new Lakehouse (with a different name) and deploy a fresh Semantic Model on top of it. If Compare works there, it confirms the issue is tied to internal lineage/cache on the original Lakehouse.
• If you’re comfortable, try using the Fabric REST APIs to inspect or reset lineage metadata (though this is more advanced and not always exposed).
• Definitely raise this with Microsoft Fabric support — this feels like a backend issue that needs cleanup on their side.

Let me know if you want help testing with a minimal setup — happy to assist.

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.

*This response was supported by AI for translation and text editing purposes.

[LopesN]

I have done some further testing but was not able to correct this issue.
I will create a ticket with microsoft to explore what the problem might be.
Thank you again for your feedback (and sorry for the delay in my answer)!