Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
By default, a workspace with restricted inbound public access restricts connections from other workspaces. To enable cross-workspace communication in this scenario, you must use either managed private endpoints or a data gateway.
These options are necessary even if private endpoints exist between the client and one or both workspaces. The reason is that the source workspace (not the client) initiates the connection. If the target workspace allows inbound public access, connections from other workspaces are permitted without additional configuration.
Managed private endpoint
A managed private endpoint establishes a trust relationship from the source workspace (Workspace 1 in the following diagram) to the target workspace (Workspace 2). The trust relationship allows connections from the source workspace to the target workspace. You can create a managed private endpoint by using workspace settings in the Microsoft Fabric portal or the API.
To create a managed private endpoint to the target workspace, you need the Azure Private Link service's resource ID for the target workspace. You can find this resource ID in Azure by viewing the resource JSON for the workspace. Ensure that the workspace ID in the JSON matches the intended target workspace.
The Private Link service owner for Workspace 2 needs to approve the request for a managed private endpoint in Azure private link center > Pending connections.
Cross-workspace connections that use managed private endpoints are currently limited to the following scenarios:
- Shortcut access from one workspace to another workspace.
- A notebook in one workspace accessing a lakehouse in another workspace. When the notebook is in the source workspace, connecting to the target workspace requires using the workspace's fully qualified domain name (FQDN).
- A pipeline in one workspace accessing a notebook in another workspace.
- An eventstream in one workspace accessing a lakehouse in another workspace.
- An eventstream in one workspace accessing an eventhouse in another workspace when it's using event processing before ingestion.
For examples of how to set up cross-workspace communication by using managed private endpoints, see the following articles:
- Accessing a lakehouse in an inbound restricted workspace from a notebook in an open workspace
- Use a pipeline to access a lakehouse in an inbound restricted workspace from an open workspace
Data gateway
You can use a virtual network data gateway or an on-premises data gateway (OPDG) to establish cross-workspace communication with a workspace that has a policy that restricts inbound public access. With either option, you need to create a private endpoint on the virtual network that holds the data gateway. This private endpoint should point to the Private Link service for the target workspace.
Virtual network data gateway
The following diagram illustrates how the connection is established through a virtual network data gateway.
For an example, see Access inbound restricted lakehouse data from Power BI by using a virtual network gateway.
On-premises data gateway
The following diagram illustrates how the connection is established through an OPDG.
For an example of how to set up cross-workspace communication by using an on-premises data gateway, see Access inbound restricted lakehouse data from Power BI by using an on-premises data gateway.