Power BI RLS

[Shahami]

I’m running into an RLS behavior difference between Power BI Desktop and Power BI Service (Fabric) and would appreciate guidance on the recommended/long‑term approach.

Scenario

I have an RLS rule that needs to support:

• COINS users (tracked in a dim_system_user table via email/UPN)
• Non‑COINS users, where access is determined by a BUID embedded in the username (e.g. XYZ123 → BUID = 123), which is then mapped to companies via a BUID table
  In Power BI Desktop, USERNAME() returns values like:  EFS/XYZ123

• This allowed me to extract the BUID (123) and apply company‑level security successfully.

  However, in Power BI Service / Fabric, USERNAME() instead returns the UPN: 

  This causes the existing parsing logic to fail, even though the report works as expected in Desktop.

  My Quistions:- 

  • Is extracting identifiers (like BUID) from the UPN considered an acceptable pattern, or should this logic be moved entirely into a user‑to‑company mapping table?
  • Are there any recommended Microsoft patterns for supporting “non‑system users” in RLS when the only identifier comes from the username?
  • Is there any supported way to normalize Desktop and Service behavior, or should Desktop always be treated as a testing-only environment?

  Goal

  I want a Fabric‑safe, future‑proof RLS approach that:

  • Works consistently in Power BI Service
  • Supports both COINS and non‑COINS users
  • Avoids fragile username parsing if possible

  Appreciate any best‑practice guidance or design recommendations.

[Gabry · Accepted solution]

Hello,

To my knowledge, there is no way to get the "simple" username in the service; the USERNAME and USERPRINCIPALNAME functions return the same value. In my opinion, using an extraction rule isn't the best approach. You should instead build a mapping table (UPN - Company) and use it with RLS. You can still use your extraction rule to generate this table if no better source is available.

[v-moharafi-msft]

Hi @Shahami ,

Could you please confirm if the issue has been resolved? If not, feel free to reach out if you have any further questions.

Your update would be helpful for other members who may face a similar issue.

Best Regards,

Abdul Rafi

[v-moharafi-msft]

Hi @Shahami  ,

Thank you for reaching out to Microsoft Fabric Community and Thanks to @cengizhanarslan  , @Gabry  and @grazitti_sapna  for Sharing valuable insights.

Just wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions. 

 Best Regards,

Abdul Rafi.

[cengizhanarslan]

The RLS rule is straightforward since USERPRINCIPALNAME() returns the current user's UPN in Power BI Service and you match it directly against your mapping table:

RLS Filter =
USERPRINCIPALNAME() = UserCompanyMap[UPN]

Place this on the UserCompanyMap table in your role definition. For both COINS and non-COINS users, ensure their UPN exists in UserCompanyMap with the correct company mapping populated at the data layer during refresh.

[grazitti_sapna · Accepted solution]

Hi @Shahami,

Username() in desktop andUsername() in service have different outputs (DOMAIN\Alias and user@company.com respectively)

You can use userprinciplename() in Desktop as well to match the service output and then extract buid from it.

Better solution would be you create a separate master table with username, buid and cmpany like below

| UserKey (UPN)                                 | BUID | Company |
| --------------------------------------------- | ---- | ------- |
| [user1@company.com](mailto:user1@company.com) | 123  | A       |
| [user2@company.com](mailto:user2@company.com) | 456  | B       |
| [user3@company.com](mailto:user3@company.com) | NULL | C       |

Then you can use userprincipalname() in Desktop and then map and apply the RLS.

let me know if you have any further questions.

🌟 I hope this solution helps you unlock your Power BI potential! If you found it helpful, click 'Mark as Solution' to guide others toward the answers they need.
💡 Love the effort? Drop the kudos! Your appreciation fuels community spirit and innovation.
🎖 As a proud SuperUser and Microsoft Partner, we’re here to empower your data journey and the Power BI Community at large.
🔗 Curious to explore more? [Discover here].
Let’s keep building smarter solutions together!

[Shahami]

Thank you. My first thought was also to create a table with UPN, company, BUID etc. Thank you. 

[Gabry · Accepted solution]

Hello,

To my knowledge, there is no way to get the "simple" username in the service; the USERNAME and USERPRINCIPALNAME functions return the same value. In my opinion, using an extraction rule isn't the best approach. You should instead build a mapping table (UPN - Company) and use it with RLS. You can still use your extraction rule to generate this table if no better source is available.

[Shahami]

Thank you. I thought the same to create mapping table with UPN- Company.

[grazitti_sapna]

Hi @Shahami,

Kindly mark as solution it i was able to answer the query