Ravindra BagaleCourses & study guides

26. Row-Level Security (RLS)

26.5 Important Rules

  • RLS restricts viewers. Workspace Admins, Members and Contributors can see all data, regardless of roles. Share with end users via app or Viewer role.
  • If a user belongs to multiple roles, permissions are combined (union) – they see everything any of their roles allow.
  • RLS filters are applied before measures run; ALL() in a measure cannot bypass RLS.
  • For Live connection reports, RLS is defined in the source semantic model (or Analysis Services), not in the thin report.
  • Object-Level Security (OLS) hides entire tables or columns from certain roles; it is configured with external tools such as Tabular Editor.
  • Keep security tables small and maintain them in a controlled source (e.g. a SharePoint list or database table).

Always test with real accounts

Mhanje asa: before go-live, test each role with actual test users in the Service. A mistake in an RLS rule can expose confidential data, or hide data the user should see.

Ravindra Bagale's Tip

Remember one thing: RLS does not apply to workspace Admins, Members and Contributors, and bi-directional relationships can leak or block filters in unexpected ways. Give consumers Viewer or app access, and review relationship directions whenever you add RLS. Keep this in mind!

Thodkyaat sangaycha tar (quick recap)

Static RLS mhanje fixed rule, dynamic RLS mhanje USERPRINCIPALNAME aani security table; View as ne test kara; aani lakshat theva, RLS Admin/Member/Contributor la lagu hot nahi. Aata pudhe jaauya performance kade.