Module 9

Security & Governance

Microsoft Purview in Microsoft Fabric

10 lessonsMicrosoft FabricDP-700 Track
Module 9 · Lesson 9.1

Microsoft Purview

Microsoft Purview in Microsoft Fabric

Microsoft Purview is Microsoft's family of solutions for data governance, data security, compliance, and risk management across an organization's data estate.

In the context of Microsoft Fabric, the easiest way to understand Purview is:

Fabric processes and analyzes data; Purview helps organizations understand, govern, classify, protect, and track that data.

A useful mental model is:

               DATA SOURCES
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      Azure       Fabric      Other Data
        │           │           │
        └───────────┼───────────┘
                    ▼
             MICROSOFT PURVIEW
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
    Catalog      Lineage     Protection
       │            │            │
       ▼            ▼            ▼

Discover Data Track Flow Classify Data

1. Why do we need Purview?

Imagine a large organization has:

5,000 Tables

2,000 Reports

500 Lakehouses

200 Warehouses

Thousands of files

Multiple databases

A user asks:

"Where can I find customer sales data?"

Another asks:

"Does this table contain personal information?"

Another asks:

"Where did this Power BI number come from?"

Another asks:

"Which reports will be affected if we change this source table?"

These are not primarily ETL problems.

They are data governance and discovery problems.

Purview capabilities help organizations address them.

2. What is Data Governance?

Data governance means managing data so that it is:

Discoverable
      +
Understandable
      +
Trusted
      +
Protected
      +

Properly Managed

For example, suppose you have:

dbo.CUST_MST_01

A business user may have no idea what it means.

Good governance adds context:

Table:

Customer Master

Description:

Contains active customer information.

Owner:

Sales Data Team

Classification:

Confidential

Contains:

Customer ID

Name

Email

Phone

Used By:

Sales Analytics

Customer 360

Marketing Reports

Now the data is much easier to understand and govern.

3. Major Purview concepts

For Fabric learning, focus on:

Microsoft Purview
       │
       ├── Data Catalog / Discovery
       ├── Metadata
       ├── Classification
       ├── Sensitivity Labels
       ├── Data Lineage
       ├── Data Governance
       ├── Data Protection
       └── Compliance / Risk capabilities

You don't need to master every Purview product on day one.

For a Fabric Data Engineer, the most important concepts are usually discovery, cataloging, classification, sensitivity, and lineage.

4. Data Catalog

A data catalog helps users discover and understand organizational data.

Think of it like:

Google Search for enterprise data

Suppose your company has:

Sales Warehouse

Customer Lakehouse

Finance Warehouse

HR Lakehouse

Marketing Reports

Instead of asking different teams:

"Where is the customer data?"

a governed catalog can help users search and understand available data assets.

Conceptually:

User
 │
 ▼

Search "Customer Sales"

 │
 ▼
Data Catalog
 │
 ├── Customer Table
 ├── Sales Warehouse
 ├── Customer Lakehouse
 └── Sales Report

5. Metadata

Purview works heavily with metadata.

Metadata means:

Data about data.

Suppose:

CustomerID | Name | Country

101 | Ravi | India

That's the actual data.

Information such as:

Table Name

Column Name

Data Type

Description

Owner

Classification

Source

Relationships

is metadata.

Easy memory:

DATA

=

Actual values

METADATA

=

Information describing the data

6. Data Classification

Purview can help identify/classify sensitive types of information.

Suppose a table contains:

CustomerID

Name

Email

Phone

CreditCard

Country

Not every column has the same sensitivity.

Conceptually:

CustomerID

Identifier

Email

Personal information

Phone

Personal information

CreditCard

Highly sensitive financial information

Classification helps organizations understand:

What kind of information does this asset contain?

7. Sensitivity Labels

Sensitivity labels help categorize and protect information according to organizational policies.

For example, an organization might use labels such as:

Public

General

Confidential

Highly Confidential

Imagine:

Marketing Product List

General

Customer Information

Confidential

Employee Salary

Highly Confidential

The exact labels and policies depend on the organization's Microsoft Purview Information Protection configuration.

8. Classification vs Sensitivity Label

Don't confuse these.

Classification

Describes what kind of data exists.

For example:

Email Address

Phone Number

Credit Card Number

Sensitivity Label

Describes how sensitive/protected the information should be.

For example:

Public

General

Confidential

Highly Confidential

Remember:

Classification = What is this data?

Sensitivity = How sensitive is this data?

9. Data Lineage

This is one of the most important Purview concepts for a Data Engineer.

Data lineage shows how data moves and transforms from source to destination.

For example:

SQL Server

Fabric Pipeline

Lakehouse

Notebook

Warehouse

Semantic Model

Power BI Report

This is lineage.

It answers:

Where did this data come from?

and

Where does this data go?

10. Why lineage matters

Suppose the CEO says:

"The Sales Dashboard says revenue is ₹20 crore. Where did this number come from?"

Without lineage:

Power BI Report

???

???

Source?

With lineage:

Power BI Report

Semantic Model

Gold.FactSales

Notebook

Silver.Sales

Pipeline

ERP Sales Database

Now you can trace the data.

11. Lineage for troubleshooting

Imagine:

Source Table

Pipeline

Lakehouse

Warehouse

Power BI

A source column changes:

CustomerID

CustomerNumber

You need to know:

What will this change affect?

Lineage can help identify downstream dependencies:

Customer Table
      │
      ▼
Pipeline
      │
      ▼
Lakehouse
      │
      ▼
Customer Dimension
      │
      ▼
Semantic Model
      │
      ▼

Customer Report

This is called impact analysis.

12. Lineage vs Impact Analysis

They are related but slightly different.

Lineage

Where did the data come from and where does it flow?

Source

Pipeline

Lakehouse

Warehouse

Report

Impact Analysis

What will be affected if I change this asset?

Change Table

Which Pipeline?

Which Model?

Which Report?

Which Users?

Easy memory:

LINEAGE

=

Trace the flow

IMPACT ANALYSIS

=

Understand consequences of change

13. Purview + Fabric

Now connect Purview concepts to the Fabric items you've already learned.

                  MICROSOFT FABRIC
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
   Lakehouse         Warehouse        Eventhouse
       │                 │                 │
       └─────────────────┼─────────────────┘
                         │
                    Pipelines
                         │
                    Dataflows
                         │
                    Notebooks
                         │
                    Power BI
                         │
                         ▼
                  GOVERNANCE LAYER
                         │
                         ▼
                 MICROSOFT PURVIEW
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼

Catalog Lineage Protection

Purview-related capabilities help govern data across this environment.

14. Example with Fabric Lakehouse

Suppose:

Fabric Lakehouse
│
├── Customers
├── Orders
├── Products
└── Sales

The Customers table contains:

CustomerID

CustomerName

Email

Phone

Address

Governance may identify:

Email

Sensitive/Personal Information

Phone

Sensitive/Personal Information

Address

Sensitive/Personal Information

The asset can also have metadata describing:

Owner

Description

Business meaning

Classification

Sensitivity

15. Example with Fabric Warehouse

Suppose your Warehouse contains:

SalesWarehouse
│
├── FactSales
├── DimCustomer
├── DimProduct
└── DimEmployee

DimCustomer contains:

CustomerKey

CustomerName

Email

Phone

Country

DimEmployee contains:

EmployeeID

EmployeeName

Department

Salary

Clearly:

Salary

Sensitive

Email

Personal information

Phone

Personal information

Governance helps identify and appropriately protect these assets.

16. Data ownership

Another governance question is:

Who is responsible for this data?

Suppose:

FACT_SALES

Who owns it?

DBA?

Data Engineer?

Finance?

Sales?

BI Team?

Governance should establish responsibilities.

For example:

Data Asset
   │
   ▼
FactSales
   │
   ├── Business Owner → Sales Department
   │
   └── Technical Owner → Data Engineering

This becomes extremely important in large organizations.

17. Business glossary

Technical teams may say:

NET_REV_AMT

Business teams say:

Net Revenue

Finance may define it as:

Gross Revenue − Discounts − Returns.

A business glossary helps establish a common business meaning.

Technical Column

NET_REV_AMT

Business Term

Net Revenue

Definition

Gross Revenue - Discounts - Returns

This reduces confusion between teams.

18. Data discovery example

Imagine an analyst needs:

Customer revenue data.

Without governance:

Ask DBA

Ask BI Team

Ask Data Engineer

Search 100 databases

Maybe find table

With a governed catalog:

Search

"Customer Revenue"

Relevant Data Products / Assets

Description

Owner

Classification

Lineage

Use appropriate trusted data

That's the business value of a data catalog.

19. Trusted data

Imagine you find:

Sales_Final

Sales_Final2

Sales_New

Sales_Updated

