Fabric Lakehouse is referenced by different Ids depending on what is referencing it.

[CallumH]

Hi,

This might be a stupid question but why is a lakehouse is Fabric referenced via different Ids in notebooks as in pipelines?

If I look at a notebook in DevOps that has a lakehouse attached:
notebook_name.Notebook -> notebook-content.py

it has Ids for the default lakehouse, aswell as Ids for known lakehouses. These Ids correspond to the Id found in the URL if you go into a lakehouse.

If I look at a pipeline that reads from a lakehouse:

pipeline_name.DataPipeline -> pipeline-content.json

this references the lakehouse via "artifactID" which references the "logicalId" found in:

lakehouse_name.Lakehouse -> .platform

Both of these seem to be correctly replaced using the fabric-cicd package when deploying to another workspace using the replacement value  $items.Lakehouse.lakehouse_name.$id.

Thanks,

Callum

[AntoineW · Accepted solution]

Hello @CallumH,

I understand this can be confusing, but here’s how it works for my understanding:

• Why the IDs differ:
  In Fabric, every Lakehouse has both a physical artifact ID and a logical ID.
  – Notebooks use the physical ID because they connect directly to a specific instance at runtime.
  – Pipelines use the logical ID because they are meant to be portable across environments (Dev → Test → Prod). The Fabric CI/CD process automatically remaps these logical references to the correct artifacts during deployment.

• You can Variable Libraries to centralize environment-specific values such as IDs, paths, or connection strings, organized in value sets (for Dev/Test/Prod).
  This allows notebooks and pipelines to reference variables dynamically at runtime instead of hardcoding environment values, reducing the need for manual edits after deployment.

Hope it can help you !

Best regards,

Antoine

[anilgavhane · Accepted solution]

@CallumH 

Why the IDs Differ

• Notebooks reference the lakehouse using the physical (artifact) ID
• This ID corresponds to the actual instance of the lakehouse in the workspace.
• It’s used for direct runtime access, which is why you see it in the notebook’s .py file and in the lakehouse URL.
• Pipelines reference the lakehouse using the logical ID

• This ID is found in the .platform file and is used to identify the lakehouse across environments (Dev → Test → Prod).
• It enables CI/CD portability, allowing the same pipeline definition to work across multiple workspaces.

How Fabric Handles Deployment

• The fabric-cicd package automatically replaces these IDs during deployment:

• $items.Lakehouse.lakehouse_name.$id resolves to the correct physical ID for the target workspace.
• This ensures that both notebooks and pipelines point to the correct lakehouse instance after deployment.

Best Practices

• Use variable libraries or centralized config notebooks to manage environment-specific values like lakehouse names, paths, and IDs.
• Avoid hardcoding IDs in notebooks—use dynamic references or configuration files stored in the lakehouse itself.
• Understand that logical IDs are tracked in Git, while physical IDs are runtime-specific and not exposed in Git metadata.

If you're curious about how to extract or manage these IDs programmatically or want help setting up a config-driven deployment model, I can walk you through that too.

[AntoineW · Accepted solution]

Hello @CallumH,

I understand this can be confusing, but here’s how it works for my understanding:

• Why the IDs differ:
  In Fabric, every Lakehouse has both a physical artifact ID and a logical ID.
  – Notebooks use the physical ID because they connect directly to a specific instance at runtime.
  – Pipelines use the logical ID because they are meant to be portable across environments (Dev → Test → Prod). The Fabric CI/CD process automatically remaps these logical references to the correct artifacts during deployment.

• You can Variable Libraries to centralize environment-specific values such as IDs, paths, or connection strings, organized in value sets (for Dev/Test/Prod).
  This allows notebooks and pipelines to reference variables dynamically at runtime instead of hardcoding environment values, reducing the need for manual edits after deployment.

Hope it can help you !

Best regards,

Antoine

[CallumH]

How come it's not possible to see that Physical Id in DevOps for the lakehouse other than in a notebook? Are pipelines not also referencing a specific instance at run time? 
The Physical Id as you call it is stored in the notebook defintion in DevOps and is replaced on deployment just as the logical Id is in the pipeline defintion. Only difference is I can find the logical Id in the lakehouse definition, I can't find the physical Id.