Row-level security in Power BI is often introduced as a DAX rule attached to a role. The real security boundary is larger. The rule depends on identity, workspace permissions, model relationships, data-access mode, role membership, and the assumption that every filter path reaches the rows that should be protected. A rule can be syntactically correct and still fail the business intent if one of those surrounding conditions is wrong.
The PL-300 manage-and-secure scope makes row-level security an operational design topic, not a settings checklist. The goal is to define which users are allowed to see which rows, place the rule where filters propagate predictably, prevent privileged workspace roles from being mistaken for restricted consumers, and collect evidence that the boundary works after every model change.
Start with the protected business entity
An RLS design should begin with a sentence such as “sales managers can see transactions for the regions they are assigned” or “customers can see only their own account rows.” That sentence identifies the protected entity and the mapping between identity and allowed data. Writing DAX before the mapping is clear usually creates rules that are difficult to test.
The broader principle behind role-based access control applies directly: access rules should express business authorization, not merely technical convenience. A role name such as West Region is useful only when the organization has a reliable process for deciding who belongs in it.
Entitlement can be hierarchical. A country manager may inherit access to all regions in that country while a regional manager sees only one region. That hierarchy should be modeled as data or a controlled mapping, not recreated through dozens of hard-coded role expressions that become impossible to maintain.
RLS filters rows, not model objects
Row-level security restricts which rows are visible through the semantic model. It is not a mechanism for hiding a sensitive table, column, or measure from a user who otherwise has access to the model. Object-level security and workspace permissions solve different problems.
This distinction matters when a model contains fields that should not be discoverable at all. A row filter that returns no values from a sensitive column does not automatically create the same boundary as removing access to the object.
Sensitive metadata can still leak through field names, model descriptions, or discoverable objects even when rows are filtered. If users should not know that a field exists, RLS is the wrong control. The security architecture should decide separately which objects are visible and which rows within visible objects each user may query.
Workspace roles determine whether RLS is enforced
In the Power BI service, RLS is intended for consumers such as users with Viewer permissions. Workspace Admins, Members, and Contributors have broader access and are not constrained by RLS in the same way. Treating a workspace role as just another report-sharing convenience can therefore bypass the intended restriction.
Identity design should be reviewed together with Microsoft Entra identity and access management. Groups, service principals, workspace roles, and semantic-model roles form one chain. A least-privilege consumer path is stronger than an RLS rule placed underneath overly broad workspace permissions.
Sharing paths outside the workspace also need review. Apps, direct semantic-model permissions, report sharing, and build permissions can change what a user is allowed to do even when the RLS role itself is correct. The security review should follow the identity from entry point to query, not stop at the role definition.
Filter propagation makes relationship design part of security
RLS filters a table, then model relationships propagate those filters to related data. Active, deterministic relationships are therefore security infrastructure. A rule on a Region dimension can protect a Sales fact when the relationship correctly carries the filter. An inactive or ambiguous path can produce a very different result.
This is why the Power BI semantic layer should be modeled for clarity before security rules are added. Security is easier to validate on a star schema with controlled filter paths than on a dense graph of bidirectional relationships.
Inactive relationships deserve special caution because RLS filters do not automatically propagate through them in the same way as active paths. A measure can activate a relationship for calculation, but the security design should not assume an alternate analytical path automatically becomes a protected security path.
Dynamic RLS turns identity into data
Dynamic security commonly maps the signed-in user to allowed entities using functions such as USERPRINCIPALNAME and a security-mapping table. That approach scales better than creating a separate role for every region or customer, but it shifts the risk to the mapping data. A stale assignment can grant too much access even when the DAX rule is perfect.
The mapping table therefore needs an owner, update process, uniqueness rules, and a way to remove access promptly. Security data is production data and should be governed with the same care as the facts it protects.
Group-based assignments can reduce administrative work, but they move lifecycle control into directory groups. Joiner, mover, and leaver processes therefore matter. A person who changes departments should not retain old group membership long enough to keep historical access that the new role no longer permits.
Identity normalization matters when mappings come from multiple systems. UPNs can change, guests can have different identity formats, and service accounts may not follow employee naming conventions. A stable directory identifier or governed mapping can be safer than assuming a text username is permanent business identity.
Security filters should be placed on stable dimensions
Microsoft guidance generally favors applying RLS filters to dimension tables and relying on relationships to propagate them. That aligns with star-schema design and often performs better than filtering a large fact table directly. It also makes the authorization rule easier to reason about because it targets a business entity such as Region, Customer, or Department.
Filtering facts directly can be appropriate in some designs, but it should be a conscious choice with performance and maintainability consequences. The test is whether the rule remains understandable as new facts and dimensions are added.
The dimension should also have a trustworthy key. If security is applied to Region but the fact table contains unmatched or blank region keys, those rows need an explicit policy. They should not silently fall outside the intended entitlement logic. Security testing should include unknown-member and missing-key scenarios.
Performance is part of the security design
Every RLS query includes security filters, so complex DAX rules and inefficient relationship paths can increase query cost. Dynamic rules that perform expensive lookups or force broad scans may work in development and then slow down under real user concurrency.
The operational lesson from data-quality accountability applies here too: the security mapping should be clean and keyed so the model does not need defensive calculations for every query. Strong data contracts improve both correctness and performance.
Caching can make performance tests misleading when they use one administrative account repeatedly. Test representative restricted users and realistic concurrency so the cost of security filters is visible. A design that feels fast without RLS may behave very differently when every query includes dynamic entitlement logic.
Test as the restricted user, not as the model author
Model authors and workspace administrators often have privileges that make it easy to misread a security test. Power BI provides role-testing capabilities, and production validation should also use representative users or groups with the same workspace permissions as real consumers. Test both positive access and negative access.
A good test matrix includes users with one assignment, multiple assignments, no assignment, recently removed access, and boundary cases where relationships or blank keys might expose unexpected rows. Security testing should try to prove the rule wrong, not merely demonstrate one happy path.
Evidence should be retained for sensitive models. A lightweight test record can document the role or group tested, expected accessible entities, unexpected rows found, and the model version. That creates an audit trail showing that a security change was verified rather than merely deployed.
Regression testing should be rerun after relationship, workspace-role, sharing, or identity-mapping changes even when the DAX role expression did not change. Those surrounding components are part of the trust boundary. A security test that runs only when the role formula is edited misses many of the ways effective access can change in production.
RLS is one layer in a larger trust boundary
Row-level security works when identity, permissions, relationships, and data mappings all support the same authorization statement. It should sit alongside source-system controls, workspace least privilege, governed sharing, and monitoring rather than being treated as the only line of defense. The goal is the same as in any business intelligence platform: give people the data they need without making the semantic model an accidental escalation path.
The strongest design can answer four questions at any time: who is the user, which business entities are they entitled to, which active filter paths enforce that entitlement, and what evidence proves the result. If any answer depends on an informal convention, the RLS boundary is weaker than it appears.
Monitoring should include unexpected access patterns as well as rule tests. Large query volumes from one identity, repeated attempts to access empty entities, or sudden growth in entitlement mappings can signal operational or security issues. RLS does not replace broader auditing, but its mappings and role assignments should be observable enough that unusual changes are noticed.
Access reviews should periodically compare entitlement data with organizational reality. Roles that were correct six months ago can become stale as teams reorganize. Security remains trustworthy only when role membership, directory groups, workspace permissions, and model mappings are reviewed as living operational data.