Sales_Prod

Sales_Report_Final

Which one should you use?

This is a common enterprise problem.

Governance practices can help users identify authoritative, approved, or endorsed data assets rather than guessing.

The goal is:

Many Data Assets

Governance

Trusted / Approved Assets

Business Users

20. Purview and security

Purview doesn't replace Fabric security.

This distinction is important.

Your earlier Fabric Warehouse Security topic covered:

Entra ID

Workspace Roles

Item Permissions

SQL Permissions

RLS

CLS

These answer:

Who can access the data?

Purview governance/protection capabilities answer broader questions such as:

What data do we have?

Where is it?

Is it sensitive?

Where did it come from?

Where does it go?

How should it be governed/protected?

They work together.

21. Fabric Security vs Purview

Fabric SecurityPurview/Governance
Access controlData governance
Workspace rolesCatalog/discovery
Item permissionsMetadata
SQL permissionsClassification
RLSSensitivity
CLSLineage
Who can access?What data exists and how is it governed?

Think:

FABRIC SECURITY

=

Can Sreehari access this table?

PURVIEW / GOVERNANCE

=

What is this table?

Who owns it?

Is it sensitive?

Where did it come from?

Where is it used?

22. Example: End-to-End governance

Imagine customer data starts in Salesforce:

Salesforce
    │
    ▼
Fabric Pipeline
    │
    ▼
Bronze Lakehouse
    │
    ▼
Notebook
    │
    ▼
Silver Customer
    │
    ▼
Warehouse
    │
    ▼
DimCustomer
    │
    ▼
Semantic Model
    │
    ▼

Customer 360 Report

Governance/lineage can help represent that journey.

If EmailAddress contains sensitive information:

EmailAddress

Classification

Sensitivity / Protection Policy

Now the organization knows both:

WHERE DATA CAME FROM
        +
WHAT TYPE OF DATA IT IS
        +

HOW IT SHOULD BE GOVERNED

23. Why Purview matters for compliance

Organizations may have regulatory or internal requirements around:

Personal information

Financial information

Employee information

Customer information

Confidential business data

They need to answer questions such as:

Where is sensitive information stored?

Who owns it?

How is it classified?

Where is it being used?

How does it flow between systems?

Purview capabilities help organizations build this governance and compliance picture.

24. Real-world banking example

Imagine a bank has:

Customer Name

Account Number

Credit Card

Phone

Email

Transaction History

spread across:

SQL databases

Data lakes

Fabric Lakehouses

Fabric Warehouses

Power BI

Governance can help:

Discover

Classify

Catalog

Apply governance/protection

Track lineage

Monitor

This is much more manageable than manually documenting thousands of systems.

25. Purview in your Fabric architecture

Combine everything you've learned:

                  DATA SOURCES
                       │
                       ▼
                  DATA FACTORY
                       │
                       ▼
                    OneLake
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
        Lakehouse  Warehouse  Eventhouse
            │          │          │
            └──────────┼──────────┘
                       ▼
                Semantic Models
                       │
                       ▼

Power BI

              GOVERNANCE / PROTECTION
                       │
                       ▼
               MICROSOFT PURVIEW
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
     Catalog        Lineage      Classification
        │              │              │
        └──────────────┼──────────────┘
                       ▼

GOVERNED DATA ESTATE

26. Purview vs Eventhouse

Since you just studied Eventhouse, don't confuse them.

EVENTHOUSE

=

Store and analyze

real-time event data

PURVIEW

=

Govern, discover,

classify and protect data

They solve completely different problems.

27. Purview vs OneLake

Another useful distinction:

ONELAKE

=

Storage foundation

PURVIEW

=

Governance / protection capabilities

Conceptually:

Microsoft Fabric

                     OneLake
                        │
                    Stores Data
                        │
                        ▼
                Fabric Data Items
                        │
                        ▼
                 Governance Layer
                        │
                        ▼

Microsoft Purview

28. Purview vs Microsoft Entra ID

Don't confuse these either.

Microsoft Entra ID

Primarily answers:

Who is the user?

Identity

Authentication

Groups

Users

Microsoft Purview

Addresses areas such as:

What data exists and how should it be governed/protected?

Catalog

Classification

Lineage

Governance

Information Protection

Compliance

They work together as parts of Microsoft's broader security and governance ecosystem.

29. Important concepts to memorize

For Microsoft Fabric interviews, remember:

MICROSOFT PURVIEW
============================

1. Data Governance

2. Data Discovery

3. Data Catalog

4. Metadata Management

5. Data Classification

6. Sensitivity Labels

7. Data Lineage

8. Impact Analysis

9. Data Protection

10. Compliance / Risk Management

30. Interview question — What is Microsoft Purview?

A strong answer:

Microsoft Purview is Microsoft's set of data governance, security, risk, and compliance solutions. In a Microsoft Fabric environment, Purview capabilities help organizations discover and understand data assets, manage metadata, classify sensitive information, apply sensitivity and protection policies, and understand data lineage across analytical workloads.

31. Interview question — What is Data Lineage?

Data lineage shows the origin, movement, and transformation of data across systems. For example, it can help trace data from a source database through a Fabric pipeline, Lakehouse or Warehouse, semantic model, and ultimately to a Power BI report. This is useful for troubleshooting, governance, auditing, and impact analysis.

Remember:

Source

Pipeline

Lakehouse

Warehouse

Power BI

= LINEAGE

32. Interview question — Classification vs Sensitivity Label

Classification identifies what kind of information the data contains, such as an email address or financial information. A sensitivity label indicates how sensitive the information is and can be associated with protection and governance policies, such as Confidential or Highly Confidential.

33. Quick revision

MICROSOFT PURVIEW
================================
             DATA ESTATE
                  │
                  ▼
           MICROSOFT PURVIEW
                  │
       ┌──────────┼──────────┐
       │          │          │
       ▼          ▼          ▼
    DISCOVER    GOVERN     PROTECT
       │          │          │
       ▼          ▼          ▼

Catalog Lineage Sensitivity

    Metadata    Owners    Classification
       │          │          │
       └──────────┼──────────┘
                  ▼

TRUSTED DATA

One diagram to remember

                  MICROSOFT FABRIC
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
    Lakehouse         Warehouse        Eventhouse
       │                 │                 │
       └─────────────────┼─────────────────┘
                         ▼
                     Power BI
                         │
                         ▼
               MICROSOFT PURVIEW
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
       CATALOG         LINEAGE      CLASSIFICATION
          │              │              │
     Find Data       Track Data     Identify Data
          │              │              │
          └──────────────┼──────────────┘
                         ▼

DATA GOVERNANCE

The easiest way to remember Purview

Ask these five questions:

1. What data do we have? → Catalog 2. Where is it? → Discovery 3. What does it contain? → Classification 4. Where did it come from and where does it go? → Lineage 5. How sensitive is it/how should it be protected? → Sensitivity & protection

For a Microsoft Fabric Data Engineer, the three Purview concepts I would learn first are:

Data Catalog + Data Classification + Data Lineage

Once these three are clear, the rest of Fabric governance becomes much easier to understand.

↑ Back to top
Module 9 · Lesson 9.2

Module 9 · Lesson 9.2

Sensitivity Labels

Sensitivity Labels in Microsoft Fabric

Sensitivity Labels are used to classify and help protect data based on how sensitive it is.

In Microsoft Fabric, sensitivity labels are part of the integration with Microsoft Purview Information Protection.

The easiest definition to remember:

A sensitivity label tells users and Microsoft services how sensitive a data asset is and can associate protection/governance policies with that classification.

For example:

Public

General

Confidential

Highly Confidential

As sensitivity increases, stronger organizational controls may be appropriate.

1. Why do we need Sensitivity Labels?

Imagine your Fabric workspace contains:

Sales Report

Customer Lakehouse

Employee Warehouse

Salary Report

Marketing Report

Financial Report

Not all of these contain equally sensitive information.

For example:

Marketing Brochure

PUBLIC

Internal Sales Report

GENERAL

Customer Information

CONFIDENTIAL

Employee Salary Data

HIGHLY CONFIDENTIAL

Without labels, users may not immediately know which data needs special handling.

Sensitivity labels provide that classification.

2. Simple example

Suppose a Warehouse contains:

EmployeeID

EmployeeName

Department

Salary

BankAccount

The table contains highly sensitive information.

You might classify the relevant Fabric item as:

Employee Warehouse
        │
        ▼

HIGHLY CONFIDENTIAL

A user viewing the item can recognize:

This data requires careful handling.

3. Sensitivity Labels come from Microsoft Purview

The relationship is:

             MICROSOFT PURVIEW
                    │
                    ▼
         Information Protection
                    │
                    ▼
           Sensitivity Labels
                    │
                    ▼
             Microsoft Fabric
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼

