Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!To celebrate FabCon Vienna, we are offering 50% off select exams. Ends October 3rd. Request your discount now.
Today, User Data Functions (UDFs) expose user execution context such as PreferredUsername
, Oid
, and TenantId
. However, there’s no way to see where the UDF was invoked from.
It would be very useful if UDFs could also capture the workspace id, item id, and item type of the calling object (e.g., Power BI report, semantic model, data pipeline, notebook, etc.).
Why this matters:
Improves troubleshooting and auditing of UDF calls
Helps distinguish between calls from developer environment vs. production reports
Makes it easier to design robust logging for compliance and monitoring
Suggested Implementation:
Extend UserDataFunctionContext
with fields such as:
WorkspaceId
WorkspaceName
ItemId
ItemName
ItemType
(e.g., Report, Dataflow, Pipeline, Notebook)
Impact:
This would make UDF logging more transparent and allow developers and admins to track usage across environments with better precision.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.