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.
Private links in Microsoft Fabric can affect how events are consumed through Real-Time hub. Both tenant-level private links and workspace-level private links enforce network restrictions that can block event creation and delivery depending on the event source and network configuration.
Note
It might take up to 30 minutes for changes to the workspace networking configuration to take effect.
Tenant-level private links and Azure events
When the Block Public Internet Access tenant setting is enabled as part of tenant-level private link configuration, Azure event sources outside the tenant are blocked from delivering events into Fabric. This restriction applies because Azure events (such as Azure Blob Storage events) originate from outside the Fabric tenant and require public network access to deliver events.
Impact on Azure event consumption
When Block Public Internet Access is enabled:
| Scenario | Result |
|---|---|
| Creating a new Azure event consumer (for example, configuring an Activator alert to monitor blob uploads from an Azure Storage account) | Configuration is blocked. Consumer creation fails. |
| Existing Azure event consumer (for example, an Eventstream that was already receiving Azure Blob Storage events) | Events are dropped at the Azure source and never reach Fabric. The configuration doesn't enter a paused state. To restore delivery, add the Azure Event Grid system topic to the allow list as a trusted resource in the workspace inbound networking settings. To discover dropped events, investigate the metrics and diagnostic logs for the Azure resource (such as the Azure Storage account) in the Azure portal. |
Impact on Fabric event consumption
Fabric events (such as Job events, Workspace item events, and OneLake events) aren't affected by tenant-level private link configuration because they originate from within the Fabric tenant.
Workspace-level private links and cross-workspace events
When workspace-level private links are configured on a workspace to block public access, event consumers (such as Activator alerts or Eventstreams) in other workspaces can't consume events from items in that workspace unless a private link is established from the consumer's network to the source workspace.
In Azure and Fabric Events, the source workspace is the workspace where the events originate from, and the consumer workspace is the workspace where the Activator alert, Eventstream, or other consumer item is created. Workspace-level private links are enforced on the source workspace only. The consumer workspace's private link configuration doesn't impact the events flow. Event consumption within the same workspace is always allowed, regardless of private link settings.
How workspace-level private links affect event consumption
The following table summarizes how workspace-level private link settings affect event consumption.
| Source workspace private links | Consumer workspace private links | Private link from consumer to source | Result |
|---|---|---|---|
| A (public access blocked) | A (public access blocked) | Not required | Consumption succeeds because source and consumer are in the same workspace. |
| A (public access blocked) | B | Not established | Consumption is blocked. Consumer creation fails with an error. |
| A (public access blocked) | B | Established | Consumption succeeds because the consumer connects via a private link to the source workspace. |
| A | B (public access blocked) | Not required | Consumption succeeds because the consumer workspace's private link configuration doesn't impact the events flow. |
Examples
The following examples illustrate how workspace-level private links affect different event types.
Fabric events: OneLake events
Suppose you configure an Activator alert in Workspace A to monitor OneLake events from a lakehouse in Workspace B. In this case, Workspace B is the source workspace (where the events originate) and Workspace A is the consumer workspace (where the Activator alert is created). If Workspace B blocks public network access, this configuration fails unless a private link is established from Workspace A's network to Workspace B.
Fabric events: Job events
Suppose you create an Eventstream in Workspace A to capture Job events emitted by a pipeline in Workspace B. Workspace B is the source workspace because the pipeline job runs there, and Workspace A is the consumer workspace because the Eventstream is created there. If Workspace B blocks public network access, the Eventstream can't receive events from the pipeline unless a private link is established from Workspace A's network to Workspace B.
Azure events: Azure Blob Storage events
When you configure a consumer to receive Azure Blob Storage events, an Eventstream item is created in a Fabric workspace to represent the Azure source. This Eventstream item acts as the bridge between the Azure source and Fabric consumers.
For example, suppose an Eventstream item for Azure Blob Storage events is created in Workspace A, and an Activator alert in Workspace B consumes those events. Workspace A is the source workspace (because it contains the Eventstream item that represents the Azure source) and Workspace B is the consumer workspace (because the Activator alert is created there). If Workspace A blocks public network access, the Activator alert in Workspace B can't consume those events unless a private link is established from Workspace B's network to Workspace A.
Note
Azure events are also subject to tenant-level private link restrictions. Even if workspace-level private links allow the connection, Azure event delivery is still blocked if the Block Public Internet Access tenant setting is enabled. See Tenant-level private links and Azure events for details.
Configuration changes after consumer creation
If workspace-level private link settings change after a consumer is already configured, the system detects the change and pauses the configuration. To restore event delivery, delete and recreate the consumer configuration.
Workspace-level private link changes
For example, suppose an Activator alert in Workspace A is configured to consume Job events from a pipeline in Workspace B while public access is allowed on Workspace B. If a workspace admin later enables workspace-level private links on Workspace B and blocks public access, the system detects the network policy change and pauses the configuration. To restore delivery, allow public access on the source workspace or establish a private link from the consumer's network to the source workspace, then delete and recreate the consumer configuration.
For details on how to discover and troubleshoot paused configurations, see Paused event configurations in Real-Time hub.
Tenant-level private link changes
If a tenant admin enables Block Public Internet Access after Azure event consumers are already configured, the events are dropped at the Azure source and never reach Fabric. The configuration doesn't enter a paused state in Real-Time hub. To discover dropped events, investigate the metrics and diagnostic logs for the Azure resource (such as the Azure Storage account) in the Azure portal.