Lakehouse Warehouse Power BI

Organizations typically define and publish sensitivity labels through their Microsoft Purview / Microsoft 365 information-protection configuration, and supported Fabric items can use them.

4. Typical sensitivity labels

The exact labels are defined by your organization.

A common example hierarchy might be:

PUBLIC
   │
   ▼
GENERAL
   │
   ▼
CONFIDENTIAL
   │
   ▼

HIGHLY CONFIDENTIAL

Some organizations may have more detailed labels:

Public

Internal

Confidential

Confidential - Finance

Confidential - HR

Highly Confidential

Highly Confidential - Legal

So don't assume every company has exactly the same labels.

5. Public

Public means the information is intended or approved for public consumption.

Examples:

Company Website Content

Public Product Information

Published Press Release

Public Marketing Material

Conceptually:

Product Catalog

PUBLIC

Can be publicly shared

according to company policy

6. General / Internal

This could represent information intended primarily for employees.

Examples:

Internal Training Material

Internal Project Documentation

Team Meeting Notes

Internal Operational Reports

Conceptually:

Internal Sales Dashboard

GENERAL

Internal organization use

7. Confidential

Confidential data needs stronger protection.

Examples:

Customer Information

Financial Information

Business Strategy

Supplier Contracts

Non-Public Sales Information

For example:

Customer Warehouse

CONFIDENTIAL

8. Highly Confidential

This is generally used for the organization's most sensitive information.

Examples could include:

Employee Salary

Bank Information

Highly Sensitive Financial Data

Legal Documents

Strategic Acquisition Information

For example:

Payroll Warehouse

HIGHLY CONFIDENTIAL

9. Fabric example

Imagine a workspace:

Finance Workspace
│
├── Public_Product_Report
│
├── Sales_Warehouse
│
├── Customer_Lakehouse
│
├── Finance_Warehouse
└── Payroll_Report

Possible labels:

Public_Product_Report

PUBLIC

Sales_Warehouse

GENERAL

Customer_Lakehouse

CONFIDENTIAL

Finance_Warehouse

CONFIDENTIAL

Payroll_Report

HIGHLY CONFIDENTIAL

This immediately gives users information about the sensitivity of each asset.

10. Classification vs Sensitivity Label

This is an important distinction.

Suppose:

Customers

CustomerID

Name

Email

Phone

CreditCard

Purview might identify data types such as:

Email

Email Address

Phone

Phone Number

CreditCard

Credit Card Number

These are classifications.

Then the organization might label the overall asset:

Customer Data

CONFIDENTIAL

That's a sensitivity label.

Remember:

CLASSIFICATION

"What type of data is this?"

Email

Phone

Credit Card

etc.

SENSITIVITY LABEL

"How sensitive is this asset?"

Public

General

Confidential

Highly Confidential

11. Sensitivity Label vs RLS

Don't confuse sensitivity labels with Row-Level Security.

Sensitivity Label

Classifies/protects the asset according to sensitivity.

Customer Warehouse

CONFIDENTIAL

RLS

Controls which rows users can see.

India Manager

India Records Only

So:

Sensitivity Label

=

How sensitive is the data?

RLS

=

Which rows can the user see?

12. Sensitivity Label vs CLS

Similarly:

Sensitivity Label

Payroll

Highly Confidential

Column-Level Security

EmployeeID ✓

EmployeeName ✓

Department ✓

Salary ✕

BankAccount ✕

CLS directly controls access to columns.

A sensitivity label is a broader information classification/protection mechanism.

13. Sensitivity Label vs Permissions

Another very important distinction:

A label is not simply the same thing as a Fabric permission.

Suppose:

Finance Warehouse

Sensitivity:

CONFIDENTIAL

Fabric permissions determine:

Can Ravi access it?

Can John edit it?

Can Priya share it?

Sensitivity labels describe/classify the information and can participate in protection/governance policies.

Think:

PERMISSIONS
     │
     ▼

Who can access?

SENSITIVITY LABEL
     │
     ▼

How sensitive is it /

how should it be handled?

14. Sensitivity Label vs Encryption

Don't automatically assume:

Confidential Label

=

Everything encrypted in every scenario

A sensitivity label can be associated with protection policies, but the behavior depends on the organization's configuration and the particular Fabric/export scenario.

Think of the label as:

DATA
 │
 ▼
Sensitivity Classification
 │
 ▼
Policy
 │
 ▼

Protection / Governance Behavior

The specific behavior comes from policy configuration.

15. Label inheritance

An important Fabric concept is that sensitivity labels can propagate/inherit in supported scenarios.

Suppose:

Warehouse
    │
    ▼
Semantic Model
    │
    ▼

Power BI Report

If the source is sensitive, organizations don't want that sensitivity context to disappear when downstream analytical content is created.

Conceptually:

Sensitive Data

Downstream Item

Sensitivity Context

Continues through supported lineage

The exact inheritance behavior depends on the Fabric item and operation, so it should be checked for your specific scenario.

16. Why inheritance matters

Imagine:

Payroll Warehouse

HIGHLY CONFIDENTIAL

Semantic Model

Payroll Dashboard

It would be dangerous if the dashboard were treated as:

Public

just because it is a different Fabric item.

Sensitivity propagation helps maintain appropriate information classification as data moves through supported analytics workflows.

17. Export scenarios

This is one of the reasons sensitivity labels become important with Power BI/Fabric.

Imagine:

Power BI Report

Confidential

Export

Excel / PowerPoint / PDF

Depending on the organization's configuration, supported export formats and protection policies, sensitivity information/protection can follow exported content.

This helps prevent:

Sensitive Report

Export

Uncontrolled File

Accidental Sharing

18. Example: HR

Suppose HR has:

EmployeeID

EmployeeName

Department

Salary

Bonus

BankAccount

This is sensitive.

Architecture:

HR Data

Fabric Warehouse

HIGHLY CONFIDENTIAL

Semantic Model

HR Dashboard

Authorized HR Users

You might additionally use:

Permissions

RLS

Column Security

Sensitivity Labels

These controls complement each other.

19. Example: Sales

Suppose:

FactSales

DimCustomer

DimProduct

DimCustomer contains:

CustomerName

Email

Phone

Address

The Warehouse may therefore be classified:

Sales Warehouse

CONFIDENTIAL

A product-only report containing no customer information could have a different classification depending on organizational policy.

20. Example: Finance

Suppose:

Finance Warehouse

Revenue

Profit

Cost

Forecast

Budget

Bank Details

Possible policy:

Finance Warehouse

CONFIDENTIAL

Bank Details

Highly Sensitive Information

Security may then include:

Entra Groups
     +
Fabric Permissions
     +
SQL Permissions
     +
RLS / CLS
     +

Sensitivity Labels

21. End-to-end example

Imagine customer data originates in Salesforce:

Salesforce

Fabric Pipeline

Lakehouse

Warehouse

Semantic Model

Power BI Report

The data contains:

Customer Name

Email

Phone

Address

Sales

Your governance architecture could be:

Customer Data

Classification

Personal Information

Sensitivity Label

CONFIDENTIAL

Fabric Security

Authorized Users

22. Who creates Sensitivity Labels?

Normally, individual developers don't simply invent enterprise labels whenever they want.

An organization's security/compliance administrators typically define and publish labels and associated policies using Microsoft Purview.

Conceptually:

Security / Compliance Admin

Microsoft Purview

Define Labels

Publish Policies

Users / Groups

Fabric

For example:

Public

General

Confidential

Highly Confidential

become part of the organization's information-protection policy.

23. Who applies the label?

Depending on the organization's configuration and supported capabilities, labels can be applied through user actions and/or automated/default governance mechanisms.

Conceptually:

Fabric Item

Sensitivity Label

Confidential

For example, a data owner may classify an appropriate Fabric item as confidential where the policy allows.

24. Why Sensitivity Labels matter

Without labels:

Warehouse_A

Warehouse_B

Report_123

Customer_Final

Users may not know:

Which contains sensitive information?

Which can be shared?

Which requires special handling?

Which contains customer information?

With labels:

Customer Warehouse

[CONFIDENTIAL]

Payroll Report

[HIGHLY CONFIDENTIAL]

Public Product Report

[PUBLIC]

The sensitivity is much clearer.

25. Sensitivity Labels + Purview + Fabric Security

The complete picture:

               MICROSOFT PURVIEW
                       │
                       ▼
              Sensitivity Labels
                       │
                       ▼
                MICROSOFT FABRIC
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
      Lakehouse    Warehouse    Power BI
                       │
                       ▼
                 Fabric Security
                       │
         ┌─────────────┼─────────────┐
         ▼             ▼             ▼

Permissions RLS CLS

Purview helps with information governance/protection.

