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

Enhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.

Reply
ribisht
Helper I
Helper I

Column Level Security with Power BI

Question by Yaswanth ,I started learning and working in Power BI. I watched a video about column level security in Power BI. After going through that, I have got one doubt regarding measures. The below example will explain in detail.
 
Example:
 

I have a fact table and a user table where column-level security has been applied to specific fields, such as Category, Sub-category, and Sales Pareto amount. The data in the user table is correctly mapped to the respective columns for each user. For example, when column-level security is implemented, User A will not have access to the Sales Pareto column, which works as intended.

However, I have also created a measure based on the Sales Pareto amount. My concern is whether this measure will remain restricted for User A when they view the report. My assumption is that it won't be restricted at the measure level, and User A will still be able to see the Sales Pareto amount due to the measure being created.

If that is the case, how can we ensure that such users are also restricted from accessing measures based on fields they are not permitted to view?



Another Use Case
 
I need assistance with one of the use cases. I have a tabular visual comprising 30 columns sourced from three different tables: a, b, and c. I created a role for a user who does not have access to table b. However, when this user views the report, the entire visual fails and displays an error message stating that they do not have access to the columns in table b. How can this issue be resolved?

Solution required: When the user views the report, he should see the visual, but the columns from the B table should show null or blank values in the visual using Power BI. 
 
 
1 ACCEPTED SOLUTION
FarhanJeelani
Super User
Super User

Hi @ribisht ,

Great questions! Let’s break down your concerns step by step.

1. Column-Level Security and Measures:
In Power BI, Row-Level Security (RLS) is applied to rows in a table based on user roles. Column-Level Security (CLS) isn’t directly supported as a built-in feature in Power BI; however, you can achieve column-level security by controlling access to columns using DAX expressions. This method applies to measures as well, but the important thing to note is:

When you create a measure using a restricted column, the measure will still follow the column security if you ensure the DAX expression considers the role-based access.

To ensure the measure respects column-level security, you need to apply the same security logic to the measure. Here’s an example of how you could apply this:

DAX

Sales Pareto Measure =
IF(
USERNAME() = "UserA",
BLANK(),
SUM(FactTable[SalesParetoAmount])
)

In the above DAX code:

The IF condition checks if the logged-in user is "UserA." If true, the measure returns BLANK(), effectively restricting UserA from viewing the Sales Pareto amount.

For other users, it will return the correct value.

This ensures that when User A tries to view the report, the measure based on Sales Pareto won’t display any data.

 

2. Columns from Tables Without Access:
For your second use case, where a user doesn't have access to a specific table (e.g., Table B), the behavior you’re encountering is because Power BI applies security at the data model level. If a user doesn't have access to a table or column, they cannot see it in any visual, including measures derived from those columns, which results in an error message.

To resolve the issue where the visual fails but you want the columns to show NULL or BLANK, you can do the following:

Use DAX measures to check the user's access to the table and return a blank or null if they don't have access.

You can create a "safe" measure that returns a blank for restricted users, as shown below:

DAX

SalesAmountWithAccess =
IF(
ISINSCOPE(TableB[Column]),
SUM(TableB[SalesAmount]),
BLANK()
)

In this case:

The ISINSCOPE function checks if the column from Table B is in the current context. If the user does not have access to Table B, the measure will return BLANK().

This ensures that for users without access to Table B, the columns from that table will be displayed as NULL or BLANK, while still allowing other columns and measures to work normally.

 


Measure Level Security: Ensure you add logic to your DAX measures that takes the user’s role or access rights into account, and returns BLANK() or a restricted value if necessary.

Column Access and Visibility: When users don't have access to specific tables, you can use DAX expressions to control the visibility of columns and prevent errors by showing BLANK() for restricted data.

 

By implementing these solutions, you can ensure that the visuals behave as intended and that users see only the data they are allowed to access.

 

Please mark this post as solution if it helps you. Appreciate Kudos.

View solution in original post

6 REPLIES 6
v-pnaroju-msft
Community Support
Community Support

Hi ribisht,

We are following up to see if your query has been resolved. Should you have identified a solution, we kindly request you to share it with the community to assist others facing similar issues.

