---
title: "Power BI Row-Level Security"
slug: "power-bi-row-level-security"
updated: 2026-03-24T13:07:23Z
published: 2026-03-24T13:07:23Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plainid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# 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.

PlainID aligns with Power BI native RLS behavior. Tables that are **not explicitly connected** to a Row Access Policy are translated to a **Blank DAX** expression in Power BI, ensuring full alignment with Power BI’s default “allow all” behavior. See [Blank DAX behavior for Asset Types and Rulesets](/v1/docs/power-bi-row-level-security#behavior-for-asset-types-and-rulesets) for more information.

#### 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](/v1/docs/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](/v1/docs/creating-policies).

---

**To create a Row Access Policy with the Policy Wizard**:

1. Input the **Policy Details**. For more information, refer to the [Creating Policies](/v1/docs/creating-policies) article
2. Select **Use Policy For SaaS Applications** and select the relevant Power BI application.
3. 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.
  - The Platform also supports the **Dataflow** Dataset.

1. 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.**

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(361).png)

For information on how to create a Dynamic Group, see [Managing Dynamic Groups](/v1/docs/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](/v1/docs/managing-asset-types).

**To define access**:

1. Click **Add Asset Type**.
2. From the dropdown, select the **Asset Types** that are included in your Row-Level access logic rules.

> Asset Types that **are not explicitly connected** to a Row Access Policy are translated to a **Blank DAX expression in Power BI**, ensuring full alignment with Power BI’s default “allow all” behavior, which means that the table allows access to all rows by default.

1. Select existing **Rulesets** for your Policy logic or create a new one. A Policy can include **multiple Rulesets**, where each Ruleset may contain complex logic, but the relationship between the Rulesets themselves is OR.

> You can also use the **"All Assets"** Ruleset to translate tables to `TRUE()` access. To explicitly **block** access to a Table, ensure that you set the Native Ruleset to `FALSE()`.

1. Click **Save**.

#### Behavior for Asset Types and Rulesets

Below is a table that describes how Asset Types and Rulesets are translated into DAX expression:

| PlainID Policy | DAX Translation |
| --- | --- |
| Defining a custom Ruleset with Policy Logic | DAX Expression |
| Defining an **All Assets** Ruleset with Policy Logic | Translated to `TRUE()` |
| Table is not explicitly connected to Policy | Blank DAX |
| Native Ruleset defined as `FALSE()` | Translated to `FALSE()` |

> **Known limitation** A Policy defined only with Blank DAX expressions is considered incomplete.

#### Defining a Ruleset for Row-Level Filtering

**To define a structured 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](/docs/object-side-panel#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.

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(359).png)

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(360).png)

**To define a Native Ruleset**: To manage policies in their native DAX form directly within PlainID:

1. In the **Authorization Workspace**, navigate to **Assets and Conditions tab**.
2. Select on the relevant **Asset Type**.
3. Click on **Rulesets**.
4. Click on **Create Ruleset**.
5. Click the **AND/OR** dropdown and select **Native**.
6. Add a **DAX Expression** and click **Done**.

To explicitly block access to a Table, you must define a Ruleset that evaluates to `FALSE()`.

### 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**:

1. 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](/v1/docs/managing-conditions) to learn how to create a new Identity Attribute Condition.
  - Ensure that the Condition meets the [Conditions for Row-Level Requirements](/v1/docs/Row-Level-security#conditions-for-rowlevel-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.
2. 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](/docs/object-side-panel#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.

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(362).png)

### 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.

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(364).png)

## PlainID Row Access Structured DAX Policy

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** |
| Security Roles for Conditions | `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 Power BI 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.* ![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(367).png)

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(370).png)

![Image](https://cdn.document360.io/726c7002-05a9-480e-b986-42c9e8824acd/Images/Documentation/image(371).png)