Fabric security controls access.

Together they provide stronger data governance.

26. Interview question — What are Sensitivity Labels?

A strong answer:

Sensitivity labels are Microsoft Purview Information Protection classifications used to identify and help protect data according to its level of sensitivity. In Microsoft Fabric, supported items can be labeled according to organizational policies—for example Public, General, Confidential, or Highly Confidential—and sensitivity can propagate through supported downstream scenarios.

27. Interview question — Classification vs Sensitivity Label

Classification identifies what type of sensitive information exists, such as an email address, phone number, or financial information. A sensitivity label indicates the sensitivity level and handling requirements of the data asset, such as Confidential or Highly Confidential.

Easy memory:

Classification

WHAT DATA?

Sensitivity

HOW SENSITIVE?

28. Interview question — Sensitivity Label vs RLS

A sensitivity label classifies an item according to its sensitivity and can be associated with information-protection policies, while Row-Level Security controls which individual rows a user is allowed to access. They solve different problems and can be used together.

29. Interview question — Why are labels important in Fabric?

Sensitivity labels help organizations consistently identify and protect sensitive information across Fabric analytics workloads. They provide users with visible sensitivity context and can participate in governance, inheritance, and protection policies as data moves through supported Fabric and Power BI scenarios.

30. Quick revision

SENSITIVITY LABELS
================================

Part of:

Microsoft Purview

Information Protection

Purpose:

Classify & help protect

sensitive information

Example Labels:
----------------

Public

General

Confidential

Highly Confidential

Works with:
-----------

Fabric

Power BI

Purview Policies

Important Concepts:
-------------------

Classification

Sensitivity

Inheritance

Protection

Governance

Compliance

One diagram to remember

                    DATA
                      │
                      ▼
              MICROSOFT PURVIEW
                      │
                      ▼
              CLASSIFICATION
                      │
                      ▼
             SENSITIVITY LABEL
                      │
         ┌────────────┼────────────┐
         ▼            ▼            ▼

PUBLIC CONFIDENTIAL HIGHLY

                               CONFIDENTIAL
                      │
                      ▼
               MICROSOFT FABRIC
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
      Lakehouse   Warehouse    Power BI
                      │
                      ▼
              GOVERN / PROTECT
                      │
                      ▼

AUTHORIZED USERS

The easiest way to remember

Think of a file cabinet:

Classification: "This document contains employee salary information." Sensitivity label: "Highly Confidential." Permissions: "Only HR managers can open it." RLS: "Each manager sees only employees in their region." CLS: "Some users cannot see the Salary column."

So the one line to memorize is:

Sensitivity Label = How sensitive is this data, and how should it be handled/protected according to organizational policy?

↑ Back to top
Module 9 · Lesson 9.4

Module 9 · Lesson 9.3

Row-Level Security

Row-Level Security (RLS) in Microsoft Fabric

Row-Level Security (RLS) is a security mechanism that controls which rows of data a user is allowed to see.

The easiest definition to remember:

RLS = Same table + Different users + Different rows

For example, suppose one Sales table contains data for India, USA, and UK.

Sales
────────────────────────

Region SalesAmount

India 100,000

USA 200,000

UK 150,000

India 120,000

USA 180,000

We want:

India Manager

India rows only

USA Manager

USA rows only

Global Manager

All rows

That is Row-Level Security.

1. Why do we need RLS?

Imagine your company operates in:

India

USA

UK

Germany

Australia

All sales are stored in one table:

FACT_SALES

containing:

SalesID

DateKey

CustomerKey

ProductKey

Region

SalesAmount

Without RLS, if a user has access to the table, they could potentially see:

FACT_SALES

India Manager
      │
      ▼
┌─────────────────────────┐
│ India       ₹10M        │
│ USA         ₹20M        │
│ UK          ₹15M        │
│ Germany     ₹12M        │
│ Australia   ₹8M         │
└─────────────────────────┘

But the requirement might be:

India managers should see only India sales.

RLS solves this.

2. How RLS works

Conceptually:

                  FACT_SALES
                      │
        ┌─────────────┼─────────────┐
        │             │             │
        ▼             ▼             ▼
      India          USA           UK
        │             │             │
        ▼             ▼             ▼

India Manager USA Manager UK Manager

Users can query the same underlying table, but security predicates restrict the rows returned.

3. Simple example

Table:

SalesIDRegionProductSalesAmount
1IndiaLaptop100000
2USALaptop150000
3IndiaMobile50000
4UKLaptop120000
5USAMobile80000

India Manager sees

SalesIDRegionProductSalesAmount
1IndiaLaptop100000
3IndiaMobile50000

USA Manager sees

SalesIDRegionProductSalesAmount
2USALaptop150000
5USAMobile80000

Same table.

Different results.

India Manager
     │
     ▼

SELECT * FROM Sales

     │
     ▼

India Rows

USA Manager
     │
     ▼

SELECT * FROM Sales

     │
     ▼

USA Rows

4. RLS is automatic for the user

This is an important concept.

The India manager doesn't need to remember:

WHERE Region = 'India'

They might simply execute:

SELECT *

FROM FactSales;

The security policy applies the appropriate restriction.

Conceptually:

User Query
    │
    ▼

SELECT * FROM FactSales

    │
    ▼
Security Policy
    │
    ▼

Who is the user?

    │
    ▼
India Manager
    │
    ▼

Region = India

    │
    ▼

Return India rows

5. Static vs Dynamic RLS

There are two useful ways to understand RLS:

RLS
 │
 ├── Static RLS
 │
 └── Dynamic RLS

6. Static RLS

With static RLS, a security rule is tied to a predefined condition/group.

For example:

India Managers

Region = India

and:

USA Managers

Region = USA

Conceptually:

Role / Group
      │
      ▼
Fixed Filter
      │
      ▼
Region = 'India'

This can work well when you have a small number of predictable security groups.

7. Dynamic RLS

Dynamic RLS is more scalable when many users need different access.

Instead of creating:

India Role

USA Role

UK Role

Germany Role

Australia Role

...

you maintain a mapping table.

For example:

UserSecurity

UserEmailRegion
ravi@company.comIndia
john@company.comUSA
david@company.comUK
priya@company.comIndia

Then:

Logged-in User

Find User in Security Table

Find Allowed Region

Filter Data

8. Dynamic RLS example

Suppose Ravi signs in:

ravi@company.com

Security mapping:

ravi@company.com

India

Then:

FactSales
    │
    ▼

Region = India

Ravi sees only:

India Sales

John signs in:

john@company.com

USA

and receives:

USA Sales

This is much easier to manage for hundreds or thousands of users.

9. One user can have multiple regions

Your mapping table can contain multiple records for the same user.

For example:

UserEmailRegion
ravi@company.comIndia
ravi@company.comSingapore
john@company.comUSA
john@company.comCanada

Now Ravi can see:

India
  +

Singapore

while John can see:

USA
  +

Canada

Conceptually:

Ravi
 │
 ├── India
 └── Singapore
      │
      ▼

FactSales

10. RLS in a Star Schema

RLS becomes especially interesting with a Star Schema.

Suppose:

                    DIM_DATE
                       │
                       │
                       ▼
DIM_CUSTOMER ─────► FACT_SALES ◄──── DIM_PRODUCT
                       ▲
                       │
                       │

DIM_REGION

DIM_REGION contains:

RegionKey

RegionName

And:

FACT_SALES

contains:

RegionKey

You can design security around the region dimension so that filtering propagates to related sales data.

11. Example Star Schema security

Suppose:

DIM_REGION

RegionKey | Region

----------|--------

1 | India

2 | USA

3 | UK

and:

FACT_SALES

SalesID | RegionKey | Amount

--------|-----------|-------

101 | 1 | 5000

102 | 2 | 7000

103 | 1 | 9000

104 | 3 | 6000

India manager:

India Manager

DIM_REGION

RegionKey = 1

FACT_SALES

India Sales

This is a common BI security design.

12. RLS in Fabric Warehouse

Fabric Warehouse supports SQL-based security capabilities, including RLS scenarios.

At a conceptual level, SQL RLS commonly uses:

Security Predicate
       +

Security Policy

Architecture:

User
 │
 ▼
Warehouse
 │
 ▼
Security Policy
 │
 ▼
Predicate Function
 │
 ▼

Allowed Rows

The implementation should be tested against the current Fabric Warehouse T-SQL support because Fabric's supported SQL surface evolves.

13. Simplified SQL concept

A simplified SQL RLS design might use a predicate function:

CREATE FUNCTION Security.fn_securitypredicate

(

@Region VARCHAR(50)

)

RETURNS TABLE

WITH SCHEMABINDING

AS

RETURN

(

    SELECT 1 AS AccessResult
    WHERE @Region = 'India'

);

