Understanding Object-Level Security Fundamentals in Power BI

Course: Microsoft Power BI Training

Topic: Understanding Object-Level Security Fundamentals

Course Link: Microsoft Power BI Training at JustAcademy

Demo Link: Register for a Course Demo

JustAcademy Website: Visit JustAcademy

1. Introduction to Object-Level Security

Object-Level Security (OLS) is a security feature in Power BI that controls access to specific objects within a semantic model, such as tables and columns. It is designed to protect sensitive information by preventing unauthorized users from accessing particular data objects and their metadata.

In a business environment, a Power BI semantic model may contain employee information, salary details, customer contact information, financial figures, profit margins, and other confidential data. However, not every report consumer should have permission to access every table or column.

For example, a company's employee dataset may contain Employee Name, Department, Email Address, Salary, and Performance Rating. Department managers may need to analyze employee details, while salary information should remain accessible only to authorized HR or payroll personnel.

OLS helps implement these requirements by restricting access to specific tables or columns for users assigned to appropriate security roles.

1.1 Learning Objectives

• Understand the meaning and purpose of Object-Level Security.
• Identify the difference between OLS and Row-Level Security.
• Understand table-level and column-level security.
• Learn how security roles control access to model objects.
• Understand the difference between hiding a field and securing it.
• Explore how OLS can be configured using Tabular Editor and TMDL.
• Learn how to test and validate OLS rules.
• Identify common implementation challenges and limitations.

2. What Is Object-Level Security?

Object-Level Security is a semantic-model security mechanism that restricts access to specified tables or columns. It can also protect the metadata associated with secured objects, helping prevent unauthorized users from discovering sensitive object names.

When a table or column is secured with OLS, users without the required permission cannot query or interact with that object through the secured model. From their perspective, the object is effectively unavailable.

2.1 Example of OLS

Consider an Employee table containing the following columns:

Suppose the organization wants to let general report consumers view employee names and departments but prevent them from accessing the Salary column.

With an appropriately configured OLS role, users assigned to that role can access permitted columns while the Salary column remains secured.

2.2 Why Is OLS Important?

• Protects confidential business information.
• Restricts unauthorized access to sensitive tables and columns.
• Helps prevent exposure of sensitive object names and metadata.
• Supports data governance and access-control requirements.
• Allows different audiences to use a shared semantic model with different object permissions.
• Reduces reliance on maintaining separate models solely to hide individual sensitive fields, where a shared model is otherwise appropriate.

3. Understanding Semantic Models and Objects

A Power BI semantic model is the structured representation of data used to build reports and perform analysis. It contains tables, columns, relationships, measures, hierarchies, and other model elements.

Understanding these objects is essential before configuring OLS.

OLS primarily secures table and column objects. Measures are not directly secured as standalone objects through OLS, but measures that reference secured tables or columns can become unavailable to users who lack permission to those objects.

4. Types of Object-Level Security

Object-Level Security can be implemented at different levels depending on the information that needs protection.

4.1 Table-Level Security

Table-level security restricts access to an entire table. Users assigned to a role without the required permission cannot access the secured table or its metadata.

For example, a semantic model may contain a PayrollDetails table that includes confidential payroll information. General business users may not need access to this table at all.

Table-level OLS can prevent those users from accessing the table through the secured semantic model.

4.2 Column-Level Security

Column-level security restricts access to a particular column while allowing users to access other permitted columns in the same table.

For example, an Employee table might contain EmployeeName, Department, Email, and Salary. OLS can restrict Salary while leaving the other permitted columns available.

4.3 Comparison of OLS Types

5. Difference Between OLS and RLS

Object-Level Security and Row-Level Security are different security mechanisms. OLS determines which tables or columns users can access, while RLS determines which rows they can see.

5.1 Example Combining OLS and RLS Requirements

A company may want to implement two separate restrictions:

• Regional managers can see only the sales records for their assigned region.
• Those managers cannot access the confidential InternalCost column.

RLS can restrict the rows based on region, while OLS can restrict the InternalCost column. Both controls address different security requirements.