If our response was helpful, please mark it as the accepted solution and provide kudos, as this helps the broader community.

Thank you.

v-pnaroju-msft
Community Support
Community Support

Hi ribisht,

We wanted to check in regarding your query, as we have not heard back from you. If you have resolved the issue, sharing the solution with the community would be greatly appreciated and could help others encountering similar challenges.

If you found our response useful, kindly mark it as the accepted solution and provide kudos to guide other members.

Thank you.

v-pnaroju-msft
Community Support
Community Support

Thank you, @FarhanJeelani ,for your response.

 

Hi @ribisht,

 

We would like to check if the solution provided by @FarhanJeelani has resolved your issue. If you have found an alternative approach, we encourage you to share it with the community to assist others facing similar challenges.

If you found the response helpful, please mark it as the accepted solution and add kudos. This recognition benefits other members seeking solutions to similar queries.

 

Thank you.

I initially thought it would work and accepted it, but unfortunately, it didn’t. While I can see the blanks, it fails to refresh, making it not very useful. @v-pnaroju-msft  thanks a lot  @FarhanJeelani  but the second one did not work for me

 

I have opened a new case

https://community.fabric.microsoft.com/t5/Service/Table-Level-Security/m-p/4667282#M273893

FarhanJeelani
Super User
Super User

Hi @ribisht ,

Great questions! Let’s break down your concerns step by step.

1. Column-Level Security and Measures:
In Power BI, Row-Level Security (RLS) is applied to rows in a table based on user roles. Column-Level Security (CLS) isn’t directly supported as a built-in feature in Power BI; however, you can achieve column-level security by controlling access to columns using DAX expressions. This method applies to measures as well, but the important thing to note is:

When you create a measure using a restricted column, the measure will still follow the column security if you ensure the DAX expression considers the role-based access.

To ensure the measure respects column-level security, you need to apply the same security logic to the measure. Here’s an example of how you could apply this:

DAX

Sales Pareto Measure =
IF(
USERNAME() = "UserA",
BLANK(),
SUM(FactTable[SalesParetoAmount])
)

In the above DAX code:

The IF condition checks if the logged-in user is "UserA." If true, the measure returns BLANK(), effectively restricting UserA from viewing the Sales Pareto amount.

For other users, it will return the correct value.

This ensures that when User A tries to view the report, the measure based on Sales Pareto won’t display any data.

 

2. Columns from Tables Without Access:
For your second use case, where a user doesn't have access to a specific table (e.g., Table B), the behavior you’re encountering is because Power BI applies security at the data model level. If a user doesn't have access to a table or column, they cannot see it in any visual, including measures derived from those columns, which results in an error message.

To resolve the issue where the visual fails but you want the columns to show NULL or BLANK, you can do the following:

Use DAX measures to check the user's access to the table and return a blank or null if they don't have access.

You can create a "safe" measure that returns a blank for restricted users, as shown below:

DAX

SalesAmountWithAccess =
IF(
ISINSCOPE(TableB[Column]),
SUM(TableB[SalesAmount]),
BLANK()
)

In this case:

The ISINSCOPE function checks if the column from Table B is in the current context. If the user does not have access to Table B, the measure will return BLANK().

This ensures that for users without access to Table B, the columns from that table will be displayed as NULL or BLANK, while still allowing other columns and measures to work normally.

 


Measure Level Security: Ensure you add logic to your DAX measures that takes the user’s role or access rights into account, and returns BLANK() or a restricted value if necessary.

Column Access and Visibility: When users don't have access to specific tables, you can use DAX expressions to control the visibility of columns and prevent errors by showing BLANK() for restricted data.

 

By implementing these solutions, you can ensure that the visuals behave as intended and that users see only the data they are allowed to access.

 

Please mark this post as solution if it helps you. Appreciate Kudos.

I am not sure if it can check the access to a particular column where there is no access to the table itself

Helpful resources

Announcements
August Power BI Update Carousel

Power BI Monthly Update - August 2025

Check out the August 2025 Power BI update to learn about new features.

August 2025 community update carousel

Fabric Community Update - August 2025

Find out what's new and trending in the Fabric community.

Top Solution Authors