Deployment Pipeline with Fabric Link (Dataverse) – Lakehouse

[SHAccion]

Hi Team,

I’m working on a Microsoft Fabric setup with Dataverse (D365) using Fabric Link and facing challenges with deployment across environments.

Current Setup:

- Separate workspaces for Dev and Test (using Deployment Pipeline)

- Fabric Link created in Dev (Dataverse → Lakehouse(Automatic Created))

- In Test, Fabric Link is also created separately (since it’s environment-specific)

- Lakehouse name is kept the same across environments

- Gold layer logic is implemented using SQL endpot

- Semantic model and reports are built on top of Gold views

Challenges:

1. Fabric Link always creates a new Lakehouse and cannot attach to an existing one deployed via pipeline

2. Deployment Pipeline does not include Fabric Link (expected), but causes conflicts if Lakehouse already exists in target workspace

3. We are not able to change fabric link dev to test.

What I’m trying to achieve:

-  deploying Lakehouse via pipeline dev to test.

- Use Fabric Link per environment for raw data

- Deploy only view(Gold logic), Semantic Model, and Report

- Minimize manual steps

Questions:

- What is the recommended architecture for handling Fabric Link with Deployment Pipelines?

- Is there a way to make notebooks environment-independent (auto-bind to local Lakehouse)?

- Any best practices to automate Gold layer creation across Dev/Test/Prod?

- When we are deplying the Dev to test that time lakehouse link shoud be changes to test. 

Would appreciate guidance from experts who have implemented similar setups.

Thanks!

[nilendraFabric · Accepted solution]

hi @SHAccion 

We cant control tjis atm , Fabric Link always creates a new Lakehouse and cannot attach to an existing one deployed via pipeline

Use Fabric Link separately in each environment and do not deploy the auto-created raw Lakehouse through Deployment Pipeline. The better approach is to let Dev, Test, and Prod each have their own Dataverse-to-Fabric raw layer, then deploy only the Gold views/logic, semantic model, and reports across environments. This fits Fabric guidance that environment-specific configuration should be handled per stage, not automatically converted during deployment


For Gold layer automation, keep the SQL/view logic in source control and deploy or run the same scripts in each environmen

[nilendraFabric · Accepted solution]

don’t recreate it manually. Promote the semantic model through the pipeline, then use a data source rule so Test points to the Test SQL endpoint.

[SHAccion]

Its works , Thank you!

[v-prasare]

Hi @SHAccion,

We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[v-prasare · Accepted solution]

Hi @SHAccion,

We would like to confirm if our community members answer resolves your query or if you need further help. If you still have any questions or need more support, please feel free to let us know. We are happy to help you.

@nilendraFabric ,Thanks for your prompt response

Thank you for your patience and look forward to hearing from you.
Best Regards,
Prashanth Are
MS Fabric community support

[SHAccion]

I agree with the proposed solution, but I have one question.
When we create a semantic model using the SQL endpoint in Dev and then deploy or move that semantic model to Test, we would need to update the data source to point to the Test SQL endpoint, correct?
However, it seems the source cannot be changed once it’s connected. Does this mean we are expected to recreate or manually import the semantic model in each environment instead of promoting it through the pipeline?

[nilendraFabric · Accepted solution]

don’t recreate it manually. Promote the semantic model through the pipeline, then use a data source rule so Test points to the Test SQL endpoint.

[nilendraFabric · Accepted solution]

hi @SHAccion 

We cant control tjis atm , Fabric Link always creates a new Lakehouse and cannot attach to an existing one deployed via pipeline

Use Fabric Link separately in each environment and do not deploy the auto-created raw Lakehouse through Deployment Pipeline. The better approach is to let Dev, Test, and Prod each have their own Dataverse-to-Fabric raw layer, then deploy only the Gold views/logic, semantic model, and reports across environments. This fits Fabric guidance that environment-specific configuration should be handled per stage, not automatically converted during deployment


For Gold layer automation, keep the SQL/view logic in source control and deploy or run the same scripts in each environmen