Then a security policy associates the predicate with the table.

Conceptually:

FactSales
    │
    ▼
Security Predicate
    │
    ▼

Allowed?

/ \

 YES  NO
  │    │

Return Hide

For actual Fabric implementation, always verify the supported syntax and identity functions for your Warehouse environment.

14. RLS in Power BI

RLS is also widely used in Power BI semantic models.

Architecture:

Fabric Warehouse

Semantic Model

RLS

Power BI Report

User

For example:

Same Power BI Report
         │
    ┌────┼────┐
    ▼    ▼    ▼

India USA UK

Manager Manager Manager
    │    │    │

India USA UK

Data Data Data

One report can serve many users.

15. Example DAX RLS

Suppose the semantic model has:

DimRegion

You could define a role filter conceptually as:

DimRegion[Region] = "India"

Then users assigned to that role see only India-related data.

For dynamic RLS, user identity functions and a user-access mapping table are commonly used.

16. Why dynamic RLS is powerful

Imagine your company has:

5 Countries

20 Regions

200 Managers

5,000 Salespeople

Creating thousands of individual security rules would be difficult.

Instead:

UserSecurity
     │
     ▼
User → Region Mapping
     │
     ▼

Dynamic RLS

Then adding a new employee might only require updating the security mapping rather than redesigning the entire report.

17. RLS vs Column-Level Security

This is an important interview question.

RLS

Controls rows.

Employee | Region | Salary

---------|--------|-------

Ravi | India | 100K ✓

John | USA | 120K ✕

David | UK | 110K ✕

India manager sees only Ravi's row.

CLS

Controls columns.

Employee ✓

Region ✓

Salary ✕

The user may see records but cannot access the sensitive Salary column.

Remember:

RLS = Which rows?

CLS = Which columns?

18. RLS vs Sensitivity Labels

You just studied Sensitivity Labels, so this distinction is important.

Sensitivity Label

Answers:

How sensitive is this data?

Employee Warehouse

HIGHLY CONFIDENTIAL

RLS

Answers:

Which records can this user see?

India Manager

India Employee Records

So:

Sensitivity

=

CLASSIFY

RLS

=

FILTER

19. RLS vs Workspace Roles

Workspace roles control broader Fabric access.

For example:

Admin

Member

Contributor

Viewer

RLS works at the data level.

For example:

Viewer
   │
   ▼
Can access report
   │
   ▼
RLS
   │
   ▼

Can see India data only

Therefore:

Workspace Role = Can you access/work with the Fabric content?

RLS = Which rows can you see inside the data?

20. RLS vs SQL WHERE clause

This is another useful distinction.

Normal SQL:

SELECT *
FROM FactSales
WHERE Region = 'India';

The developer/user wrote the filter.

With RLS:

SELECT *

FROM FactSales;

Security automatically restricts the result based on the user's security context.

Think:

WHERE Clause
    =

Query Logic

RLS

=

Security Logic

You should not rely on users remembering to add WHERE Region = 'India' for security.

21. Real-world example: Regional Sales

Company operates in:

India

USA

UK

Germany

Requirement:

India Manager

India

USA Manager

USA

Europe Director

UK + Germany

Global CEO

All Regions

Mapping table:

UserRegion
IndiaManagerIndia
USAManagerUSA
EuropeDirectorUK
EuropeDirectorGermany

Architecture:

User

Security Mapping

Allowed Regions

DimRegion

FactSales

Power BI

22. Real-world example: HR

Suppose:

Employee Table

EmployeeID

Name

Manager

Department

Salary

Requirement:

Employee

Own information

Manager

Their employees

HR

All employees

This can become a more advanced RLS scenario involving organizational hierarchy.

HR Director
     │
     ▼

All Employees

Manager
     │
     ▼

Team Members

Employee
     │
     ▼

Own Record

23. Real-world example: Multi-tenant application

Imagine your company provides analytics to 100 customers.

All data is stored in:

FactUsage

with:

TenantID

UserID

Usage

Date

Customer A must never see Customer B's data.

Customer A

TenantID = A

Customer B

TenantID = B

This is another strong RLS use case.

24. Where should RLS be implemented?

In a Fabric solution, security could exist at multiple layers:

Data Source

Warehouse

Semantic Model

Power BI

You should decide where enforcement belongs based on how users access the data.

For example, if users can directly query the Warehouse:

User

Warehouse

semantic-model-only RLS won't protect direct Warehouse queries.

This is extremely important.

25. Warehouse RLS vs Power BI RLS

Think about this architecture:

                 FACT_SALES
                     │
                     ▼
             FABRIC WAREHOUSE
                     │
                     ▼
              SEMANTIC MODEL
                     │
                     ▼

POWER BI

Warehouse RLS

Security is closer to the data.

User

Warehouse

Filtered Data

Power BI RLS

Security is applied through the semantic model.

User

Power BI

Semantic Model

RLS

Filtered Data

The correct choice depends on your architecture and access paths.

Sometimes security is needed at more than one layer.

26. RLS doesn't replace permissions

Suppose a user has no permission to access a Warehouse.

RLS isn't intended to magically grant that access.

Think of the sequence as:

USER

Authentication

Does user have access?

YES

RLS

Which rows?

So:

Permissions

=

Can you enter?

RLS

=

What can you see after entering?

27. Security architecture

Combine the topics you've learned:

                     USER
                       │
                       ▼
               Microsoft Entra ID
                       │
                       ▼
                Authentication
                       │
                       ▼
                Fabric Workspace
                       │
                       ▼
                  Permissions
                       │
                       ▼
                   Warehouse
                       │
              ┌────────┼────────┐
              ▼        ▼        ▼
             RLS      CLS     Masking
              │        │        │
            Rows    Columns   Values
                       │
                       ▼
              Sensitivity Labels
                       │
                       ▼

Governance

Each layer solves a different security problem.

28. Best practices

For RLS design, remember these principles:

Use security groups/mapping tables instead of maintaining large numbers of users manually.

Prefer dynamic RLS when many users require different data access.

Keep security logic as simple as practical.

Use stable business/security keys such as RegionID rather than relying only on descriptive text.

Test RLS with multiple user personas before production.

Remember all access paths—Power BI RLS doesn't automatically secure someone directly querying the underlying Warehouse.

Follow least privilege and combine RLS with appropriate Fabric/SQL permissions.

29. Interview question — What is Row-Level Security?

A strong answer:

Row-Level Security is a data-security mechanism that restricts which rows a user can access based on their identity or security context. For example, the same FactSales table can allow an India manager to see only India sales while a USA manager sees only USA sales. In Fabric solutions, RLS can be implemented at appropriate data or semantic-model layers depending on how the data is accessed.

30. Interview question — Static vs Dynamic RLS

Static RLS uses predefined filters or roles, such as an India role that always filters Region to India. Dynamic RLS determines the filter based on the logged-in user's identity, typically using a user-to-region or user-to-entity mapping table. Dynamic RLS is generally more scalable when many users require different access.

31. Interview question — RLS vs CLS

RLS controls which rows a user can see, while Column-Level Security controls which columns a user can access. For example, RLS could restrict a manager to India employees, while CLS could prevent the manager from seeing the Salary column.

32. Quick revision

ROW-LEVEL SECURITY
=================================

Purpose:

Restrict Rows

Example:
-----------------

India Manager

India Rows

USA Manager

USA Rows

Global Manager

All Rows

Types:
-----------------

Static RLS

Dynamic RLS

Dynamic RLS:
-----------------

Logged-in User

Security Mapping

Allowed Region

Filter Data

One diagram to remember

                    FACT_SALES
                        │
           ┌────────────┼────────────┐
           │            │            │
           ▼            ▼            ▼
         INDIA         USA           UK
           │            │            │
           │            │            │
    ┌──────▼─────┐ ┌────▼─────┐ ┌────▼─────┐
    │   INDIA    │ │   USA    │ │    UK    │
    │  MANAGER   │ │ MANAGER  │ │ MANAGER  │
    └────────────┘ └──────────┘ └──────────┘
          SAME TABLE
              +
       DIFFERENT USERS
              +

DIFFERENT ROWS

=

RLS

The one line to memorize

RLS answers: "Which rows is this user allowed to see?"

And keep this security comparison in mind:

Workspace Role → Can I access the Fabric content?

SQL Permission → What operations can I perform?

RLS → Which rows can I see?

CLS → Which columns can I see?

Sensitivity Label → How sensitive is the data?

Purview → How do we discover, classify, govern and protect it?

↑ Back to top
Module 9 · Lesson 9.6

Module 9 · Lesson 9.4

Object-Level Security

Object-Level Security (OLS) in Microsoft Fabric

Object-Level Security (OLS) controls whether a user can access specific objects, particularly tables or columns in a semantic model.

