Glossary
What is CUSTOMDATA?
CUSTOMDATA() is a DAX function that reads a free-text value an application passes when embedding a Power BI report. You use it in role filters for row-level security, for example to filter on a customer code.
CUSTOMDATA explained
When embedding for customers, end users often do not exist in Microsoft Entra ID, so USERPRINCIPALNAME() means little. With CUSTOMDATA() the application passes its own value in the embed token, such as a customer code or branch number, and the role filter in the model reads that value.
A typical role filter is [CustomerCode] = CUSTOMDATA(). You can pass several values in one string and split them in DAX, but keep it as simple as possible: every extra step is a chance for an error.
The value comes from the application, so the application must determine it reliably. Also check what the filter does with an empty value, so that a missing code does not mean someone sees everything.
Example
Acme Groothandel gives every dealer access to a purchasing report. When embedding, the portal passes the dealer code, for example "D-1042", as CUSTOMDATA, and the role filter on the dealer table shows only that dealer's orders.
CUSTOMDATA in ENABLE
ENABLE can optionally pass a value through CUSTOMDATA() for row-level security, linked to a profile or user tag. A user without a tag gets no access rather than unfiltered data.
FAQ
Frequently asked questions
When should you use CUSTOMDATA instead of USERPRINCIPALNAME?
Use CUSTOMDATA when users are not in Microsoft Entra ID or when you want to filter on something other than the username, such as a customer code. That is often the case with Power BI Embedded for customers.
How do you use CUSTOMDATA in a role filter?
You write a DAX filter in the role, such as [CustomerCode] = CUSTOMDATA(). The application passes the customer code in the embed token and the model shows only the rows with that code.
Is CUSTOMDATA secure?
It is as secure as the application that sets the value. The user cannot change the value, but a mistake in the application can expose the wrong data.
Further reading
- ResourcesRow-level security in Power BI explainedRow-level security (RLS) in Power BI is a security layer in the semantic model that determines which rows of data a user gets to see. Everyone opens the same report, but a regional manager only sees their own region and a customer only their own orders. You define RLS in roles with DAX filters: static with fixed values, or dynamic based on who is viewing.Read more
- PlatformPower BI row-level security and dashboard accessAccess profiles, Power BI row-level security, two-factor authentication and an audit log.Read more
- ResourcesWhat is Power BI Embedded? Scenarios and optionsPower BI Embedded is the way to show Power BI reports and dashboards in your own application, website or portal, instead of in Microsoft's Power BI service. There are two variants: embedding for your organisation, where users sign in with their own Microsoft account, and embedding for your customers, where the application handles access through a service principal and end users do not need a Power BI licence. For that second variant, you need capacity in production.Read more
- ResourcesGlossary of data, AI and Power BI termsWhat is a service principal, row-level security, a semantic model, text-to-SQL or RAG? Short, clear definitions of terms around data, Power BI and AI.Read more
Use AI on your own data. Securely, and without the headache.
In an online demo we show how ENABLE makes your data securely available and how you build on it: describing an app in the AI Builder, plain-language questions, dashboards and APIs. And how we set it up and manage it for you.