How to Fetch Logged In User Name in Power BI

Showing viewers data meant specifically for them is one of the most powerful features in Power BI. Creating a personalized report that filters information based on who is logged in not only improves the user experience but also allows you to implement critical security rules. This article will show you exactly how to fetch the logged-in user's name and use it to build dynamic, secure, and user-specific dashboards.

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

Why You Need the Logged-In User's Name

Before jumping into the technical steps, it's helpful to understand the main reasons you'd want to identify the current user in a Power BI report. It generally comes down to two key goals: personalization and security.

• Row-Level Security (RLS): This is the most common reason. RLS restricts data access at the row level. For example, you can ensure that sales representatives only see data related to their own accounts and pipelines. To do this, Power BI needs to know who is looking at the report so it can apply the correct filters.
• Report Personalization: You can make your reports more engaging by personalizing them for the viewer. This can be as simple as a welcome message like, "Welcome, Sarah!" or dynamically changing report titles to something like "John's Monthly Sales Performance." This small touch makes users feel like the dashboard was built just for them.
• Auditing and Logging: In some cases, you might want to log who is accessing a report and when, although more advanced auditing is typically handled in the Power BI admin portal.

In all these scenarios, the starting point is getting a unique identifier for the current user. Let's look at the DAX functions that make this possible.

Key DAX Functions for User Identification

Data Analysis Expressions (DAX) is the formula language used in Power BI. It includes a handful of functions that return information about the user and their environment. When it comes to user identification, two functions are essential: USERNAME() and USERPRINCIPALNAME().

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

USERNAME() vs. USERPRINCIPALNAME()

While they sound similar, these two functions return different information and are used in different contexts. Understanding the difference is important for getting your report to work correctly when published to the Power BI Service.

1. USERNAME()

The USERNAME() function returns the user's logon credential in the format of DOMAIN\UserName. For example, if you are logged into a corporate network, it might return something like CORPNET\jane.doe.

This function is primarily useful for on-premises deployments using Windows Authentication. In the Power BI Service (the cloud version), it behaves the same as USERPRINCIPALNAME(). Because most Power BI development is for the cloud, USERNAME() is used less frequently today, but it's good to know it exists.

2. USERPRINCIPALNAME()

The USERPRINCIPALNAME() function returns the User Principal Name (UPN) of the logged-in user. In almost all cases, particularly within a Microsoft 365 or Azure Active Directory environment, the UPN is the user's email address. For example, it will return jane.doe@yourcompany.com.

For reports published to the Power BI Service, this is the function you will almost always use for row-level security and personalization. The user's email is a reliable, unique identifier that you can use to filter tables and look up user information.

Quick Comparison: When to Use Which

• Use USERPRINCIPALNAME() for any report you plan to publish to the Power BI Service. It returns the user's email, which is the standard identifier in cloud environments.
• Use USERNAME() if you are working with an on-premises Analysis Services Tabular model that uses Windows Authentication.

A Step-by-Step Guide to Implementing Row-Level Security

Now that you know the functions, let's walk through the most common use case: setting up Row-Level Security (RLS) so that a sales manager can only see a report for the region she manages.

Imagine you have a Sales table with sales data and a Regions table with managers assigned to each region. The Regions table has columns like [Region], [ManagerName], and [ManagerEmail].

Step 1: Create a Role in Power BI Desktop

The first step is to define a security role that contains your filtering logic.

1. On the Modeling tab in the Power BI Desktop ribbon, select Manage Roles.
2. In the Manage Roles window, click Create. Name your new role. For this example, let's call it "Regional Manager".
3. Now you need to apply the filter. Select the Regions table from the list.
4. In the Table filter DAX expression box, enter the following formula:

[ManagerEmail] = USERPRINCIPALNAME()

That's it! This simple DAX filter tells Power BI: "For the Regions table, only show rows where the value in the ManagerEmail column is equal to the email address of the person currently viewing the report." Since your Regions table is related to your Sales table, this filter will automatically propagate and show only the sales data for that manager's region.

