Advance your Data & AI career with 50 days of live learning, dataviz contests, hands-on challenges, study groups & certifications and more!
Get registeredGet Fabric Certified for FREE during Fabric Data Days. Don't miss your chance! Request now
I'm making a report that contains RLS rules based on the function USERPRINCIPALNAME(). Basically, I've created a measure that will:
- get logged in user's email
- do a VALUELOOKUP and find their user_id
- check in a table what permissions that user_id has
- hide or show values based on permissions
The measures are working as expected. Now my client wants to embed this report in a website (outside Microsoft's domain).
I would like to know what changes do I need to make in the logic of the measures? How does the embedded report authenticates the user viewing that page? Can I still use USERPRINCIPALNAME() in the embedded report?
Solved! Go to Solution.
Hi @csette1329,
How do you plan on embedding the report?
RLS at the semantic model level like this only works with authenciated users.
If you embed “for your organization” (user-owns-data): viewers sign in with Microsoft Entra ID. USERPRINCIPALNAME() keeps working as-is because Power BI passes the signed-in user through. No DAX changes needed. See: Embed a report with RLS.
If you embed “for your customers” (app-owns-data): your app authenticates users, not Power BI. USERPRINCIPALNAME() won’t automatically be the website viewer; you must pass an effective identity (username/roles) when you call GenerateToken. In DAX you can still use USERPRINCIPALNAME() (it will return the username you supply), or use CUSTOMDATA() if you prefer passing an immutable user_id. Docs: Generate embed token, RLS with embedding, CUSTOMDATA(), USERPRINCIPALNAME().
If you're making a public web report, RLS will not function. See this post for more details: Solved: USERPRINCIPALNAME() in Public Web Reports - Microsoft Fabric Community
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, please mark this as the solution.
Hi @csette1329
When you embed a Power BI report that uses Row-Level Security (RLS) based on USERPRINCIPALNAME(), the behavior of that function depends entirely on the embedding method and authentication flow. In the Power BI Service, USERPRINCIPALNAME() automatically returns the signed-in user's email address (from Azure AD), which works perfectly for internal users within your organization. However, when the same report is embedded in an external website (outside Microsoft’s domain), there’s no direct sign-in context unless you explicitly pass one through your embedding setup.
If you are embedding the report using Power BI Embedded (service principal with embed tokens), USERPRINCIPALNAME() will not return the viewer’s identity; instead, it will reflect the identity under which the embed token was generated (usually a service principal or master account). To maintain RLS in such scenarios, you must implement “Effective User” or “Row-Level Security via Embed Tokens” — meaning your web application must authenticate the external user first (via your app’s own authentication system) and then generate a Power BI embed token with the user’s identity or role assigned. Power BI will enforce RLS based on that token rather than the logged-in Azure AD account.
In short, your DAX logic using USERPRINCIPALNAME() will continue to work if your embed implementation correctly passes the user identity through the embed token; otherwise, it will always show data for the token generator (not the viewer). So, you don’t need to change your DAX measures, but you do need to ensure your embedding solution supports per-user embedding with RLS-aware tokens — not generic app-level embedding — to preserve secure, user-specific filtering.
Hi @csette1329
When you embed a Power BI report that uses Row-Level Security (RLS) based on USERPRINCIPALNAME(), the behavior of that function depends entirely on the embedding method and authentication flow. In the Power BI Service, USERPRINCIPALNAME() automatically returns the signed-in user's email address (from Azure AD), which works perfectly for internal users within your organization. However, when the same report is embedded in an external website (outside Microsoft’s domain), there’s no direct sign-in context unless you explicitly pass one through your embedding setup.
If you are embedding the report using Power BI Embedded (service principal with embed tokens), USERPRINCIPALNAME() will not return the viewer’s identity; instead, it will reflect the identity under which the embed token was generated (usually a service principal or master account). To maintain RLS in such scenarios, you must implement “Effective User” or “Row-Level Security via Embed Tokens” — meaning your web application must authenticate the external user first (via your app’s own authentication system) and then generate a Power BI embed token with the user’s identity or role assigned. Power BI will enforce RLS based on that token rather than the logged-in Azure AD account.
In short, your DAX logic using USERPRINCIPALNAME() will continue to work if your embed implementation correctly passes the user identity through the embed token; otherwise, it will always show data for the token generator (not the viewer). So, you don’t need to change your DAX measures, but you do need to ensure your embedding solution supports per-user embedding with RLS-aware tokens — not generic app-level embedding — to preserve secure, user-specific filtering.
Hi @csette1329,
Thank you for posting your query in the Microsoft Fabric Community Forum, and thanks to @tayloramy for sharing valuable insights.
Could you please confirm if your query has been resolved by the provided solutions? This would be helpful for other members who may encounter similar issues.
Thank you for being part of the Microsoft Fabric Community.
Hi @csette1329,
How do you plan on embedding the report?
RLS at the semantic model level like this only works with authenciated users.
If you embed “for your organization” (user-owns-data): viewers sign in with Microsoft Entra ID. USERPRINCIPALNAME() keeps working as-is because Power BI passes the signed-in user through. No DAX changes needed. See: Embed a report with RLS.
If you embed “for your customers” (app-owns-data): your app authenticates users, not Power BI. USERPRINCIPALNAME() won’t automatically be the website viewer; you must pass an effective identity (username/roles) when you call GenerateToken. In DAX you can still use USERPRINCIPALNAME() (it will return the username you supply), or use CUSTOMDATA() if you prefer passing an immutable user_id. Docs: Generate embed token, RLS with embedding, CUSTOMDATA(), USERPRINCIPALNAME().
If you're making a public web report, RLS will not function. See this post for more details: Solved: USERPRINCIPALNAME() in Public Web Reports - Microsoft Fabric Community
If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, please mark this as the solution.
Hi @tayloramy
Thanks for your reply!
That was really helpful. I plan on embedding using the "for your customers" solution. I'll see if the embed token contains an useful user_id that I can use with CUSTOM DATA() function in DAX.
Advance your Data & AI career with 50 days of live learning, contests, hands-on challenges, study groups & certifications and more!
Check out the October 2025 Power BI update to learn about new features.
| User | Count |
|---|---|
| 52 | |
| 23 | |
| 12 | |
| 11 | |
| 11 |