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! Request now

Reply
ABMN
Helper I
Helper I

How to access lakehouses in a notebook when in different workspaces

Here is my scenario.  I'm looking for any guidance or best practices.

 

We have 2 centralized lakehouses (configuration and bronze).  There will be a dev/test version of these and a prod version of these, stored in a dev/test lakehouse workspace and a prod lakehouse workspace.

Each developer has their own individual workspace for development work which is connected to a feature branch.

We have a dev workspace, which is connected to the main branch.

We have a test workspace, which will be deployed to using Fabric deployment pipleines.

We have a prod workspace, which will be deployed to using Fabric deployment pipleines.

 

The individual developer workspaces, dev workspace and test workspace will all use the configuraiton and bronze lakehouse in the dev/test lakehouse workspace.

 

When a developer is creating a notebook, they need to read from the configuration and bronze lakehouses and write to a silver lakehouse that exists in their individual workspace.  When the notebook is deployed to the dev and test workspaces, it still needs to use the same configuration and bronze lakehouses, but would then need to write to the silver lakehouse in the current workspace.

 

What lakehouse should I set as my default lakehouse?

 

Should I add a default lakehouse through the UI or only do it through code (i.e. %%configure)?

 

How can I read/write from a lakehouse that is in a different workspace than my default lakehouse?

 

What is the best way to manage the lakehouse references when using Git and deployment pipelines?  

 

If the default lakehouse is added via the UI, Git does not seem to autobind to a lakehouse with the same name in the current workspace.  It still will reference the default lakehouse that is saved in the notebook.  However, deployment pipelines do autobind the default lakehouse to the same named lakehouse in the curren workspace.

 

If the default lakehouse is added via the UI and is in a different workspace, the notebook cannot be deployed by a deployment pipeline because it will error saying that dependencies do not exist in the target workspace.

 

I know this is a lengthy post and I thew out a lot of questions.  Even if you can help answer some of the questions, I am interested in your feedback.  

 

Thank you in advance for your help.

 

1 ACCEPTED SOLUTION
v-tsaipranay
Community Support
Community Support

Hi @ABMN ,

Thank you for reaching out to the Microsoft fabric community forum.

 

In Microsoft Fabric, it is recommended not to hard-bind a default lakehouse to a notebook using the UI if you plan to move the notebook across workspaces. UI binding saves the workspace GUID, which can cause deployment dependency errors when moving between environments like Dev, Test, and Prod.

For cross-workspace access, it's best to use code-based configuration (such as %%configure or spark config) and reference external lakehouses using OneLake shortcuts or abfss:// paths. With this approach:

  • The notebook should have only the target silver lakehouse of the current workspace as its default, which is set automatically by the pipeline stage.
  • Bronze and config (shared) lakehouses should be referenced in code, not through UI binding.
  • This allows Git to keep the notebook portable and ensures deployment pipelines correctly bind only the silver lakehouse in each stage.

The typical pattern is:

  • Silver lakehouse as the default (workspace/pipeline bound)
  • Bronze and config lakehouses referenced via code (abfss or shortcut).

Hope this helps. Please reach out for further assistance.

 

Thank you.

 

View solution in original post

2 REPLIES 2
ABMN
Helper I
Helper I


@v-tsaipranay   Thanks for the help on this.  This is the approach I was planning to use, but just wanted to reach out and see how other are accomplishing this.

v-tsaipranay
Community Support
Community Support

Hi @ABMN ,

Thank you for reaching out to the Microsoft fabric community forum.

 

In Microsoft Fabric, it is recommended not to hard-bind a default lakehouse to a notebook using the UI if you plan to move the notebook across workspaces. UI binding saves the workspace GUID, which can cause deployment dependency errors when moving between environments like Dev, Test, and Prod.

For cross-workspace access, it's best to use code-based configuration (such as %%configure or spark config) and reference external lakehouses using OneLake shortcuts or abfss:// paths. With this approach:

  • The notebook should have only the target silver lakehouse of the current workspace as its default, which is set automatically by the pipeline stage.
  • Bronze and config (shared) lakehouses should be referenced in code, not through UI binding.
  • This allows Git to keep the notebook portable and ensures deployment pipelines correctly bind only the silver lakehouse in each stage.

The typical pattern is:

  • Silver lakehouse as the default (workspace/pipeline bound)
  • Bronze and config lakehouses referenced via code (abfss or shortcut).

Hope this helps. Please reach out for further assistance.

 

Thank you.

 

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.