Currently, Fabric Spark Notebook & Eventstreams run through the managed private endpoint defined in the Fabric workspace.
For Fabric UDF's (User Data Functions), this is not supported.
The idea focuses on allowing UDF flows to run through the private endpoint (of the Fabric workspace).
The most common use case is getting secrets from an Azure Key Vault that is not open to public internet (default in an enterprise setup).
Note that
a) it is possible to get secrets in the notebook over MPE and call the UDF, but this setup is not desired for UDF's in the context of Power BI integrations. In this case, the UDF is being called by a linked button action from Power BI.
b) Fabric IP whitelisting is not desired as this setup can easily be replicated by another party
@deborshi_nag
@mksuni
1 Comment
We strongly support this feature request.
Private connectivity for Fabric UDFs is becoming a baseline enterprise requirement rather than a nice-to-have. Across enterprise implementations, organizations are increasingly standardizing on "private access only" for services such as Azure Key Vault, storage accounts, databases, and internal APIs as part of their security and compliance posture.
Today, the lack of private connectivity support for UDF execution creates an inconsistency within Fabric and with broader Microsoft platform networking capabilities. Notebooks and other workloads can securely access private resources, but UDFs cannot. This becomes particularly problematic when UDFs are exposed through Power BI experiences, where introducing intermediary notebooks or relying on IP allowlists is not an acceptable enterprise architecture.
For many organizations, the ability for Fabric UDFs to securely access private-only services through private connectivity is a critical prerequisite for production adoption and governance approval.
