The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends September 15. Request your voucher.
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.