The easiest definition to remember:

OLS = Hide or restrict entire tables or columns from particular users.

For example, suppose an HR semantic model contains:

Employee
│
├── EmployeeID
├── EmployeeName
├── Department
├── Salary
├── Bonus
└── BankAccount

A normal manager might be allowed to access:

EmployeeID ✓

EmployeeName ✓

Department ✓

Salary ✕

Bonus ✕

BankAccount ✕

With OLS, the restricted objects aren't simply filtered like RLS—the user is prevented from accessing those secured model objects.

1. First understand what an "Object" means

In this context, think mainly about semantic-model objects such as:

Semantic Model
     │
     ├── Tables
     │
     └── Columns

For example:

Sales Semantic Model
│
├── FactSales
├── DimCustomer
├── DimProduct
├── DimEmployee
└── EmployeeSalary

Maybe a Sales Analyst should access:

FactSales ✓

DimCustomer ✓

DimProduct ✓

DimEmployee ✕

EmployeeSalary ✕

This is where Object-Level Security becomes useful.

2. Why do we need OLS?

Imagine you have one Power BI/Fabric semantic model used by:

Sales Team

Finance Team

HR Team

Management

The model contains:

Enterprise Semantic Model
│
├── FactSales
├── DimCustomer
├── DimProduct
├── Employee
├── EmployeeSalary
└── FinancialForecast

Not everyone should see every object.

For example:

ObjectSalesFinanceHR
FactSales
DimCustomer
FinancialForecast
Employee
EmployeeSalary

OLS can enforce this separation.

3. RLS vs OLS

This is the most important distinction.

Row-Level Security — RLS

Controls rows.

Suppose:

RegionSales
India100000
USA200000
UK150000

RLS:

India Manager

India row only

The table still exists for the user, but its accessible rows are filtered.

Object-Level Security — OLS

Controls objects.

Semantic Model
│
├── FactSales           ✓
├── DimCustomer         ✓
├── EmployeeSalary      ✕
└── FinancialForecast   ✕

The secured objects aren't available to that role/user.

Easy memory:

RLS = Which rows? OLS = Which tables/columns?

4. Simple OLS example

Suppose:

Employee
────────────────────────

EmployeeID

EmployeeName

Department

Salary

BankAccount

HR users:

EmployeeID ✓

EmployeeName ✓

Department ✓

Salary ✓

BankAccount ✓

Managers:

EmployeeID ✓

EmployeeName ✓

Department ✓

Salary ✕

BankAccount ✕

Here OLS can restrict:

Salary

BankAccount

for the manager role.

5. Table-Level OLS

OLS can secure an entire table.

Suppose:

Finance Semantic Model
│
├── FactSales
├── DimCustomer
├── DimProduct
├── FinancialForecast
└── ExecutiveBudget

Business users should not access:

ExecutiveBudget

Conceptually:

Business User
     │
     ▼
Semantic Model
     │
     ├── FactSales          ✓
     ├── DimCustomer        ✓
     ├── DimProduct         ✓
     ├── FinancialForecast  ✓
     │
     └── ExecutiveBudget    ✕

The whole table is protected from that role.

6. Column-Level OLS

You can also secure particular columns.

Suppose:

DimEmployee
│
├── EmployeeID
├── EmployeeName
├── Department
├── Email
├── Salary
└── BankAccount

A manager needs:

EmployeeID

EmployeeName

Department

but should not access:

Salary

BankAccount

Conceptually:

DimEmployee

EmployeeID ✓

EmployeeName ✓

Department ✓

Email ✓

Salary 🔒

BankAccount 🔒

7. OLS is stronger than simply hiding a column

This is extremely important.

In Power BI, you can simply hide a column from report view.

For example:

Salary

Hide in report view

But:

Hidden does not mean secured.

Hiding is primarily for model/report usability.

Security requires an actual security mechanism such as OLS.

Think:

HIDDEN COLUMN
     │
     ▼

Don't normally show it

to report creators

OLS
     │
     ▼

User/role is not

allowed to access it

8. OLS works with roles

OLS is commonly defined through semantic-model roles.

For example:

Semantic Model
      │
      ├── Sales Role
      ├── Finance Role
      └── HR Role

Then:

Sales Role

EmployeeSalary

DENIED

while:

HR Role

EmployeeSalary

ALLOWED

9. Real-world HR example

Suppose:

HR Semantic Model
│
├── Employee
├── Department
├── Attendance
├── Performance
├── Salary
└── BankDetails

HR Team

Employee ✓

Department ✓

Attendance ✓

Performance ✓

Salary ✓

BankDetails ✓

Department Manager

Employee ✓

Department ✓

Attendance ✓

Performance ✓

Salary ✕

BankDetails ✕

Regular Employee

Employee Limited

Department ✓

Attendance Limited

Performance Limited

Salary ✕

BankDetails ✕

This could involve a combination of RLS and OLS.

10. RLS + OLS together

This is a very common enterprise pattern.

Suppose the model contains:

Employee

EmployeeID

Name

Region

Department

Salary

BankAccount

India Manager should see:

Rows

Only:

Region = India

That's RLS.

Columns

They should not access:

Salary

BankAccount

That's OLS.

Architecture:

                 Employee
                     │
          ┌──────────┴──────────┐
          ▼                     ▼
         RLS                   OLS
          │                     │

Region = India Salary ✕

BankAccount ✕

So the same model can use both.

11. RLS + OLS example

Original table:

EmployeeRegionDepartmentSalaryBankAccount
RaviIndiaSales100000XXXX1
JohnUSASales120000XXXX2
PriyaIndiaIT110000XXXX3
DavidUKIT130000XXXX4

India Manager has:

RLS:

Region = India

OLS:

Salary DENIED

BankAccount DENIED

Conceptually, the manager can work with:

EmployeeRegionDepartment
RaviIndiaSales
PriyaIndiaIT

So:

RLS removed:

John

David

OLS protected:

Salary

BankAccount

12. OLS vs Column-Level Security

This terminology can sometimes become confusing.

In a Power BI/Fabric semantic model, OLS is the mechanism used to secure model objects such as tables and columns.

In a SQL Warehouse/database, you may instead use SQL object/column permissions.

For example:

GRANT SELECT ON dbo.Employee TO [Analyst];

or use more granular database permissions as supported.

Therefore, always ask:

At which layer am I implementing security?

Fabric Warehouse
       │
       ▼

SQL Security

Semantic Model
       │
       ▼

RLS / OLS

Power BI Report
       │
       ▼

Consumption

13. Warehouse Security vs Semantic Model Security

This distinction is very important for Fabric.

                  USER
                    │
                    ▼
             POWER BI REPORT
                    │
                    ▼
              SEMANTIC MODEL
                    │
              ┌─────┴─────┐
              ▼           ▼
             RLS         OLS
                    │
                    ▼
             FABRIC WAREHOUSE
                    │
                    ▼

SQL SECURITY

Semantic-model OLS does not automatically mean the underlying Warehouse is protected from a user who separately has direct Warehouse permissions.

You must secure each relevant access path.

14. OLS vs Sensitivity Labels

You recently learned Sensitivity Labels.

These solve different problems.

Sensitivity Label

Answers:

How sensitive is this data?

Employee Salary Model

HIGHLY CONFIDENTIAL

OLS

Answers:

Which tables or columns can this user access?

Manager

Salary Column

DENIED

Remember:

Sensitivity Label

=

CLASSIFY / PROTECT

OLS

=

RESTRICT OBJECTS

15. OLS vs Workspace Permissions

Workspace permissions determine broader access to Fabric content.

Workspace
│
├── Admin
├── Member
├── Contributor
└── Viewer

OLS operates inside the semantic model.

For example:

User

Can access Report

Semantic Model

OLS

Cannot access Salary object

Think:

Workspace permission = Can I access/use the Fabric item?

OLS = Which model objects am I allowed to access?

16. OLS vs RLS vs Sensitivity

This table is worth memorizing:

SecurityControlsExample
RLSRowsIndia data only
OLSTables/columnsHide Salary table/column securely
Sensitivity LabelData classification/protectionConfidential
Workspace RoleWorkspace capabilitiesViewer
SQL PermissionDatabase operations/objectsSELECT
PurviewGovernanceCatalog, lineage, classification

17. Practical example: Sales model

Suppose:

Sales Semantic Model
│
├── FactSales
├── DimCustomer
├── DimProduct
├── DimRegion
├── ProductCost
└── ProfitMargin

Sales representatives should see:

FactSales ✓

DimCustomer ✓

DimProduct ✓

DimRegion ✓

ProductCost ✕

ProfitMargin ✕

Management should see everything.

Sales Rep
   │
   ▼
OLS
   │
   ├── ProductCost   🔒
   └── ProfitMargin  🔒
