POWER BI TIP
Customize data access with
Row Level Security (RLS)
Granular Hierarchical Security
control set up groups
Granular Data Access Control
Row Level Security (RLS) in Power BI enables precise
control over data access, allowing organizations to define
criteria for user access based on roles or departments.
This ensures users only view relevant data, enhancing
security and confidentiality.
If a person is supposed to see only USA sales, we can set up
the “USA” role, that will filter out only that specific data.
We can go even further and only show sales made by the
person accessing the report.
Global manager: sees all data USA manager: sees only local data
Hierarchical set up
When defining RLS, hierarchical data access structures can
be implemented using DAX calculations.
Those can be used to identify a user's manager and filter
data accordingly.
In a sales use case, this would enable managers to access
all sales records, while salespersons only see their own data.
Jonathan Doe will see the
Global manager: sales of his team
sees all data
Jenice Doe will only see
her sales
Leveraging existing security groups
Integration with Azure AD (recently renamed to Entra ID)
groups enhances RLS capabilities by leveraging existing
user management systems.
If you have a Role to see only data from a specific country,
and a security group containing all representatives for that
country, you can directly assign that group to that role,
instead of user-by-user assignment.
Instead of adding specific Add a group
persons to a role
How to?
STEP 1
Define roles in your dataset
(in Power BI Desktop or in Power BI service by editing the model*)
STEP 2
Within Power BI Service, add members to the previously defined
roles
* Editing models in the Power BI service is still in preview and needs custom set up
How to? STEP 1: Create role(s)
1. Within Power BI Desktop*, go to Modeling -> Manage
Roles
2. In the newly opened window, create a new role
In the newly opened window, create a new role
3. Give role 6. Set up the
a name condition. You can
combine multiple
expressions, as long
as it returns a
true/false value
4. Chose a table to
apply a filter on 5. Select a column to be
filtered or specify direct
DAX formula
* Or Power BI Service if edit of the model enabled
Bonus: There is a preview version of the RLS editor in Power
BI Desktop, allowing for a more intuitive UI
Instead of writing
DAX formulas, you
can use the UI to set
rules
You’ll still be able to
switch to the DAX
editor if needed
Considerations
The rules/conditions defined for roles can be
either Static, such as « Country = USA » or
dynamic, based on the connected user.
By using the « USERPRINCIPALNAME() » DAX
function, you can retrieve the email of the
connected user, and in this way, filter the data to
show only relevant one.
For example, show only the sales made by the
person accessing the report.
Testing the roles (Power BI Desktop)
Within Power BI Desktop, go to Modeling -> View as
Select the desired role to test
View a dynamic role, based on a
View a static role
specific user
How to? STEP 2: Add member(s) to role(s)
the dataset needs to be first published in Service
1. Identify the Dataset in a Workspace and go to « … »
-> Security
2. Select a role
3. Define members:
user or group
Testing the roles (Power BI Service)
You can test each role by going to « … » -> Test as role
View a static View a dynamic role,
role based on a selected user
When a person is
selected, you can see
some additional info
Warning
Users assigned to Admin, Member, or
Contributor Workspace access have edit
permission on the dataset; this means that the RLS
does not apply to them, and they will see the
entire data.
For example, if you distribute an App to users and
some of them have one of the specified roles in
the workspace where the app resides, the RLS will
not apply.
What about you?
Are you using the RLS in your
reports?
