Power BI Row-Level Security

Row-Level Security (RLS) is a fine-grained access control mechanism that limits which rows a user can view, based on their group membership and other contextual attributes, ensuring each user sees only the data relevant to them.

Power BI is a business intelligence and analytics platform that models data into a semantic model (Dataset) and enables building reports and dashboards to monitor performance and support decision-making.

In Power BI, RLS is defined and enforced at the semantic model (Dataset) level using roles and DAX table filter expressions. Role membership is assigned in the Power BI Service to individual users or Microsoft Entra ID groups, and dynamic rules can reference the current viewer using DAX functions such as USERPRINCIPALNAME() or USERNAME(), which return the user’s UPN or email.

As a result, any report or dashboard connected to the Dataset automatically returns only the rows permitted for that user by the RLS rules.

Creating a Power BI Row Access Policy in PlainID

Important

Ensure that your Power BI application in the Orchestration Workspace is switched to Manage mode to start building your Row-Level Policy in the Policy catalog section. See Managing POPs for more information on how to change the Policy Orchestration Point (POP) Mode.

Row Access Policies in PlainID can be created using the following methods:

Wizard
Code
Native

For more information, refer to Creating Policies.

To create a Row Access Policy with the Policy Wizard:

Input the Policy Details. For more information, refer to the Creating Policies article
Select Use Policy For SaaS Applications and select the relevant Power BI application.
Input the Power BI POP Details specific to the vendor policy:
- Under the Vendor Policy Kind dropdown, select Row-Level Security. (Required)
- Enter a Vendor Policy Name, a unique name for the Policy that appears in the Power BI vendor. (Required)
- Under the Vendor Policy ID, the ID is automatically generated. It is the ID used in Policy management operations like deploy, update, and override.
- Under Workspace, select the Power BI Workspace where the Policy will be deployed.
- Under Dataset, select the Dataset within the Workspace where the Policy resides.
Click Continue.

Who Section

In the Who section, specify which users should receive Row-Level access by assigning access to a new Dynamic Group or select an existing one.
A single Policy can evaluate multiple Dynamic Groups (OR relationships between them), giving you flexibility in defining access control logic.

Dynamic Groups are defined based on the users and groups that exist in the IDP configuration using Power BI identity functions.
In PlainID, Dynamic Groups that rely on USERPRINCIPALNAME() are represented through the Groups Identity Attribute, and USERNAME () is represented as USERID.
Dynamic Groups can only contain one rule using the equals operator.

For information on how to create a Dynamic Group, see Managing Dynamic Groups.

What Section

In the What section, you can define Row-Level access and limit data access from your protected table through your Asset Types.
Each Asset Type represents a table from your Power BI Dataset, as defined by your POP configuration and permissions.

For more details on Asset Types, refer to Managing Asset Types.

To define access:

Click Add Asset Type.
From the dropdown, select the Asset Types that are included in your Row-Level access logic rules.
Asset Types that are not selected automatically receive FALSE access, maintaining consistency with PlainID's zero-trust default behavior.
Select existing Rulesets for your Policy logic or create a new one. A Policy can include multiple Rulesets (OR relationship between them).

See Defining a Ruleset for Row-Level Filtering for more information.

Click Save.

Defining a Ruleset for Row-Level Filtering

To define a Ruleset:

In the Asset Type within the Ruleset tab, define the Row-Level filtering logic using the available Asset Attributes (for example, Status = 'Active'). Each Asset Attribute corresponds to a column in the table.
You can use Power BI tables as an external Identity Source for contextual or dynamic rules (for example, Account_ID = User.Assigned_Account). See our documentation on Managing Identity Source tables for more information.
Use PlainID's flexible logic to combine multiple rules with complex AND/OR relationships, while using the equals operator.

When Section

In the When section, you define the Conditions that provide contextual identity data and enrich identity information for your Policy.

To define a Condition:

Select an existing Condition or create a new one. A Policy can include multiple Conditions (an AND relationship between them, meaning all Conditions must be met for the Policy to grant access). Ensure that you select Conditions from Identity Attributes linked to the POP’s Identity Source.
- See Managing Conditions to learn how to create a new Identity Attribute Condition.
- Ensure that the Condition meets the Conditions for Row-Level Requirements.
- Once Conditions are applied to a Policy, they are automatically enforced across all tables included in that Policy. Tables not selected in the Policy will continue to receive FALSE access.
Click Save.

Conditions Guidelines

Ensure that an Identity Source table is defined within your Policy Orchestration Point (POP). For more details, refer to our documentation on Managing Identity Source Tables article.
Only Identity Attribute Conditions are supported.
A Condition can include only one rule using the equals operator. Other operators and logical relationships, like AND or OR within a single Condition, are not supported.

Deploying the Policy

Once complete, navigate to the Orchestration Workspace and deploy the Policy to Power BI.
Power BI enforces the access decision based on the Row-Level filtering you've defined in the PlainID platform.

Power BI Row Access Policy SQL Structure

This table describes the Power BI Row Access Policy (Roles) components in DAX and compares them to their equivalents in PlainID to help you translate and build your policies easily within the PlainID Platform.

Policy Syntax Table

Power BI terminology	Power BI Syntax	Description	PlainID terminology
Security Roles	Security Roles enforce Row-Level Security applied to specific tables in a Dataset.	Define and manage the Role Name as part of the RLS metadata configuration	Vendor Policy Name
Role Assignment	Process of assigning users or Entra ID groups to a security role	Determines who the RLS rules apply to. Incorporates Power BI identity functions: `USERPRINCIPALNAME()` and `USERNAME()`	Dynamic Groups using identity attributes of Groups and User ID.
Security Roles Rules	DAX filter expressions defined inside a security role. Example: `LOOKUPVALUE( Table[ReturnColumn], Table[MatchColumn],USERPRINCIPALNAME() )` Or `[Entity ID] = "Value"`	rules are applied at the table level and hold the Row-Level filtering logic.	Policy Rulesets
	`CONTAINS(TableName, TableName[UserIdentifierColumn], USERPRINCIPALNAME(), TableName[AttributeColumn], "ValueToMatch")`	Use Power BI functions for dynamic, context-based filtering.	Policy logic uses an external table mapped into conditions, where expressions typically compare attributes to static values. Note that a correlation must be defined using one of the Power BI identity functions `USERPRINCIPALNAME()` and `USERNAME()`.

Row Access Policy Example

This example grants Tax_Advisor_Group access:

Only to rows where the account is assigned to them in the HR table and only if they belong to the US region in the Accounts table.
Only to rows marked Active and only users from the UK region in the tax_entities table.

The Tax_Advisor_Group cannot see any rows from the Clients table.