In Power BI, what does a row-level security role do to the data a report user sees?

## What a role is Row-level security (RLS) in Power BI is implemented with **roles**. A role is a name plus, for each table you choose, one DAX expression that must evaluate to TRUE for a row to be visible. A role that filters nothing on a table leaves that table unrestricted. Roles are authored in Power BI Desktop (Manage roles), stored in the model metadata, and travel with the file when you publish. A typical static filter looks like: ``` [Region] = "West" ``` placed on `DimRegion`. Anyone assigned to that role sees only the West row of the dimension. ## Where the filter is applied The key point most candidates miss: the role filter is applied by the storage engine **outside** the report's own logic. Conceptually the order is: security filter → report/page/visual filters and slicers → measure evaluation. That has two consequences. First, **totals are secure**. A card showing `SUM(Sales[Amount])` for a restricted user is the total of the rows that user may see, not the grand total with rows hidden from the table visual. Nothing in the report can reveal the suppressed rows, including drillthrough, tooltips, Export data, Analyze in Excel, or a query issued over the XMLA endpoint. Second, **filter-removing DAX does not bypass it**. `ALL`, `ALLEXCEPT` and `REMOVEFILTERS` clear the filters the report placed on a table; they cannot clear the security filter. So `CALCULATE(SUM(Sales[Amount]), ALL(DimRegion))` — the usual "percent of total" pattern — returns the user's own total, which is why a "% of all regions" measure quietly becomes "% of my regions" under RLS. That is correct security behaviour, and a design problem you have to solve another way (for example by publishing a separate unrestricted aggregate, or accepting the restricted denominator). ## How the filter reaches the fact table RLS relies entirely on the model's relationships. A filter placed on a dimension flows to the fact table exactly as any other filter does — down the one-to-many relationship, in its cross-filter direction. This is why RLS is usually applied to the **dimension**, not the fact: one small predicate on `DimRegion` restricts `FactSales`, `FactBudget` and anything else related to it. It also means RLS inherits every propagation weakness of the model. If a relationship is missing or inactive, or points the wrong way, or a fact table is disconnected, the filter does not arrive and rows leak. Filtering a table on the *many* side (a user-permission bridge, for example) reaches the *one* side only if the relationship is bi-directional or has the relationship's security-filtering-in-both-directions option enabled. ## Static versus dynamic The filter above is **static**: the permitted value is hardcoded, so you need one role per audience (West, East, EMEA…) and you maintain membership by hand. **Dynamic** RLS writes one role whose filter compares a column to the signed-in identity, typically `[UserEmail] = USERPRINCIPALNAME()` on a user-mapping table, so a single role serves every user and permissions are data you can refresh. Dynamic is the standard answer for "each manager sees only their region". ## Defining versus assigning Desktop defines roles and their expressions; it does **not** hold membership. After publishing, an admin opens the semantic model's security settings in the Power BI Service and adds users or, better, Microsoft Entra security groups to each role. Membership by group means joiners and leavers are handled by identity management rather than by a BI admin. ## What RLS is not RLS filters **rows**. It does not hide a column or a table — a restricted user still sees that a `Salary` column exists and can put it on a visual (over their permitted rows). Hiding metadata is object-level security (OLS), a separate feature configured through external tooling against the model, not in the Desktop RLS dialog. RLS also does not restrict people who can edit the model. A user with workspace edit rights bypasses roles entirely, so consumers must land in read-only access (Viewer, or an app audience) for RLS to mean anything. ## Modes RLS works in Import and DirectQuery models. Under DirectQuery the predicate is pushed into the generated source query, so the source database sees a filtered SQL statement. For a live connection to an external Analysis Services model, the roles live in that source model, not in the report.