However, OLS and RLS must be designed with the model's role-combination restrictions in mind. In particular, combining an OLS role and an RLS role through separate memberships can cause query errors. Design and test the role configuration carefully rather than assuming that independently created roles will always combine safely.

6. Difference Between Hiding a Column and Securing It

One of the most important concepts in Power BI security is the difference between hiding a field and restricting access to it.

6.1 Hiding a Column

Power BI allows developers to hide columns from the report field list. This can simplify the development experience and prevent report authors from selecting fields that should not normally be used in visuals.

However, hiding a column is not a security mechanism. A hidden field may still be accessible through other supported model-query or authoring paths by users who have sufficient permissions.

6.2 Securing a Column with OLS

OLS provides actual access restrictions at the semantic-model level. A user without the necessary permission cannot query the secured object through the model merely by knowing its name.

Important: Never rely on hiding a column, renaming it, removing it from a visual, or hiding a report page as the only protection for confidential data.

7. Common Business Scenarios for OLS

7.1 Human Resources

HR semantic models may contain employee details, salaries, personal contact information, performance evaluations, and payroll data.

OLS can restrict access to sensitive columns or entire tables so that only authorized roles can query the relevant objects.

7.2 Finance and Accounting

Financial reports may contain revenue, expenses, profit margins, internal costs, and confidential forecasts. Different business audiences may require different levels of detail.

OLS can restrict access to specific financial columns or tables that should not be available to ordinary report consumers.

7.3 Sales and Marketing

Sales models may contain customer contact information, contract values, commission rates, or confidential pricing data.

OLS can restrict access to selected fields while preserving access to other approved sales information.

7.4 Healthcare and Personal Information

Where an organization processes sensitive personal or healthcare information, OLS can be one part of the security architecture for restricting access to specified model objects.

It should be combined with appropriate source-system controls, identity management, access reviews, and relevant privacy and compliance requirements.

8. Understanding OLS Roles and Permissions

OLS definitions are configured within semantic-model roles. The role specifies whether a particular table or column is accessible to users assigned to that role.

8.1 Common Object Permission Values

Read is the normal permission for accessible model objects. Setting an object's metadata permission to None is used to secure that object from the specified role.

8.2 Example Role Design

Suppose a company has the following user groups:

The developer can define the appropriate OLS permissions for each role and then assign users to the intended role membership in the Power BI service.

9. Tools Used to Configure OLS

Object-Level Security requires model-level configuration. The main approaches include Tabular Editor and Tabular Model Definition Language (TMDL) view.

9.1 Tabular Editor

Tabular Editor is an external tool for creating and managing tabular semantic models. It can be used to configure object permissions for roles, including table-level and column-level OLS.

General workflow:

1. Open the model in Power BI Desktop.
2. Create or verify the required security roles.
3. Open Tabular Editor through the External tools ribbon when available and configured.
4. Locate the role you want to configure.
5. Open the role's table permissions.
6. Set the relevant table or column permission to None or Read as required.
7. Save the model changes.
8. Publish the semantic model.
9. Assign users or supported groups to the appropriate roles in the Power BI service.

9.2 TMDL View

Tabular Model Definition Language is a textual representation of semantic-model metadata. In supported Power BI authoring environments, TMDL view can be used to define roles and object-level permissions through scripts.

This method is useful for developers who prefer a script-based approach to model configuration and review.

9.3 Comparison of Configuration Approaches

10. Creating Table-Level OLS with Tabular Editor

Consider a semantic model containing a confidential PayrollDetails table. General report users should not be able to access this table.

10.1 Step-by-Step Procedure

1. Open Power BI Desktop and load the semantic model.
2. Select Modeling and open Manage roles.
3. Create a role named GeneralReportUsers if it does not already exist.
4. Save the role definition.
5. Open Tabular Editor from the External tools ribbon.
6. Locate the Roles section and select GeneralReportUsers.
7. Expand the role's Table Permissions.
8. Locate PayrollDetails.
9. Set the table's Object-Level Security metadata permission to None.
10. Save the changes.
11. Return to Power BI Desktop and publish the semantic model.
12. Assign the intended report consumers to the role in the Power BI service.
13. Test access using a properly permissioned Viewer account.

