Power BI / Intermediate: context, quality and access / Lesson 11

Row-level security and access boundaries

Separate data-row restrictions from report filters, workspace roles and distribution permissions while designing explicit identity-based acceptance cases.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain RLS roles and filter propagation.
Distinguish viewer enforcement from editing-role access.
Test allowed, denied and unexpected identities with synthetic data.

Separate selection from security

A report slicer helps a reader choose data; it is not an access-control boundary. Hiding a page or field also does not establish that a user cannot query underlying data through another permitted path. RLS defines allowed rows in the semantic model for applicable users and roles. Its propagation depends on the model’s relationships and security design. Begin with the principal, allowed data population and supported consumption path. The course uses North and South as synthetic regions, with50 and20 revenue respectively, and never reads real identities, tenant settings or restricted data.

Define a role and its context

The first snippet is a static role filter on DimRegion. With an active region-to-fact relationship, an applicable North viewer should see the North facts and their50 total. A role definition alone does not assign service users or validate the relationship. Dynamic security can use a governed identity-to-region mapping and a supported identity function, but an unknown identity needs a deliberate fail-closed design. Do not place actual user principal names or tokens in public examples. The illustrated rule is unexecuted and assumes an import-model teaching context; other connection modes have their own restrictions.

dax Unexecuted static RLS role expression

DimRegion[Region] = "North"

Assume this filter is defined on DimRegion and propagates through the intended active relationship. It is not a complete security deployment or a service test.

Understand workspace-role limits

The official Power BI RLS guidance states that workspace Viewer users are restricted by RLS, while workspace Admin, Member and Contributor roles are not restricted in that way. Testing only as an author can therefore give the wrong assurance about a consumer scenario. Report sharing, app audiences, Build permission and row restrictions are related but different decisions; review the exact documented path instead of assuming one checkbox secures every export or query. A personal Desktop test is useful for role logic but does not prove actual service membership and permissions. Never publish sensitive material merely to demonstrate the lesson.

Model multiple-role populations

Membership in more than one RLS role can broaden the allowed row population through the roles’ combined allowances; it should not be assumed to create a deny intersection. The second program models a simple union of region sets. It is not the service authorization engine and omits relationship and permission details. A user accidentally assigned North and South can see more than a designer expected from reviewing only North. Keep group membership and identity mapping within the security review. Do not try to counteract an overbroad allowance with a visual filter that a consumer may change.

python Synthetic combined-role allowance

north_role = {"North"}
south_role = {"South"}
allowed = north_role | south_role
print(sorted(allowed))
print(sum(value for region, value in [("North", 50), ("South", 20)] if region in allowed))

Expected output

['North', 'South']
70

Both regions and total70 are allowed by this toy union. It does not test actual RLS, identity resolution or workspace roles.

Write security acceptance cases

Define an authorized North viewer, South viewer, unexpected identity, multiple-role member and editing-role case. Specify expected rows and aggregates, not merely whether a report opens. Verify relationship paths and the supported consumption/export scenarios through separately authorized testing. This course runs only the set-union model and performs no sign-in, role assignment or service request. The local result cannot establish enforcement. A reviewable security handoff separates role logic, identity membership, workspace permissions and observed data access, preserving each unresolved question rather than calling a hidden report page secure.

Common errors and fixes

A slicer is presented as row-level security

Why it happens: User selection was confused with model access enforcement.
How to fix it: Define actual row restrictions and review all permitted consumption paths.
Prevent it next time: Keep presentation filters separate from security claims.

Author access is used to validate a Viewer scenario

Why it happens: Workspace role differences were ignored.
How to fix it: Test the intended consumer identity and permissions under official RLS rules.
Prevent it next time: Include editing-role and viewer-role cases separately.

Multiple roles unexpectedly broaden data access

Why it happens: Combined allowances were assumed to intersect restrictively.
How to fix it: Review all applicable memberships and the resulting allowed population.
Prevent it next time: Maintain an explicit multiple-role acceptance case.

Check your understanding

1. Why does hiding South on a report page not prove North-only access?

Show worked solution

A page filter is presentation state and another permitted report, query or export path can expose a different selection. Security requires applicable model restrictions plus correct identity and permission configuration. Define expected denied rows and test the actual consumer scenario through authorized evidence, without relying on a visual’s current appearance.

2. A user belongs to North and South roles. Why must both memberships enter the expected result?