Management
   │
   ▼

All Objects

18. Practical example: Finance

Model:

Finance Model
│
├── Revenue
├── Expenses
├── Budget
├── Forecast
├── EmployeeSalary
└── ExecutiveCompensation

Finance analyst:

Revenue ✓

Expenses ✓

Budget ✓

Forecast ✓

EmployeeSalary ✕

ExecutiveCompensation ✕

Finance director:

Everything ✓

OLS provides object-level separation while allowing teams to use the same broader model where appropriate.

19. Why OLS is useful

Without OLS, you might create separate semantic models:

Sales_Model

Finance_Model

HR_Model

Manager_Model

Executive_Model

That can lead to:

Duplicate Models

Duplicate Measures

Duplicate Maintenance

More Complexity

In appropriate scenarios, OLS allows:

One Semantic Model
       │
       ├── Sales Role
       ├── Finance Role
       ├── HR Role
       └── Executive Role

with different object visibility/security.

20. Important limitation to understand

OLS is not a substitute for securing the source.

Suppose:

Warehouse

Semantic Model

OLS

Power BI

OLS protects the semantic-model access path.

But if a user has:

Direct Warehouse Access

they may query the source according to their Warehouse permissions.

Therefore enterprise security should be designed end-to-end:

Entra ID

Fabric Permissions

Warehouse Security

Semantic Model Security

RLS / OLS

Sensitivity Labels

Power BI

21. Interview question — What is OLS?

A strong answer:

Object-Level Security is a semantic-model security mechanism that restricts access to specific model objects, such as tables or columns, for particular roles. For example, an HR role might access an EmployeeSalary table while a Sales role is prevented from accessing that table.

22. Interview question — RLS vs OLS

A strong answer:

Row-Level Security controls which rows a user can see, while Object-Level Security controls whether the user can access specific tables or columns in the semantic model. For example, RLS could restrict a manager to India employees, while OLS could prevent that manager from accessing the Salary column.

Easy memory:

RLS

ROWS

OLS

OBJECTS

Tables / Columns

23. Interview question — Hiding vs OLS

Hiding a table or column in a semantic model is primarily a usability/modeling feature and should not be treated as security. OLS actually restricts access to the secured model object for the applicable role.

Remember:

Hide

=

User Experience

OLS

=

Security

24. Interview question — Can RLS and OLS work together?

Yes.

For example:

India Manager
      │
      ├── RLS
      │     ↓
      │  India employees only
      │
      └── OLS

Salary column denied

They solve different security requirements and can complement each other.

25. Complete Fabric security picture

You've now covered several related concepts. Put them together like this:

                        USER
                          │
                          ▼
                 MICROSOFT ENTRA ID
                          │
                          ▼
                  FABRIC WORKSPACE
                          │
                   Workspace Roles
                          │
                          ▼
                     FABRIC ITEM
                          │
                          ▼
                 FABRIC WAREHOUSE
                          │
                    SQL Security
                          │
                          ▼
                   SEMANTIC MODEL
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
            RLS          OLS      Sensitivity
             │            │          Labels
             ▼            ▼            ▼
           ROWS      TABLES/COLUMNS  CLASSIFY
                          │
                          ▼

POWER BI REPORT

Quick revision

OBJECT-LEVEL SECURITY
================================

OLS = Secure model objects

Main objects:
----------------

Tables

Columns

Example:
----------------

Sales Analyst

FactSales ✓

DimCustomer ✓

DimProduct ✓

EmployeeSalary ✕

BankAccount ✕

Comparison:
----------------

RLS → Rows

OLS → Tables / Columns

Sensitivity → Classification

Permissions → Access

Purview → Governance

The easiest way to remember

Imagine an Excel sheet:

Name | Region | Department | Salary

If you say:

"Sreehari can see only India employees."

That's RLS — restricting rows.

If you say:

"Sreehari can see employees but cannot access the Salary column."

That's OLS — restricting a model object/column.

If you say:

"This dataset is Confidential."

That's a Sensitivity Label.

So memorize:

RLS = Which rows? OLS = Which tables/columns? Sensitivity Label = How sensitive?

↑ Back to top
Module 9 · Lesson 9.5

Workspace Roles

Workspace Roles in Microsoft Fabric

Workspace Roles in Microsoft Fabric control what a user can do inside a Fabric workspace.

The four main workspace roles are:

Admin → Member → Contributor → Viewer

The easiest way to remember them:

ADMIN

Full workspace management

MEMBER

Manage and collaborate

CONTRIBUTOR

Create and modify content

VIEWER

View and consume content

1. First, what is a Workspace?

A workspace is a collaborative container where Fabric items are created and managed.

For example:

Sales Workspace
│
├── Lakehouse
│
├── Warehouse
│
├── Data Pipeline
│
├── Dataflow Gen2
│
├── Notebook
│
├── Semantic Model
└── Power BI Report

Suppose your team contains:

Fabric Administrator

Data Engineer

Data Analyst

Business User

You don't want everyone to have the same level of access.

That's why we have Workspace Roles.

2. The four Workspace Roles

              FABRIC WORKSPACE
                     │
       ┌─────────────┼─────────────┐
       │             │             │
       ▼             ▼             ▼
     ADMIN         MEMBER      CONTRIBUTOR
                                     │
                                     ▼

VIEWER

Think of them as progressively different levels of workspace capability rather than database permissions.

3. Admin

Admin has the highest level of control over the workspace.

Think:

Admin = Workspace administrator

An Admin can perform broad workspace-management activities, including managing access and workspace settings as permitted by Fabric.

Conceptually:

Admin
  │
  ├── Manage workspace
  ├── Manage users/access
  ├── Manage workspace settings
  ├── Create items
  ├── Modify items
  ├── Delete items
  └── Manage workspace content

Example:

Production Fabric Workspace
          │
          ▼

Fabric Admin

You should keep the number of Admins limited.

4. Member

Member is a highly privileged collaboration role, but it isn't the same as Admin.

Think:

Member = Senior workspace collaborator

A Member can generally collaborate extensively with workspace content and perform broader content-management/sharing activities than a Contributor.

Conceptually:

Member
  │
  ├── View content
  ├── Create content
  ├── Modify content
  ├── Delete/manage content
  └── Collaborate/share where permitted

For example:

Data Platform Lead

Member

5. Contributor

This is a very important role for Data Engineers and Developers.

Think:

Contributor = Build and modify Fabric content

A Contributor can generally create and modify workspace items.

For example:

Data Engineer

Contributor

Create Pipeline

Create Lakehouse

Create Notebook

Modify Pipeline

Develop Data Solution

But a Contributor does not have the same workspace-administration capabilities as an Admin.

6. Viewer

Viewer is primarily for users who need to consume existing content.

Think:

Viewer = Read/consume

For example:

Business User

Viewer

View Reports

Consume Content

They shouldn't normally be building, editing, or deleting workspace content.

7. Simple comparison

CapabilityAdminMemberContributorViewer
View workspace content
Create Fabric items
Modify workspace items
Delete/manage content
Broad collaborationLimited compared with Member
Manage workspace accessHighestSome delegated capabilities depending on settings
Workspace administration

The exact capabilities can vary by Fabric item and tenant/workspace configuration, so for production security design you should verify Microsoft's current role-permission matrix.

8. Easy real-world analogy

Imagine a company office.

Admin = Office Owner/Administrator

Admin

Controls Office

Controls Access

Controls Configuration

Member = Senior Team Member

Member

Works with everything

Collaborates

Manages content

Contributor = Employee/Developer

Contributor

Creates work

Updates work

Develops solutions

Viewer = Visitor/Consumer

Viewer

Can see permitted content

Cannot modify it

9. Fabric example

Suppose we have:

Sales Analytics Workspace
│
├── Sales_Lakehouse
├── Sales_Warehouse
├── Sales_Pipeline
├── Sales_Notebook
├── Sales_SemanticModel
└── Sales_Report

Team:

Sreehari → Data Engineer

John → Fabric Administrator

Priya → Business Analyst

David → Sales Manager

A possible design:

John

Admin

Sreehari

Contributor

Priya

Contributor / Member

depending on responsibilities

David

Viewer

The important point is to assign the least privileged role that still allows the person to do their job.

10. Data Engineer example

A Fabric Data Engineer may need to:

Create Lakehouse

Create Warehouse

Create Pipeline

Create Notebook

Create Dataflow

Modify ETL logic

Run Pipelines

They may not need to:

Manage Workspace Users

Change Workspace Administration

Control All Workspace Settings

Therefore:

Data Engineer

Contributor

can often be a suitable starting role.

Don't automatically give every developer Admin.

11. Business user example

Suppose a Sales Manager only needs:

View Sales Dashboard

View Reports