10.2 Expected Result

Users assigned to GeneralReportUsers should not be able to access the secured PayrollDetails table through the semantic model. Other tables that remain accessible to the role can continue to support approved reporting scenarios.

Before deploying the configuration, verify that securing the table does not break necessary relationship paths or cause unexpected report errors.

11. Creating Column-Level OLS with Tabular Editor

Column-level OLS is useful when only a few fields in a table contain confidential information.

11.1 Example Requirement

An Employee table contains:

• EmployeeID
• EmployeeName
• Department
• Email
• Salary

General report consumers may access the employee name and department, but the Salary column must remain inaccessible.

11.2 Step-by-Step Procedure

1. Open the model in Power BI Desktop.
2. Create or select the GeneralReportUsers role using Manage roles.
3. Open Tabular Editor through External tools.
4. Expand Roles and select GeneralReportUsers.
5. Open Table Permissions for the Employee table.
6. Locate the Salary column permission.
7. Set the column's Object-Level Security metadata permission to None.
8. Keep the table itself accessible to the role.
9. Save the model changes.
10. Publish the model to the Power BI service.
11. Assign the intended users to the role.
12. Test access to permitted fields and verify that Salary cannot be queried by the restricted users.

11.3 Expected Result

The Employee table remains available to the role, but the secured Salary column and its metadata are inaccessible to users without the required permission.

12. Example TMDL Definitions for OLS

TMDL provides a script-based approach for defining role permissions in supported semantic-model authoring environments.

12.1 Securing an Entire Table

The following example demonstrates the general structure of a role that restricts the Customers table.

createOrReplace

    role CustomersRestricted
        modelPermission: read

        tablePermission Customers
            metadataPermission: none

In this example, the role is named CustomersRestricted. The Customers table is configured with metadataPermission set to none, restricting access to that table for the role.

12.2 Securing a Specific Column

The following example restricts the Address column in the Customers table.

createOrReplace

    role CustomersRestricted
        modelPermission: read

        tablePermission Customers
            columnPermission Address
                metadataPermission: none

In this example, the table remains accessible while the Address column is secured.

12.3 Important TMDL Considerations

• Use the exact table and column names from the semantic model.
• Ensure the role exists or that the script correctly defines the intended role.
• Review the script before applying changes.
• Use Preview when available to inspect the proposed model changes.
• Apply the script only after validating its contents.
• Save and publish the updated semantic model.
• Test the role using an account that has the intended permissions.

Official documentation: Microsoft Learn — Object-Level Security with Power BI.

13. Securing Measures and Calculations

Measures are calculations created with DAX and used in report visuals. OLS does not provide a direct permission setting that independently secures a measure in the same way it secures a table or column.

However, a measure can become inaccessible if its expression references a table or column that is secured from the user.

13.1 Example Measure

Total Salary =
SUM(Employee[Salary])

If the Salary column is secured from a role, a measure that depends on that column can also become unavailable to users assigned to that role.

13.2 Important Design Consideration

Do not assume that hiding a measure in the report field list secures the underlying information. Identify which columns and tables the calculation depends on and test the result under each relevant security role.

If a measure needs to be available to one audience but not another, design and validate the model's object permissions and calculation dependencies carefully.

14. Combining OLS with Other Security Controls

OLS is one layer of the Power BI security architecture. A secure reporting solution may also require authentication, workspace permissions, RLS, semantic-model permissions, and source-system security.

Each control serves a different purpose. OLS does not replace the need for appropriate workspace permissions, source-system protection, or user authentication.

15. Important OLS Limitations

Before implementing OLS, developers should understand its operational restrictions and design implications.

15.1 Workspace Role Limitation

OLS applies to users accessing the semantic model as Viewers. Workspace users assigned the Admin, Member, or Contributor role have editing permissions and are not restricted by OLS in the same manner.

To protect sensitive model objects from report consumers, carefully review workspace access and avoid granting editing roles to users who should be restricted by OLS.

15.2 Relationship Dependencies

Securing an entire table can break a relationship chain that other tables depend on. Power BI may reject a configuration that breaks required relationships.

