How to Use UserPrincipalName in Power BI

You've just put the finishing touches on a comprehensive sales dashboard in Power BI. The visuals are clean, and the metrics are insightful - it's a masterpiece. There's just one problem: it shows everything to everyone. How do you make sure your sales reps only see their own deals, your regional managers only see their regions, and you still get the full picture?

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

The answer lies in a powerful little DAX function called USERPRINCIPALNAME(). This article will show you exactly how to use this function to implement Row-Level Security (RLS), turning one generic dashboard into a personalized, secure report for everyone on your team.

What Exactly is USERPRINCIPALNAME()?

In simple terms, USERPRINCIPALNAME() is a DAX function that returns the User Principal Name (UPN) of the person currently logged in and viewing your report. In most business setups using Microsoft 365, the UPN is simply the user's email address they use to log into Power BI - for example, jane.doe@yourcompany.com.

Think of it as a dynamic stamp that tells Power BI, "Hey, this is who is looking right now."

There's one important catch: this function only works its magic in the Power BI Service (the online version where you share reports). When you are building in Power BI Desktop, it will typically return your computer's user or system name, not your Power BI email address. That’s why you have to use a special testing feature in Power BI Desktop to see how it will behave once published, which we'll cover in a bit.

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

The Real Goal: Row-Level Security (RLS)

The primary use for USERPRINCIPALNAME() is to implement Row-Level Security, or RLS. RLS is a technique that restricts data access at the row level based on the user's identity. Instead of building ten different reports for ten different people, you build one report and apply rules that automatically filter the data for each person who views it.

Here are a few relatable examples where RLS is a lifesaver:

• Sales Dashboard: Each salesperson sees only their own sales figures, leads, and customer interactions. The sales manager, however, can see the data for their entire team.
• Regional Performance Report: A country manager for France sees only data related to France, while the manager for Germany sees only German data. The CEO sees everything combined.
• Store Profitability Dashboard: The manager of Store A sees financial data for Store A but not for Store B, C, or D.

Implementing RLS with USERPRINCIPALNAME() makes your reports smarter, more secure, and infinitely more relevant to your audience. You maintain a single source of truth while giving everyone a view tailored specifically for them.

Step-by-Step Guide: Setting Up RLS with USERPRINCIPALNAME()

Let's walk through a common scenario: creating a secure sales dashboard where reps can only see their own sales data. For this to work, you need one crucial piece of information in your data: an email address associated with each sale.

Let's assume you have a Sales table with sales data and an Employees table with information about your sales staff, including their email address. These two tables should be related in your data model.

Step 1: Get Your Data Model Ready

Your data model needs a way to link a row of data to a person. In our case, the Sales table has a salesperson’s ID, which links to the Employees table. The Employees table has an EmailAdresse column that contains the work email of each sales rep. This email is what we will match against the viewer's login credentials.

Bottom line: make sure you have a column in your tables that contains the email addresses (UPNs) of the people you want to filter for.

Step 2: Create a New Role

A "role" in Power BI is just a container for one or more RLS rules. You'll create a role that defines the filtering logic.

1. In Power BI Desktop, go to the Modeling tab in the ribbon.
2. Click on Manage roles.
3. In the "Manage roles" window, click Create. Name your new role something descriptive, like "Sales Rep View".

You’ve now created a security group but haven't told it how to filter anything yet.

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

Step 3: Write the DAX Filter Expression

This is where USERPRINCIPALNAME() enters the picture. You'll apply a DAX filter to the employee table to restrict its rows.

1. In the "Manage roles" window, with your "Sales Rep View" role selected, find the Employees table from the list.
2. Click the ellipsis (...) next to the table name and select Add filter, then choose the column containing the email addresses (e.g., [EmailAdresse]).
3. Power BI gives you a space to write your DAX expression. Enter the following:

[EmailAdresse] = USERPRINCIPALNAME()

That’s it! This simple line of code tells Power BI: "For the 'Employees' table, only show rows where the value in the 'EmailAdresse' column is exactly the same as the email of the person currently looking at the report." Because your tables are related, filtering the Employees table will automatically filter the Sales table, showing only sales made by that employee.

Click Save to close the window.

Step 4: Test Your Role in Power BI Desktop

Before publishing, you need to make sure your rule works as intended. Power BI has a built-in tool for this.

1. On the Modeling tab, click on View as.
2. In the "View as roles" window, check the box for your newly created role, "Sales Rep View".
3. Also, check the box for Other user and enter the email address of one of your sales reps - for example, tom.jones@yourcompany.com.
4. Click OK.

Your report canvas will now reload, showing you exactly what Tom Jones would see. All the charts, tables, and slicers will be filtered down to only his data. You'll see a yellow banner at the top of your report confirming that you are viewing as "Sales Rep View" and a specific user. To stop testing, just click "Stop viewing" on that banner.

Step 5: Publish Your Report

Once you’ve confirmed the RLS is working, it’s time to publish your report to the Power BI Service. Go to the Home tab and click Publish. Choose the workspace where you want your report to live.

Step 6: Assign Users to Roles in Power BI Service

Just creating the role isn't enough. You have to tell Power BI which people belong to that role. This final step is done online.

1. Go to your workspace in the Power BI Service (app.powerbi.com).
2. Find your new dataset (not the report). Click the ellipsis (...) next to it and select Security.
3. You'll see your "Sales Reps View" role. Select it.
4. In the box on the right, start typing the email addresses of all the users who should be part of this role (your sales team). You can add individual users or entire Microsoft 365 security groups.
5. Click Add, and then Save.

Now, when Tom Jones logs into Power BI and opens this report, he will automatically and seamlessly only see his own performance data. He won’t even know he’s being filtered, it will just look like the report was built just for him.

Good Habits and Common Problems

While the process is straightforward, a few details can trip you up. Keep these tips in mind for a smooth experience.

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

Tip 1: Handle Case Sensitivity

Email addresses in your data source might be Tom.Jones@yourcompany.com while the Power BI login is tom.jones@yourcompany.com. DAX can be case-sensitive. To avoid issues, it’s a best practice to force both values to be the same case, like lowercase.

Modify your DAX rule like this:

LOWER([EmailAdresse]) = LOWER(USERPRINCIPALNAME())

Tip 2: Mismatched UPNs vs. Standard Emails

In some rare corporate environments, the UPN used to log into Active Directory/Microsoft 365 might be different from a user's primary email address (e.g., UPN is tjo123@yourcompany.com but the email is tom.jones@yourcompany.com). Make sure the email addresses in your data column match what USERPRINCIPALNAME() actually returns. If unsure, ask your IT department.

Tip 3: Don't Forget to Assign Users

A common mistake is perfectly setting up the roles in Power BI Desktop but forgetting the final step of assigning actual users to that role in the Power BI Service. If you don't assign anyone, the rule does nothing.

Final Thoughts

Learning to use USERPRINCIPALNAME() is a huge step in moving from a casual Power BI user to someone who can build sophisticated, secure, and user-friendly reports. By implementing Row-Level Security, you can serve a wide audience with a single report, ensuring everyone gets the data they need and nothing more.

While mastering tools like Power BI to set up data models, write DAX, and manage user roles is a powerful skill, it can definitely feel like a lot of steps. For our own marketing and sales reporting, we wanted a way to get answers without the manual setup. That's why we created Graphed. It's our AI data analyst that connects your marketing and sales sources in seconds, letting you build dashboards and get insights simply by asking questions in plain English, putting hours of reporting work behind you.