Power BI Row-level Security with Dataverse

Power BI Row-Level Security (RLS) is a powerful feature that allows users to define security roles and rules to restrict access to specific data rows based on the user’s identity. When combined with Dataverse (the underlying data platform for Microsoft Dynamics 365 and Power Apps), RLS can help control which records are visible to different users within a Power BI report or dashboard, based on their security roles and responsibilities.

In this guide, we’ll explore how to implement and use Power BI Row-Level Security with Dataverse data, including step-by-step instructions, key concepts, and best practices.

What is Row-Level Security (RLS) in Power BI?

Row-Level Security (RLS) in Power BI is a feature that restricts access to certain rows of data based on the user’s identity. With RLS, you can create security roles and define DAX (Data Analysis Expressions) rules that determine what data a user can see. For example, a regional sales manager may only be able to see sales data for their specific region, while a company-wide executive might be able to view data for all regions.

How Does RLS Work with Power BI?

Security Roles: In Power BI, you can define roles that specify which data users assigned to the role can access. Each role contains DAX expressions that filter data at the row level.
User Identity: Power BI uses the user’s identity to apply the security filters. This is typically done using the UserPrincipalName (UPN), which is often tied to an email address, but other identifiers can be used as well.
Data Filtering: The DAX expressions within each role are applied to limit the rows visible to the user in the report or dashboard. When a user views the report, Power BI applies the filters to restrict access to the data that matches the role’s rules.

What is Dataverse?

Dataverse (formerly known as the Common Data Service) is a cloud-based data platform provided by Microsoft, used by applications such as Power Apps, Power Automate, and Dynamics 365. It allows businesses to securely store and manage data used by these apps. Dataverse enables data to be shared between apps and services, and it’s designed to work seamlessly with Power BI to enable rich analytics and reporting.

In the context of Power BI, Dataverse is used as a data source, and Row-Level Security can be applied to control access to different rows of Dataverse tables (formerly known as entities).

Implementing RLS with Power BI and Dataverse

Implementing Row-Level Security with Power BI and Dataverse involves several key steps:

Step 1: Set Up Dataverse Security

Before applying RLS in Power BI, it’s important to ensure that Dataverse security settings are configured properly. Dataverse uses security roles to manage access to different tables and records. These security roles can be mapped to users in the Power BI environment to control access.

Create Security Roles in Dataverse:
- In Dataverse, security roles define what data (tables, rows) a user can access. These roles should be set up to ensure that users can only access the data they are authorized to see based on their roles.
- Go to Power Platform Admin Center > Environments > Security > Security Roles, and create new roles or configure existing roles for your users.
- Set permissions for the tables that will be used in Power BI.
Field-Level Security (Optional):
- In addition to row-level security, you can implement Field-Level Security to control visibility of specific fields within the tables.
- This is particularly useful when users can access rows but should not be able to see all fields in those rows.

Step 2: Load Dataverse Data into Power BI

Connect Power BI to Dataverse:
- Open Power BI Desktop.
- From the Home tab, click on Get Data and select Dataverse.
- Sign in with your Microsoft account and select the Environment and Table from which you want to import data.
Import Tables into Power BI:
- Once connected to Dataverse, you can load tables (such as Sales, Contacts, or Accounts) that you want to analyze in Power BI. These tables will contain the data to which you’ll apply RLS.

Step 3: Implement Row-Level Security in Power BI

Define Security Roles in Power BI:
- In Power BI Desktop, go to the Modeling tab and click on Manage Roles.
- Define roles to control what data is visible for specific users.
- Use DAX expressions to create the filters for each role. For example: [Region] = USERPRINCIPALNAME() This DAX expression filters data based on the logged-in user’s email (or other identifier). You can tailor the expression to match your Dataverse data schema.
Apply Filters for Specific Tables:
- For each table you want to apply RLS to, specify the DAX filter that corresponds to the row-level security criteria.
- For example, if you have a Sales Territory field, you might filter data so that users can only see sales records from their designated region.
Test Roles:
- In Power BI Desktop, once roles are created, you can test the security configuration by clicking View as Role in the Modeling tab. This will simulate the view of a report as if you were assigned a specific security role.
- You can test multiple roles to verify that each user group sees the appropriate data.

Step 4: Publish the Report to Power BI Service

Publish to Power BI Service:
- After creating and testing the report with RLS in Power BI Desktop, publish the report to the Power BI Service.
- Ensure that you are connected to the correct Power BI workspace for the report.
Assign Roles in Power BI Service:
- Once the report is published to the Power BI Service, go to the dataset’s settings.
- Under the Security section, you can assign users or groups to specific roles that you defined in Power BI Desktop.
- You can assign Active Directory groups, individual users, or security groups to the roles created in Power BI.
Share the Report:
- After assigning roles, share the report with users, ensuring that they only see the data relevant to their security roles based on the RLS configuration.

Key Concepts in RLS with Dataverse

USERPRINCIPALNAME():
- This DAX function returns the user’s login name or email address (e.g., john.doe@example.com). This is often used in RLS filters to match the user to specific data rows.
- Example filter: [Email] = USERPRINCIPALNAME() This expression ensures that users only see data corresponding to their own email address in the Email field.
Multiple Roles:
- You can create multiple roles based on different access needs. For instance:
  - Sales Manager role: Can view data only for the sales regions they manage.
  - Regional Sales Rep role: Can see only data for their assigned region.
Role-Based Access:
- In Dataverse, roles such as Owner, Business Unit, and Organization can be leveraged alongside RLS to ensure that users access only the appropriate data.
- For example, you can set up roles in Power BI to filter by the Business Unit in Dataverse, ensuring that users only see records associated with their business unit.

Best Practices for Power BI RLS with Dataverse

Use Structured Security Roles in Dataverse:
- Ensure that security roles in Dataverse are properly structured and align with the roles you create in Power BI. This will help minimize errors and ensure consistency across platforms.
Keep RLS Filters Simple:
- When creating DAX expressions for RLS, keep them simple and efficient. Complex expressions can lead to performance issues when working with large datasets.
Test Security Thoroughly:
- Always test RLS thoroughly before publishing reports. Make sure that users can only access the data they are authorized to see. Power BI’s View as Role feature is critical for testing the implementation.
Use Azure Active Directory (AAD) Groups:
- When assigning roles in the Power BI Service, consider using Azure Active Directory groups to simplify the management of user access. This is particularly useful in large organizations.
Monitor and Audit Data Access:
- Monitor who accesses your Power BI reports and ensure compliance with your data governance and security policies. You can use tools like the Power BI Service Audit Logs to track user activity and data access patterns.