For example, if Table A connects to Table B and Table B connects to Table C, securing Table B may prevent queries from traversing the relationship chain between A and C.

Review the model structure before securing entire tables. When appropriate, securing an individual column rather than the entire table may avoid unnecessary disruption.

15.3 Unsupported Features

Some Power BI features have limitations when a semantic model contains OLS-secured objects. Microsoft documentation identifies limitations for features such as Quick Insights, Smart Narrative visualizations, and the Excel Data Types gallery. Check current documentation for the applicable feature support before deployment.

15.4 Report Visual Errors

If a report visual references an object that the user is not allowed to access, the visual may display an error indicating that the field cannot be found or used. This can occur even though the report author can access the field.

Report authors should design reports with their intended audiences in mind and test each security role before distribution.

16. Testing and Validating OLS

Testing confirms that users can access permitted objects while unauthorized objects remain inaccessible.

16.1 Testing Checklist

• Verify that the role contains the intended object permissions.
• Confirm that sensitive tables are inaccessible to restricted users.
• Confirm that sensitive columns are inaccessible to restricted users.
• Verify that permitted tables and columns remain available.
• Test measures that reference secured columns or tables.
• Review report visuals that depend on restricted objects.
• Confirm that role membership is correct in the Power BI service.
• Test with an account that has Viewer permissions.
• Review workspace roles to ensure that elevated permissions do not undermine the intended restrictions.
• Validate the behavior of reports, exports, and downstream analysis paths that are relevant to the organization.

16.2 Testing with Different Users

Suppose a report has two user groups: GeneralReportUsers and PayrollUsers.

Actual access depends on the complete role configuration and any other applicable permissions. Always validate the effective result rather than relying only on the role names.

17. Troubleshooting Common OLS Problems

18. OLS Best Practices

1. Identify sensitive objects: Document the tables and columns that contain confidential information.
2. Apply least privilege: Give each audience access only to the objects required for its work.
3. Prefer column-level security when appropriate: Restrict individual sensitive fields instead of entire tables when the rest of the table is needed.
4. Review relationships: Check whether table-level restrictions will disrupt important model paths.
5. Use descriptive roles: Choose role names that clearly indicate the intended audience or purpose.
6. Test with Viewer accounts: Do not validate OLS only while using an account with editing permissions.
7. Review dependent measures: Check calculations that reference secured objects.
8. Document the configuration: Record the secured objects, role permissions, and business justification.
9. Review permissions regularly: Remove unnecessary access and validate role membership as responsibilities change.
10. Check feature compatibility: Confirm that important Power BI features work with the chosen OLS design.
11. Protect source data: Maintain appropriate access controls in the underlying databases and applications.
12. Validate after changes: Retest security whenever the model schema, roles, or permissions are updated.

19. Hands-On Project: Protecting Employee Salary Information

Project Objective: Implement Object-Level Security to restrict access to salary information while allowing authorized report consumers to analyze permitted employee data.

19.1 Dataset Requirements

Create an Employee table with the following columns:

• EmployeeID
• EmployeeName
• Department
• Email
• Salary

19.2 Business Requirements

• General report consumers can analyze employee names and departments.
• General report consumers must not be able to access Salary.
• Authorized payroll users can access Salary when permitted by the model.
• Both audiences should receive only the access required for their responsibilities.

19.3 Implementation Steps

1. Import the Employee table into Power BI Desktop.
2. Review the model and identify the sensitive Salary column.
3. Create or select the GeneralReportUsers role.
4. Open Tabular Editor or use a supported TMDL workflow.
5. Set the Salary column's OLS metadata permission to None for GeneralReportUsers.
6. Ensure that the Employee table remains accessible to the role.
7. Configure the appropriate permissions for the authorized payroll audience.
8. Save and publish the semantic model.
9. Assign users to the appropriate roles in the Power BI service.
10. Test with a Viewer account from each audience.
11. Confirm that general users cannot query Salary while payroll users can access it if authorized.
12. Document the security rules and testing results.

19.4 Expected Outcome

