Power BI row-level and object-level security

For Power BI semantic models shared across many users, controlling what each user is allowed to see is essential. Two related features handle different cases: Row-Level Security (RLS) filters rows; Object-Level Security (OLS) hides entire tables or columns.

Row-Level Security (RLS)

RLS filters the rows visible to a user based on a DAX expression that runs in the user's context. Common patterns:

• A salesperson sees only their own customers — [SalesRep] = USERNAME().
• A regional manager sees only their region — [Region] = LOOKUPVALUE(...).
• An executive sees all rows — granted a role with no filter.

How RLS works

RLS is defined in Power BI Desktop with roles:

1. Modelling tab → Manage roles → New role.
2. Define a DAX filter on each table where rows should be filtered.
3. Assign users or Entra ID groups to roles in the Power BI Service.

When a user opens a report, Power BI evaluates which roles they're in, applies the union of their filters, and filters every visual accordingly.

Static vs dynamic RLS

• Static RLS — role assignment is by user group. "Sales East role" filters to East region.
• Dynamic RLS — the filter uses USERNAME() or USERPRINCIPALNAME() and looks up the current user's permitted scope from a security table in the model.

Dynamic is more flexible — adding a new sales rep doesn't require touching role definitions. Just add them to the security table.

Testing RLS

Power BI Desktop lets you view the report as a specific role or user before publishing. Essential for validation.

Common pitfalls

• DirectQuery RLS — works but each visual generates filtered SQL; performance varies.
• Cross-filtering relationships — RLS on one table propagates via relationships; verify the expected filtering occurs everywhere.
• Many-to-many complexity — RLS interacts with composite filter logic in non-obvious ways. Test thoroughly.
• Service principals and embedded scenarios — RLS evaluates differently when the report is embedded in an app via a service principal. Use the effective identity feature in the embedding code.

Object-Level Security (OLS)

OLS hides entire tables or columns from users in specific roles, rather than filtering rows.

Use cases:

• HR salary data — hide the salary column from non-HR users.
• Internal cost data — hide cost tables from sales users.
• Confidential metadata — hide auditing columns from regular users.

How OLS works

Defined in Tabular Editor (an external tool, free): mark specific tables or columns as visible only to specific roles. Users not in those roles can't even see the column exists — visuals referencing it would fail.

For users in roles where a column is hidden, measures referencing the hidden column also fail. This can break dashboards in non-obvious ways; verify carefully.

When OLS is right

• Truly confidential columns / tables that some users shouldn't even know exist.
• Compliance scenarios where filtered rows aren't enough — the field itself must be invisible.

When OLS isn't right

• If filtering would suffice — RLS is simpler.
• If "out of scope" means "show as null/N/A" — a calculated column with conditional logic is friendlier than OLS.

Combined RLS + OLS

The two can be combined: filter rows AND hide columns based on role. A sales rep sees their own customers (RLS) and doesn't see the cost column (OLS).

Operational considerations

• Source-of-truth security tables — for dynamic RLS, the security table should be authoritative and well-maintained. Stale data here means wrong access.
• Documentation — document the role definitions and the security model. Without docs, future maintainers won't know how access works.
• Audit — Power BI logs which users access which reports; combined with role memberships, you can audit who saw what.
• Service principals — for embedded scenarios, the embedding app's code controls the effective identity. Get this right.

For Power BI semantic models with mixed-sensitivity data shared across heterogeneous audiences, RLS and OLS are how you serve everyone without proliferating the model. Built once, applied consistently, audited centrally.