Two security roles do not necessarily narrow each other. In Power BI, membership in multiple row-level security roles can broaden the permitted row set. Test that rule with invented records before assuming a second role adds a restriction.

Use a separate local Power BI Desktop import model containing only harmless practice data. Create a table with IDs N1 and N2 in Region North and S1 in Region South. Display those IDs and regions in a table visual so the test checks actual membership, not just a potentially misleading aggregate.

Define and test the two allowed sets

In Modeling, Manage Roles, create a North role and select the practice table. In the DAX editor, use [Region] = "North" and save. Create a South role with [Region] = "South". Desktop defines the rules; assigning real users to published roles is a separate service operation.

Use Modeling, View as to test North alone, then South alone. In the practice report, expect N1 and N2 for North and S1 for South. Confirm the selected test role each time rather than relying on the preceding report state.

Next test both roles together. Microsoft's guidance states that multiple role filters are additive: permitted rows form a union. A rule that denies a row in one role does not override another role that permits it. For this sample, the combined result should contain N1, N2 and S1, not an empty intersection.

Record what the test does and does not establish

Write down the selected role set and expected IDs for all three tests. If a row is missing or unexpectedly present, inspect the rule, table and active test selection before altering the sample. Keep the single-role results because they help distinguish a bad individual rule from a mistaken combination assumption.

This local exercise validates a model rule on known data. It cannot substitute for deployment acceptance with the intended accounts, actual role memberships, semantic-model permissions and report access paths. In the Power BI service, RLS applies to workspace Viewers; workspace Admin, Member and Contributor roles are not restricted by it.

For a real design, document the intended visible records per audience and have the responsible owner validate deployed access separately, including relevant combinations. Do not publish the practice model or change production membership simply to reproduce this example. The useful result is a clear account of additive row access and a test record that cannot be mistaken for a security sign-off on a live deployment.

Sources: Microsoft: row-level security guidance; Microsoft: supporting procedure; Microsoft: supporting procedure.