Click Save to confirm the role.

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 2: Test the Role in Power BI Desktop

Before publishing, you should always test your RLS roles to make sure they work as expected.

1. On the Modeling tab, select View as.
2. In the View as roles window, check the box for the role you just created ("Regional Manager").
3. Below that, check the Other user box and enter the email address of a manager from your Regions table (e.g., sara.johnson@yourcompany.com).
4. Click OK.

Your report will now refresh and display as if you were Sara Johnson. You should see only the data for the region she manages. This confirms your DAX filter is working correctly. To stop viewing as that role, just click "Stop viewing" on the yellow banner that appears at the top of your report.

Step 3: Publish the Report and Assign Users in Power BI Service

Testing locally is great, but RLS only becomes active for users once you configure it in the Power BI Service.

1. Publish your report to the Power BI Service from Power BI Desktop.
2. Navigate to the workspace where you published it. Find the dataset (not the report) associated with your .pbix file.
3. Click the three dots next to the dataset and select Security.
4. You will see the "Regional Manager" role you created. Select it.
5. A pane will appear where you can add members. Start typing the names or email addresses of the managers you want to assign to this role. Add the relevant people and click Save.

Now, when one of those assigned managers opens the report, the USERPRINCIPALNAME() function will return their email, the RLS filter will be applied, and they will only see the data for their specific region.

Advanced Tip: Getting the User's Full Name for Personalization

Row-level security relies on the user's email, but for personalization, you probably want to display their actual name, not their email. For example, a "Welcome, sara.johnson@yourcompany.com" message isn't very friendly.

To get a user's full name, you need a table in your data model that maps their email address (UPN) to their full name. Let's call this the Employees table. It might have columns like [EmployeeID], [FullName], and [Email]. Here’s how you can use it.

Create a Measure to Fetch the Full Name

Create a new DAX measure that looks up the current user's full name from the Employees table.

Current User Full Name = LOOKUPVALUE(Employees[FullName], Employees[Email], USERPRINCIPALNAME())

Let's break down this formula:

• LOOKUPVALUE(...): This is a DAX function that returns a value from a table where a row meets a certain criteria.
• Employees[FullName]: This is the value we want to return (the person's name).
• Employees[Email]: This is the column we are searching in.
• USERPRINCIPALNAME(): This is the value we are searching for (the logged-in user's email).

Now, you can use this [Current User Full Name] measure in any visual. For example, you can drop it into a Card visual to create a "Welcome, Sara Johnson!" card or create another measure to dynamically change a report's title:

Dynamic Title = "Performance Dashboard for " & [Current User Full Name]

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

Handling Users Not in the Table

What happens if a user who logs in isn't in your Employees table? The LOOKUPVALUE function will return a blank. To avoid this, you can provide an alternate result in the formula.

Current User Full Name =
VAR LoggedInEmail = USERPRINCIPALNAME()
VAR LookedUpName = LOOKUPVALUE(
    Employees[FullName],
    Employees[Email],
    LoggedInEmail
)
RETURN
    IF(ISBLANK(LookedUpName), "Guest User", LookedUpName)

This improved version first checks if the lookup returned a valid name. If it's blank, it returns "Guest User" instead. This makes your report more robust.

Final Thoughts

Ultimately, fetching the logged-in user's name with DAX functions like USERPRINCIPALNAME() is a foundational skill for any serious Power BI developer. It opens the door to creating powerful, secure, and highly personalized reports that deliver the right data to the right people, every time. By pairing it with a user or employee dimension table, you can build dashboards that feel custom-made for each member of your team.

While mastering DAX and RLS inside Power BI is incredibly valuable, it often comes with a steep learning curve and hours of manual report configuration. For teams that need answers now, there's an easier way. With Graphed, we automate the tiresome parts of reporting. You can simply connect your data sources and tell our AI data analyst what you want to see in plain English. We turn hours of clicking, dragging, and formula-writing into simple conversations, so your team can spend less time building reports and more time acting on the insights within them.