Skip to main content
Showing results for 
Search instead for 
Did you mean: 

Find everything you need to get certified on Fabric—skills challenges, live sessions, exam prep, role guidance, and more. Get started

Helper II
Helper II

Dynamic Data Masking


I work in an organisation with a large number of retail outlets. We have sales data from these outlets including the name of the salesperson who made the sale. The sales data table has an employee id in it, which then joins to a employee table where dynamic data masking has been applied at source (Fabric Lakehouse). 


Is it possible to set up some dynamic rules in Power BI that will allow all users who work in Location A to see the unmasked data for them and their colleagues in the same location, but only to see masked data outside of their own location? We have the added complication that each shop would report into an Area Manager, and we would need the Area Manager to see all of the unmasked data for the all the Locations for which they were responsible, but only masked data for everyone else. 


Am I expecting to be able to do too much with this, without having to create loads of roles/groups?

Solution Supplier
Solution Supplier

Applying dynamic data masking directly within Power BI, similar to what you've described, requires a strategic approach, especially considering the complexity of different visibility levels for different users.

Here’s a simplified strategy on how you can achieve this:


Step 1: Set Up Your Data Model

Ensure your data model has a table that maps employees to their locations and a separate mapping for area managers to their locations. This setup will be crucial for defining security roles.


Step 2: Implement Row-Level Security (RLS)

You can use RLS to dynamically filter data based on the user’s login. Although RLS traditionally controls access to rows of data, you can creatively use it alongside calculated columns or measures to mask or unmask data.


Basic Steps in Power BI Desktop:

1. **Create Roles**: Go to the Modeling tab and click on "Manage Roles". For each location and for area managers, you’ll create a specific role. For example, “Location_A_Staff”, “Area_Manager_X”, etc.

2. **Define Filters**: For each role, you define DAX filters on your tables that determine what data the role can see. For staff at Location A, the filter would ensure they only see unmasked data for Location A. For an Area Manager responsible for Locations A, B, and C, the filter would allow them to see unmasked data for these locations.


Example DAX Filter for a Staff Role at Location A:
[Location] = "Location A"
USERPRINCIPALNAME() = [Employee Email] -- Assuming email can be used to identify users uniquely


Example DAX Filter for an Area Manager Role:
[Area Manager ID] = LOOKUPVALUE([Manager ID], [User Table], USERPRINCIPALNAME(), [Employee Email])
[Location] IN { "Location A", "Location B", "Location C" }


Step 3: Dynamic Masking Logic

Since RLS filters rows and not individual column values, to achieve dynamic masking, you’ll need to use calculated columns or measures that display different values based on the user’s role.

- **Calculated Column for Salesperson Name**: Create a calculated column that checks if the current user should see the unmasked name based on their location or role. If not, show a masked value.

Salesperson Name Visible =
[Location] = USERLOCATION() -- Assume a function or logic to determine the user's location,
[Salesperson Name], -- Unmasked
"Masked" -- Masked


Step 4: Deploy and Test

After setting up RLS and your dynamic masking logic, publish the report to Power BI Service. Then, configure the roles for each user or group of users through the service. Test thoroughly to ensure that each user sees exactly what they’re supposed to see.



- This approach requires careful setup and maintenance, especially as new locations or roles are added.
- Power BI does not directly support column-level security or dynamic masking out-of-the-box. The described method is a workaround and might need adjustments based on your specific data structure and security requirements.
- For complex scenarios, consider maintaining a separate table with masked and unmasked values, controlled by RLS, to simplify the DAX expressions.

Helper II
Helper II

Thanks @Ritaf1983 , I had come across this post before when researching the issue, but it doesnt't quite address the issue. Was hoping someone else had a closer example to what I was after.

Super User
Super User

Hi @TheCreepster1 
It seems that there is no other way to reach your goals, only with dynamic row-level security with hierarchies and groups.

For more information please refer :

If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly

Helpful resources

July 2024 Power BI Update

Power BI Monthly Update - July 2024

Check out the July 2024 Power BI update to learn about new features.


Fabric Community Update - June 2024

Get the latest Fabric updates from Build 2024, key Skills Challenge voucher deadlines, top blogs, forum posts, and product ideas.

Top Solution Authors