u/Banjo1980

Looking for advice on how others are handling default lakehouse configuration in Fabric notebooks when the notebook lives in an engineering workspace and the lakehouse is in a separate storage workspace.

My setup follows a pattern where notebooks and lakehouses are in different workspaces, and I have DEV/PPE/PROD environments each with their own storage workspace. I'm using a Variable Library (VL) to manage environment-specific configuration and want the notebooks to automatically target the correct lakehouse per environment without any code changes.

What I've tried:

The obvious approach would be to use an item reference variable in the VL and dereference it in `%%configure`. However, I can't get item references to work this way. The following code successfully retrieves the item reference object, but `run_cell_magic` doesn't work for `%%configure` as it's handled by the Fabric/Livy layer rather than IPython:

vl = notebookutils.variableLibrary.getLibrary("VL_MyLibrary") 
lh = vl.it_lh_mydb 
lh_name = "LH_MyDatabase" 
lh_itemId = lh.apply("itemId") 
lh_workspaceId = lh.apply("workspaceId") 

config_json = f""" {{   
    "defaultLakehouse": {{     
        "name": "{lh_name}",     
        "id": "{lh_itemId}",     
        "workspaceId": "{lh_workspaceId}"   }} 
}}

I also confirmed that the `%%configure` variable resolver doesn't support dot notation for item reference sub-properties — `$(/**/VL_MyLibrary/it_lh_mydb.itemId)` throws `InvalidReferenceFormat`.

According to the Microsoft docs, item references in notebooks through `%%configure` aren't supported, which explains the error.

The only way I've found that works is to add flat string variables to the VL for the lakehouse ID and workspace ID, then reference those in `%%configure`:

%%configure -f {   
    "defaultLakehouse": {     
        "name": "LH_MyDatabase",     
        "id": { "variableName": "$(/**/VL_MyLibrary/lh_mydb_id)" },     
        "workspaceId": { "variableName": "$(/**/VL_MyLibrary/lh_mydb_workspace_id)" }   
} }

This works, but it means duplicating information that's already captured in the item reference variable. It feels like a gap — item references exist precisely to encapsulate workspace + item ID pairs, but they can't be used where you need them most.

1. Is anyone else handling this pattern differently? Is there a cleaner approach I'm missing?

2. Does anyone know if support for item references in `%%configure` is on the roadmap? It seems like an obvious feature gap given that item references are the recommended way to manage cross-workspace connections in VLs.

3. Are there any other approaches for making the default lakehouse environment-aware when the lakehouse is in a different workspace to the notebook?

Any advice appreciated!