In modern analytics, the biggest data risk is not always a breach from the outside. It is often a well-intentioned user seeing more than they should: a report that exposes sensitive columns, an AI prompt that surfaces restricted details, or an export that carries governed data beyond the right audience.
That is why data access permissions need to be designed deliberately. Microsoft Fabric provides a layered security model that helps organizations control who can enter a workspace, who can reach the underlying data in OneLake, and what each user can see at the table, row, and column level.
This article walks through three permission layers that work together to protect data while still enabling self-service analytics and AI:
- Workspace-level permissions to control who can access and manage Fabric resources.
- OneLake security to control access to the underlying data.
- Granular data security, including Row-Level Security (RLS), Column-Level Security (CLS), and Object-Level Security (OLS), to control what users can see.
When these layers are planned together, Fabric can give business users the access they need without turning every dataset into an all-access pass.
1. Workspace-Level Permissions: Establishing the First Access Boundary
Every secure Fabric environment starts with a basic question: who should be allowed into this workspace, and what should they be able to do once they are there? Workspace permissions create the first access boundary around Fabric resources.
Microsoft Fabric provides four workspace roles: Admin, Member, Contributor, and Viewer, each providing different levels of capability.
| Role |
Typical responsibility |
| Admin |
Manages the workspace, access, and settings |
| Member |
Collaborates on content and manages access based on permissions |
| Contributor |
Creates and modifies Fabric content |
| Viewer |
Consumes workspace content without authoring capabilities |
Think of the workspace as the first boundary around a Fabric environment. A development workspace may contain experimental models and pipelines, while a production workspace may contain business-critical reports and governed datasets. Separating these environments and assigning appropriate roles helps limit access and changes to what each team needs.
Workspace access does not automatically grant unrestricted access to all data. Organizations can combine workspace permissions with more granular item and OneLake permissions.
Use Microsoft Entra Groups
Workspace roles can be assigned through Microsoft Entra identities, including groups, making access easier to manage as teams change.
For example:
Finance Analysts → Finance Entra Group → Viewer access → Finance workspace
When someone joins or leaves the team, their group membership can be updated without redesigning the Fabric permission structure.
Separate Development, Test, and Production
Maintaining separate Development → Test → Production environments creates a clear boundary between experimentation and business-critical workloads. Developers may need authoring permissions in Development, while production access can be limited to those responsible for deployment and consumption.
Workspace permissions answer the first question: who can participate in a Fabric environment? The next question is more specific: which data should each person be allowed to use?
That is where OneLake security and granular data controls become essential.
2. OneLake Security: Controlling Access to the Data
Workspace permissions determine what users can do within Fabric. OneLake security goes a level deeper by helping control which data those users can access.
OneLake is the unified data lake that underpins Microsoft Fabric. Its security model helps organizations scope access to supported Fabric data across tables, folders, schemas, rows, and columns instead of relying only on broad workspace membership.
Why this matters
Consider a central sales lakehouse that contains customer information, product data, regional sales, pricing, and employee-related datasets. Not every analyst, manager, or downstream report consumer should see the same data just because they can access the workspace.
OneLake security allows organizations to move from broad access to purposeful access. Instead of treating an entire lakehouse as one permission boundary, teams can define access based on role, responsibility, and data sensitivity.
For example:
Sales leadership may need regional sales and pipeline data, Finance may need revenue and budget tables, and Operations may need fulfillment metrics without access to confidential compensation or personal information.
The same Fabric environment can therefore support multiple audiences while keeping each audience inside the right data boundary.
Understand the Grant Model
OneLake security roles are grant roles. They grant access to specific data; they are not a substitute for careful workspace design or broad access governance. If a user receives broad access through another layer, a more granular rule may not always behave like a deny rule.
The practical lesson is clear: do not grant more access than a user needs and assume another layer will clean it up later. Design permissions from the outside in: workspace, item, OneLake, and then row, column, or object controls where needed.
3. Granular Data Security: RLS, CLS, and OLS
Even after workspace and OneLake access are configured, some scenarios require more precision. A regional manager may need the Sales table, but only for their region. A finance analyst may need revenue data, but not salary or personally identifiable information.
This is where granular data security turns permission design from broad access into governed access.
| Security control |
What it controls |
Example |
| Object-Level Security (OLS) |
Tables, folders, or schemas |
Analyst can access Sales but not Payroll |
| Column-Level Security (CLS) |
Individual columns |
Analyst can see Revenue but not Cost |
| Row-Level Security (RLS) |
Individual rows |
Regional manager sees only their region |
Row-Level Security: Same Report, Different Data
RLS restricts the rows a user can access. For example, a global sales dashboard could include data for North America, Europe, and APAC.
Instead of creating separate reports:
North America Manager → North America rows
Europe Manager → Europe rows
APAC Manager → APAC rows
Users can work with the same underlying data while seeing only the rows permitted by their security role.
Column-Level Security: Protect Sensitive Fields
Sometimes the issue is not which rows a user can see, but which fields they can access.
A customer table may include Customer Name, Region, Revenue, Credit Limit, and Personal Information. A user may need only the first few fields and not require access to sensitive financial or personal information.
CLS allows organizations to restrict access to specific columns rather than creating separate copies of the data.
Object-Level Security: Control Access to Tables and Folders
OLS provides an additional layer of control by restricting access to specific objects such as tables or folders.
For example:
Finance team → Finance schema → Revenue and Budget tables
Sales team → Sales schema → Customer and Orders tables
This allows related data to remain within a governed environment while controlling which objects each user can access.
4. How the Three Layers Work Together
The strength of Fabric’s permission model is not one setting. It is the way each layer reinforces the next.
Workspace permissions define the collaboration boundary. OneLake security narrows access to the right data. RLS, CLS, and OLS refine visibility based on user role, geography, function, or sensitivity. Together, these controls help organizations support self-service analytics and AI without weakening governance.
5. What This Means for AI and Self-Service Analytics
AI makes permission design even more important. Traditional reports reveal the data that designers choose to display. AI-powered experiences can allow users to ask open-ended questions across a broader body of organizational data.
That means underlying data permissions become the control plane for trustworthy AI and governed self-service analytics.
Security should therefore be part of the architecture from the beginning, not something added after an analytics or AI solution is built.
In Fabric, organizations should continuously ask:
- Who can access the workspace?
- Who can access the underlying data?
- Which tables and columns should each audience see?
- Which rows should different users be able to access?
- Which identities or groups should receive those permissions?
A properly designed security model can allow multiple audiences to work from governed data without requiring a separate dataset or report for every user group.
6. A Practical Fabric Permission Strategy: The LevelShift Approach
A secure Fabric environment starts with a permission strategy that is intentional, documented, and tested:
- Start with identity: Use Microsoft Entra users and groups to establish who needs access.
- Define workspace boundaries: Separate workloads and environments based on organizational and operational requirements.
- Assign the appropriate workspace role: Give users only the level of access they need.
- Define data access: Use OneLake security where workspace-level access is too broad.
- Apply granular controls: Use RLS, CLS, and OLS when different users need access to different data within the same environment.
- Test and review: Validate access using different user personas and review permissions as requirements change.
This is the approach LevelShift applied to CITGO, building a centralized, IT-governed data distribution model on Microsoft Fabric. Enterprise data was provisioned through a central Enterprise Domain, and business units accessed it via their respective domains in read-only mode. Teams could also ingest business-specific data from SAP, APIs, and local systems, combining it with governed enterprise data for analytics, reporting, and machine learning.
The result is a model that balances centralized governance with decentralized innovation: IT can protect trusted enterprise data, while business teams can analyze, build, and innovate within clearly defined access boundaries.
Building a secure and governed Microsoft Fabric environment?
LevelShift can help you design a Fabric architecture where data access permissions are clear, enforceable, and ready for analytics and AI. [Talk to our team →]
