Siksha Sarovar

Siksha Sarovar (sikshasarovar.com) is a free educational web application that helps students in India learn programming and prepare for academic and competitive exams. The platform offers structured coding courses (C, C++, Python, Java, HTML, CSS, PHP, Power BI, AI, Machine Learning, Data Science), complete university curriculum notes for BCA/MCA students with previous year question papers, Class 10 and Class 12 CBSE/HBSE school notes, and dedicated preparation material for SSC, UPSC, Banking, Railway and other government exams. Browsing the site is completely free and requires no account. Users may optionally sign in with Google solely to save their learning progress, quiz scores and personal preferences across devices.

Privacy Policy | Terms of Service | Contact Siksha Sarovar | About Siksha Sarovar

v4.0.9 · PWA
Siksha Sarovar logo
Siksha Sarovar
Your Learning Universe

Siksha Sarovar is a free e-learning platform for coding courses, BCA university notes and competitive exam preparation. Optional Google sign-in saves your learning progress across devices.

Initializing knowledge base…
Compiling modules 0%

5.9 Object-Level Security (OLS) vs RLS

Lesson 49 of 62 in the free Power BI notes on Siksha Sarovar, written by Rohit Jangra.

Object-Level Security (OLS) vs Row-Level Security (RLS)

While RLS controls which rows users can see, Object-Level Security (OLS) controls which tables and columns are visible.

What is Object-Level Security (OLS)?

OLS restricts access to specific metadata objects — tables and columns — in the data model. Users with OLS restrictions cannot see or reference the restricted objects.

OLS vs RLS Comparison

FeatureRLS (Row-Level Security)OLS (Object-Level Security)
ControlsWhich rows are visibleWhich tables/columns are visible
ScopeData filteringMetadata hiding
Setup LocationPower BI Desktop + ServiceTabular Editor (external tool)
DAX RequiredYes (filter expressions)No (configuration-based)
Use CaseRegional data accessHiding sensitive columns
ExampleSales rep sees only their salesHR can't see salary column
Performance ImpactCan slow queries (filter evaluation)Minimal (metadata-level)
Combined Use✅ Can use both together✅ Can use both together

When to Use OLS

ScenarioSolution
Hide salary data from non-HR usersOLS on Salary column
Restrict access to a PII tableOLS on the entire table
Hide cost data from sales teamOLS on Cost column
Protect sensitive metricsOLS on the column used in measures

Setting Up OLS

OLS is configured using Tabular Editor (a free external tool for Power BI).

Steps:

  1. Download and install Tabular Editor (free version works)
  2. Open your model in Tabular Editor:
  • From Power BI Desktop → External ToolsTabular Editor
  • Or connect directly to a published dataset
  1. Navigate to the table/column you want to restrict
  2. In the Properties pane:
  • Find Object Level Security
  • Assign None (full access) or Read (hidden) per role
  1. Save changes

OLS Permissions:

PermissionEffect
NoneObject is completely hidden — cannot be seen or referenced
ReadObject is visible and accessible

OLS Behavior

When a table or column is restricted by OLS: • ❌ The object doesn't appear in the Fields pane • ❌ DAX measures referencing it return errors for restricted users • ❌ Visuals using the object show errors • ❌ Q&A queries about the object fail • ✅ Other users (with access) see everything normally

Combining RLS and OLS

You can use both RLS and OLS together for comprehensive security:

Example:RLS: Sales reps see only their own region's data (row filtering) • OLS: Sales reps cannot see the "Cost" and "Margin" columns (column hiding)

Result: A sales rep sees: • ✅ Their region's sales data • ✅ Revenue column • ❌ Other regions' data (blocked by RLS) • ❌ Cost and Margin columns (blocked by OLS)

Limitations of OLS

• ❌ Can only be set up via Tabular Editor (not in Power BI Desktop UI) • ❌ Measures referencing restricted columns will error for restricted users • ❌ Cannot be tested in Power BI Desktop (only in Service) • ❌ Requires careful planning — hiding a column used by many visuals breaks those visuals • ❌ Not available in Power BI Desktop's built-in role management

Best Practices

• Use RLS for row-level data filtering (different users see different data) • Use OLS for column/table hiding (different users see different structure) • Combine both for comprehensive security • Plan OLS before building visuals — adding OLS later may break existing visuals • Create role-specific measures that don't reference OLS-restricted columns • Test thoroughly with different user accounts • Document which roles have access to which objects