What is row-level security (RLS)?
Row-level security (RLS) is a security mechanism that controls which rows of data a user may see in a report or data model. In Power BI, RLS ensures that every user opens the same report but only sees the data released for them, such as only their own region or department.
Also known as: RLS · row-based security
Where row-level security is used
Row-level security filters the data per user without having to build a separate report for each group. Through defined roles and filter rules, it is determined which rows a person may see. Often the identity of the signed-in user is used to dynamically show the appropriate rows (dynamic RLS).
In Power BI, RLS is defined on the semantic model and applies to all reports built on it. This makes access control central and consistent instead of repeating it per report.
Typical use cases
Row-level security is needed as soon as the same report is used by people with different viewing rights.
- Regional or branch managers see only their own region
- Sales staff see only their own customers or territories
- Tenant or customer separation in a shared report
- Department-specific views without separate report copies
How it relates & how smiit uses it
RLS controls which rows are visible, not which reports or workspaces someone may open; that is governed by the permissions in Power BI above it. RLS is a concrete tool of data governance and is implemented on the semantic model, often in combination with DAX filter expressions. In the dy Project AG data platform, RLS ensured that different project participants saw only the data relevant to them. smiit designs RLS so that it stays secure, traceable and performant.
Common mistakes & misconceptions
- Row-level security hides only rows, not columns. Sensitive fields stay visible for permitted rows; hiding columns needs different mechanisms.
- Many believe RLS automatically protects every access path, but rules apply in the model while export, direct source access or missing tests can bypass them.
- A common error is to skip testing RLS roles after creating them. Without view-as-role testing, misconfigurations often go unnoticed.
Frequently asked questions
What is the difference between static and dynamic RLS?
With static RLS, a fixed filter is stored per role. With dynamic RLS, the identity of the signed-in user is used to determine the visible rows automatically, which is considerably less maintenance with many users.
Does row-level security protect the data completely?
RLS controls the visibility of rows in the report. For comprehensive protection it belongs in an overall concept of permissions, encryption and governance, which smiit considers holistically.
How do you test whether row-level security works correctly?
Power BI provides a feature that lets you view a report from the perspective of a specific role or user. This makes it possible to verify before publishing that each role really only sees the intended rows.
Does row-level security affect a report's performance?
RLS filters are evaluated with every query and, with very complex rules or large models, can influence response times. With a clean data model and filter expressions kept as simple as possible, the effect usually stays small.
Related terms
Sources & further reading
Want to put this topic to work in your company?
Updated · Back to the glossary