General report consumers can analyze permitted employee information without accessing the secured Salary column. Authorized payroll users can access the required information according to their role permissions.

20. Interview Questions and Answers

Q1. What is Object-Level Security in Power BI?

Answer: OLS is a semantic-model security feature that restricts access to specific tables or columns and their metadata.

Q2. What is the difference between OLS and RLS?

Answer: OLS restricts access to model objects such as tables and columns, while RLS restricts the rows users can see.

Q3. What is table-level security?

Answer: Table-level security prevents a role from accessing a specified table and its metadata.

Q4. What is column-level security?

Answer: Column-level security restricts access to a specific column while leaving other permitted columns accessible.

Q5. Can hiding a column replace OLS?

Answer: No. Hiding a column is a presentation and modeling convenience, not an access-control mechanism.

Q6. Which tools can configure OLS?

Answer: OLS can be configured using tools and interfaces such as Tabular Editor, TMDL view, and supported tabular-model scripting or object-model approaches.

Q7. Can OLS be used to secure Salary?

Answer: Yes. Column-level OLS can restrict access to a Salary column for roles that should not be allowed to query it.

Q8. Does OLS directly secure measures?

Answer: No. OLS does not directly secure measures as standalone objects, but measures that reference secured tables or columns can become inaccessible to restricted users.

Q9. Does OLS apply to workspace Admins?

Answer: OLS applies to Viewer users. Workspace Admins, Members, and Contributors have editing permissions and are not restricted by OLS in the same manner.

Q10. What is metadata protection?

Answer: Metadata protection helps prevent unauthorized users from discovering the names and structural information of secured objects.

Q11. Can OLS and RLS be used together?

Answer: They address different security requirements, but their role configuration must follow the platform's role-combination restrictions. Separate OLS and RLS memberships can cause query errors, so the design must be tested carefully.

Q12. What happens if a report visual uses a secured column?

Answer: The visual may display an error indicating that the field cannot be found or used in the expression.

Q13. Why should table relationships be reviewed before applying OLS?

Answer: Securing a table may break relationship chains that other tables depend on, potentially causing invalid configurations or unexpected query behavior.

Q14. How should OLS be tested?

Answer: Test with appropriately permissioned Viewer accounts, verify access to allowed and secured objects, and review all dependent visuals and measures.

Q15. What is the main benefit of OLS?

Answer: It provides object-level protection for sensitive tables and columns without relying solely on hidden fields or separate reports.

21. Quick Revision Checklist

• OLS stands for Object-Level Security.
• OLS restricts access to tables and columns in a semantic model.
• OLS can protect the metadata of secured objects.
• Table-level OLS secures an entire table.
• Column-level OLS secures an individual column.
• RLS filters rows; OLS restricts model objects.
• Hiding a field does not provide security.
• Tabular Editor and TMDL are supported approaches for configuring OLS.
• Read permits access to an object; None secures it from the role.
• Measures referencing secured objects can become unavailable.
• OLS applies to Viewers, not workspace editors in the same manner.
• Table-level security must be reviewed for relationship dependencies.
• Some Power BI features have limitations with OLS-secured models.
• Test all security rules with the correct user permissions before deployment.

22. Conclusion

Object-Level Security is an important Power BI security feature for protecting sensitive tables, columns, and their metadata. It helps organizations control which model objects report consumers can access while supporting the development of secure analytical solutions.

Understanding the difference between table-level and column-level security allows developers to select the appropriate protection for each business requirement. Tools such as Tabular Editor and TMDL provide ways to configure OLS permissions within semantic-model roles.

A successful OLS implementation requires careful role design, relationship analysis, appropriate workspace permissions, and thorough testing with actual report-consumer access. When combined with RLS and other security controls where appropriate, OLS helps organizations build trustworthy and well-governed Power BI reporting solutions.

23. Additional Learning Resources

• Microsoft Power BI Training — JustAcademy
• Register for a Power BI Course Demo
• Official JustAcademy Website
• Microsoft Learn: Object-Level Security with Power BI
• Microsoft Learn: Object-Level Security in Tabular Models
• Microsoft Learn: Row-Level Security Design Guidance