Analyze Sales

They don't need:

Create Lakehouse

Delete Warehouse

Modify Pipeline

Edit Notebook

Therefore:

Sales Manager

Viewer

is much more appropriate than Admin.

12. Admin vs Member

This is a common interview question.

Admin

Focused on:

Workspace Administration
        +
Access Management
        +
Workspace Settings
        +

Content Management

Member

Focused on:

Collaboration
      +
Content Management
      +

Broader workspace participation

Easy memory:

Admin = Manage the workspace itself

Member = Collaborate/manage content within the workspace

13. Member vs Contributor

This is where many beginners get confused.

Both can work with content.

But think:

MEMBER

Senior collaboration
      +
Content management
      +

More sharing/management capability

versus:

CONTRIBUTOR

Build
  +
Develop
  +

Modify content

Simple example:

Team Lead

Member

Data Engineer

Contributor

This isn't a mandatory rule—it's just an easy way to understand the difference.

14. Contributor vs Viewer

This distinction is straightforward.

Contributor

Create

Edit

Develop

Modify

Viewer

View

Consume

Read

Think:

Contributor

BUILDER

Viewer

CONSUMER

15. Workspace Role vs Item Permission

This is extremely important.

A Workspace Role gives broader access within the workspace.

Workspace
│
├── Lakehouse
├── Warehouse
├── Pipeline
├── Notebook
└── Report

But sometimes you only want to give a person access to a specific item.

For example:

Finance Workspace
│
├── Finance_Warehouse     ✕
├── Finance_Lakehouse     ✕
├── Finance_Pipeline      ✕
│
└── Finance_Report        ✓

You don't necessarily want to make that user a broad workspace collaborator.

Instead, use appropriate item/report sharing and permissions.

Think:

Workspace Role = Broad workspace access

Item Permission = Access to a particular item

16. Workspace Role vs SQL Permission

Suppose:

Sales Workspace

Sales Warehouse

FactSales

Workspace role answers:

What can this user do in the Fabric workspace?

SQL permissions answer:

What can this user do with Warehouse objects/data?

For example:

GRANT SELECT ON dbo.FactSales

TO [SalesAnalyst];

So:

Workspace Role

Fabric-level capabilities

SQL Permission

Database-level capabilities

17. Workspace Role vs RLS

You recently learned Row-Level Security.

Don't confuse them.

Workspace Role

Viewer

Can consume workspace content

RLS

India Manager

Can see India rows only

Therefore:

Workspace Role = What can I do in the workspace?

RLS = Which rows can I see?

18. Workspace Role vs OLS

Similarly:

Workspace Role

Controls broader workspace capabilities.

Admin

Member

Contributor

Viewer

OLS

Controls semantic-model objects.

FactSales ✓

DimCustomer ✓

EmployeeSalary ✕

BankAccount ✕

So:

Workspace Role = Workspace-level capability

OLS = Table/column access in the semantic model

19. Workspace Role vs Sensitivity Label

These are completely different.

Workspace Role

Answers:

What can this person do?

Example:

Sreehari

Contributor

Sensitivity Label

Answers:

How sensitive is this data?

Example:

Employee Salary Report

Highly Confidential

20. Workspace Roles + RLS + OLS

They can all work together.

Imagine:

India Sales Manager

Workspace:

Viewer

Meaning:

They consume existing content.

Then RLS:

Region = India

Meaning:

They only see India records.

Then OLS:

ProductCost ✕

ProfitMargin ✕

Meaning:

They cannot access those protected model objects.

Architecture:

               India Manager
                     │
                     ▼
             WORKSPACE ROLE
                     │
                  Viewer
                     │
                     ▼
                    RLS
                     │
                India Rows
                     │
                     ▼
                    OLS
                     │

ProductCost / Margin

Restricted

21. Complete Fabric security layers

This is the diagram worth remembering:

                       USER
                         │
                         ▼
                MICROSOFT ENTRA ID
                         │
                   Authentication
                         │
                         ▼
                 FABRIC WORKSPACE
                         │
                  Workspace Role
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
        Admin          Member      Contributor
                                         │
                                         ▼
                                       Viewer
                         │
                         ▼
                   FABRIC ITEMS
                         │
              Item Permissions
                         │
                         ▼
                    WAREHOUSE
                         │
                  SQL Permissions
                         │
                         ▼
                 SEMANTIC MODEL
                         │
              ┌──────────┴──────────┐
              ▼                     ▼
             RLS                   OLS
              │                     │
             Rows             Tables/Columns
                         │
                         ▼
              Sensitivity Labels
                         │
                         ▼

Governance / Purview

22. Least Privilege Principle

This is the most important security principle.

Give users only the permissions they actually need.

Bad design:

Everyone

Admin

Better:

Fabric Administrator

Admin

Data Platform Lead

Member

Data Engineer

Contributor

Business User

Viewer

This reduces the risk of accidental or unauthorized changes.

23. DEV vs PROD

You may also assign roles differently across environments.

DEV

Developers need to build things:

Data Engineer

Contributor / Member

PROD

Developers may need more restricted access:

Data Engineer

Viewer / limited access

while deployment/service processes handle production changes.

For example:

DATA ENGINEER

DEV                         PROD
 │                            │
 ▼                            ▼
Contributor                Viewer
 │                            │

Develop Monitor

Test Consume

Modify Restricted changes

This depends on your organization's deployment and governance model.

24. Using Entra groups

In larger organizations, avoid assigning hundreds of users individually where possible.

Instead of:

Ravi → Contributor

Priya → Contributor

John → Contributor

David → Contributor

...

use groups:

Microsoft Entra ID
       │
       ▼
Fabric_Data_Engineers
       │
       ├── Ravi
       ├── Priya
       ├── John
       └── David
       │
       ▼

Contributor

Then when a new engineer joins:

New Employee

Add to Entra Group

Receives appropriate workspace access

This is much easier to manage.

25. Example enterprise setup

Suppose:

Production Sales Workspace

Groups:

Entra GroupWorkspace Role
Fabric_AdminsAdmin
Data_Platform_LeadsMember
Data_EngineersContributor
Sales_ConsumersViewer

Then additional security controls can be applied:

Sales_Consumers
       │
       ▼
Viewer
       │
       ▼
RLS
       │
       ├── India Manager → India
       ├── USA Manager   → USA
       └── UK Manager    → UK

This gives you both:

Workspace Security
        +

Data Security

26. Interview question — What are Workspace Roles?

A strong answer:

Microsoft Fabric workspace roles control what users can do within a workspace. The four main roles are Admin, Member, Contributor, and Viewer. Admin provides workspace administration capabilities, Member supports broad collaboration and content management, Contributor is typically used for creating and modifying Fabric content, and Viewer is primarily for consuming existing content.

27. Interview question — Contributor vs Viewer

A Contributor can generally create and modify Fabric items within a workspace, while a Viewer is primarily intended to view and consume existing content without making changes.

28. Interview question — Workspace Role vs RLS

Workspace roles control a user's capabilities within the Fabric workspace, while Row-Level Security controls which rows of data the user can see. For example, a Sales Manager might have the Viewer workspace role while RLS restricts the report data to the India region.

29. Interview question — Workspace Role vs Item Permission

Workspace roles provide broad access and capabilities across a workspace, whereas item-level permissions can be used to give more targeted access to individual Fabric items without granting broader workspace collaboration rights.

30. Quick revision

MICROSOFT FABRIC WORKSPACE ROLES
======================================
ADMIN
  │
  └── Workspace Administration

Highest Control

MEMBER
  │
  └── Broad Collaboration

Content Management

CONTRIBUTOR
  │
  └── Create

Develop

Modify

VIEWER
  │
  └── View

Consume

One diagram to memorize

               FABRIC WORKSPACE
                      │
        ┌─────────────┼─────────────┐
        │             │             │
        ▼             ▼             ▼
      ADMIN         MEMBER      CONTRIBUTOR
        │             │             │
        ▼             ▼             ▼

MANAGE COLLABORATE BUILD

   WORKSPACE         & MANAGE       CONTENT
                                      │
                                      ▼
                                    VIEWER
                                      │
                                      ▼

CONSUME

The easiest way to remember

Admin = Manage Member = Collaborate Contributor = Build Viewer = Consume

And for all the security topics you've covered:

Security conceptQuestion it answers
Workspace RoleWhat can I do in this workspace?
Item PermissionWhich Fabric item can I access?
SQL PermissionWhat database operation can I perform?
RLSWhich rows can I see?
OLSWhich model tables/columns can I access?
Sensitivity LabelHow sensitive is this data?
PurviewHow do we discover, classify, govern, and protect the data?
↑ Back to top
Module 9 · Lesson 9.9

Module 9 · Lesson 9.6

Configure Security