10.4 — Access Control in Microsoft Fabric: RBAC, RLS, OLS & Cost Governance

As you scale Microsoft Fabric across teams and business units, two questions quickly dominate design conversations: who can see or change what, and how much does it cost to run. This section explains how Fabric answers both questions through role-based access control (RBAC), row-level security (RLS), object-level security (OLS), and cost governance practices. Together, these capabilities turn Fabric from a powerful analytics platform into an enterprise-ready, well-governed data estate.

RBAC: Controlling Access at the Workspace Level

Role-Based Access Control (RBAC) in Fabric defines who can do what in a workspace. It governs access to items such as semantic models, notebooks, pipelines, lakehouses, and reports. RBAC is enforced by the Fabric service itself, not by your data model, and it is the first line of defense for isolating projects and teams.

Workspace roles in Fabric

Fabric provides four standard workspace roles. You should understand them before you invite anyone to a workspace:

• Admin
  • Full control over the workspace and all its items.
  • Can add, remove, and change roles for other users and security groups.
  • Can publish, edit, delete, or overwrite any item (reports, semantic models, pipelines, notebooks, lakehouses, etc.).
  • Can configure workspace settings such as endorsement, sensitivity labels, and connection settings.
• Member
  • Co-owners for development work within the workspace.
  • Can create, edit, and delete items.
  • Can share reports and apps with others (depending on tenant and workspace settings).
  • Cannot change workspace-level permissions (cannot promote themselves or others to Admin).
• Contributor
  • Can create and edit most content they own or have been granted access to.
  • Can publish new items into the workspace.
  • Typically cannot delete or overwrite items owned by others unless explicitly allowed by item-level permissions.
  • Cannot manage workspace access or settings.
• Viewer
  • Read-only role for consumers.
  • Can view reports, dashboards, notebooks outputs, and other allowed content.
  • Cannot create, edit, or delete items in the workspace.
  • Ideal for broad audiences who only need to consume curated content.

RBAC best practices

• Assign roles by team function, not by person
  • Define clear personas: e.g., Fabric Admins, Data Engineers, Data Analysts, Business Consumers.
  • Map each persona to a default workspace role: for example, Data Engineers as Members, Analysts as Contributors, Consumers as Viewers.
• Use groups, not individuals
  • Use Azure AD / Entra ID security groups or Microsoft 365 groups to manage access.
  • Add and remove people from groups rather than editing workspace permissions one by one.
  • This dramatically simplifies onboarding and offboarding and supports audits.
• Audit permissions regularly
  • Review workspace access for high-value or sensitive workspaces (finance, HR, executive analytics) on a regular cadence.
  • Check for over-privileged accounts (e.g., too many Admins, Contributors who should be Viewers).
  • Align workspace access with data classifications and sensitivity labels.

RBAC sets the outer boundary of who can even get into a workspace and touch its items. Inside that boundary, you still need to control which data each person can see—this is where RLS and OLS come in.

RLS: Row-Level Security in Semantic Models

Row-Level Security (RLS) controls which rows of data a user can see in a semantic model. You typically define RLS on Power BI datasets (now semantic models in Fabric) and it is enforced whenever a report or other tool queries that model.

How RLS works in Fabric

• RLS is implemented as DAX filter rules on roles defined in Power BI Desktop.
• Each role contains one or more table filters that restrict visible rows.
• When a user connects to a semantic model, Fabric evaluates which roles apply to them and applies the union of all relevant filters.
• RLS is applied server-side, so users cannot bypass it by exporting or connecting via another tool.

Static RLS vs. dynamic RLS

There are two broad patterns for RLS rules, and both are important in real-world solutions.

• Static RLS
  • Uses hard-coded filter conditions that do not depend on the current user.
  • Example: A Finance role where the Department column must equal "Finance".
  • Best for scenarios where access is governed by membership in a fixed role (e.g., Finance, HR, Sales Leadership).
• Dynamic RLS
  • Filters rows based on the identity of the logged-in user.
  • Uses DAX functions such as USERNAME() or USERPRINCIPALNAME() to capture the user’s UPN or domain ame.
  • Typically joins the user identifier to a security table (mapping users or groups to allowed regions, cost centers, or business units) and filters based on that relationship.
  • Best for scenarios with many users or frequent changes, where maintaining static roles would be unmanageable.

Common RLS use cases

• Region-based access
  • Sales reps can see only the customers and orders in their assigned region.
  • Regional managers can see all regions they are responsible for, based on a mapping table between user and region.
• Department-based access
  • HR can see employee data for the entire company.
  • Line managers can see only employees in their department.
  • Other departments see only highly aggregated metrics without individual-level data.
• Manager and team visibility
  • Managers can see metrics for their direct reports and, optionally, their full reporting hierarchy.
  • Individual contributors see only their own records (e.g., their pipeline, their tickets).

Design RLS early: your semantic model schema, especially your security tables and relationships, should make it simple to express these filters in DAX without complicated or ambiguous logic.

OLS: Object-Level Security for Tables and Columns

While RLS filters rows, Object-Level Security (OLS) controls which tables or columns are visible at all. OLS is critical for hiding highly sensitive fields, even from advanced users who might create their own reports or export data.

What OLS can protect

• Entire tables
  • Hide a whole table such as SalaryDetails or HRNotes for everyone except specific roles.
• Specific columns
  • Hide sensitive columns in otherwise shareable tables, such as:
  • Personally identifiable information (PII) — national ID, personal email, phone numbers.
  • Compensation data — base salary, bonuses, stock grants.
  • Confidential metrics — margins, cost prices, internal scores.

Configuring OLS in Fabric semantic models

OLS can be configured in:

• Power BI Desktop
  • For many scenarios you can define OLS directly in Desktop when you configure roles and security.
• Tabular Editor
  • Provides a more advanced authoring experience for complex enterprise models.
  • Makes it easier to apply OLS consistently across large models and multiple roles.

OLS is evaluated alongside RLS. First, the model determines which objects (tables and columns) a user is allowed to see (OLS). Then, RLS further filters which rows within those objects are visible. Used together with RBAC, this gives you a layered security model that aligns with least-privilege principles.

RBAC vs. RLS vs. OLS: How They Work Together

RBAC, RLS, and OLS solve related but distinct problems. The following comparison helps you decide where to implement which rule.

Capability	What it controls	Where it applies	Who typically configures it	Typical use case
RBAC (Role-Based Access Control)	Access to workspaces and items (reports, semantic models, lakehouses, pipelines, notebooks).	Fabric workspaces, capacities, and sometimes tenant-level admin settings.	Fabric administrators, workspace admins, platform / CoE teams.	Segmenting projects or departments; ensuring only the right teams can create, edit, or delete content.
RLS (Row-Level Security)	Which rows in a table are visible to a user.	Semantic models (Power BI datasets) used by reports, dashboards, and external tools.	Data modelers, BI developers, data analysts working on the semantic model.	Region-based access, department-based access, managers seeing only their own teams’ data.
OLS (Object-Level Security)	Visibility of entire tables or individual columns.	Semantic models (Power BI datasets).	Data modelers and BI developers, often in collaboration with data owners and security teams.	Hiding salary, PII, or confidential metrics while still exposing aggregated or non-sensitive data.

A robust Fabric deployment uses all three: RBAC to gate workspace membership, OLS to hide sensitive objects, and RLS to tailor which slices of data each user can see.

Cost Governance in Microsoft Fabric

Security without cost control quickly becomes unsustainable. Fabric’s capacity-based model gives you predictable performance, but it also means you must treat compute and storage as shared, governed resources. Effective cost governance combines monitoring, performance optimization, and organizational practices such as chargeback and usage policies.

Monitor capacity usage

• Fabric Admin portal
  • Use the Admin portal to monitor capacity utilization (CPU, memory, concurrency) over time.
  • Identify peak usage windows and long-running or resource-heavy workloads.
  • Drill into workspaces and items that are consistently driving high consumption.
• Per-workspace monitoring
  • Track which workspaces consume the most capacity and storage.
  • Encourage workspace owners to review and optimize expensive datasets, notebooks, and pipelines.
• Capacity alerts
  • Configure alerts for high utilization thresholds (e.g., 80–90% sustained usage).
  • Trigger review or scaling decisions before performance degrades for business users.

Optimize Delta tables and storage layout

Most Fabric workloads rely on Delta tables in OneLake. Poorly designed tables can inflate storage costs and slow down queries, which in turn wastes capacity.

• Compaction
  • Use compaction jobs to merge many small Delta files into fewer, larger files.
  • This improves read performance and reduces overhead for query planning.
• Z-ordering
  • Apply Z-order indices on frequently filtered columns (such as date, region, customer ID).
  • Helps engines skip irrelevant data ranges, reducing I/O and compute time.
• Vacuum
  • Regularly run vacuum operations to remove obsolete data files that are no longer referenced.
  • Reduces storage footprint and keeps tables healthy over time.
• Avoid the tiny files problem
  • Design ingestion and streaming solutions to write data in reasonably sized batches.
  • Consolidate or batch events before writing to Delta instead of creating thousands of tiny files.
  • Tiny files cause excessive metadata overhead and degrade performance, driving up capacity usage.

Modeling for performance: schemas and aggregations

Good data modeling is one of the most powerful levers for controlling cost because it directly influences how much data each query needs to scan.

• Use a star schema
  • Organize large analytic models into a central fact table surrounded by dimension tables.
  • Keep fact tables narrow: avoid unnecessary columns and pre-aggregate where appropriate.
  • Dimension tables should contain descriptive attributes and hierarchies that support slicing and dicing.
• Use aggregation tables
  • Create pre-aggregated tables (by day, by region, by product category) for common reporting grains.
  • Configure semantic model aggregations so that most queries hit the smaller, aggregated tables instead of the detailed fact table.
  • This reduces the amount of data scanned and improves performance for high-volume reports.

Optimize development and deployment

• Use deployment pipelines instead of duplicate workspaces
  • Adopt deployment pipelines (e.g., Dev → Test → Prod) to promote content across stages.
  • Avoid copying and maintaining separate, uncoordinated datasets for each environment.
  • Shared, promoted models reduce duplication in storage and refresh operations.
• Right-size capacity SKUs
  • Choose capacity SKUs (e.g., F2, F4, F8, F64 and beyond) based on measured, not guessed, workload needs.
  • Start with a smaller SKU, monitor performance and queueing, and scale up or out as justified by usage patterns.
• Pause capacity during off-hours
  • For non-24/7 workloads, configure schedules to pause capacity during nights or weekends.
  • Ensure critical refreshes and batch jobs are scheduled when capacity is running.
  • Communicate pause windows clearly to users so they understand when reports may be unavailable.

Enterprise cost allocation and chargeback

In large organizations, cost governance is as much about organizational behavior as it is about technical tuning.

• Per-workspace usage attribution
  • Use Fabric’s monitoring capabilities and logs to estimate cost contributions by workspace.
  • Align workspaces with business units or product teams so costs map cleanly to owners.
• Chargeback or showback models
  • Implement a chargeback (or at least showback) process where business units see the cost impact of their workloads.
  • Share regular reports on capacity and storage usage by team.
  • Use this visibility to drive better behavior: consolidating redundant datasets, optimizing refresh schedules, and retiring unused content.
• Governance policies
  • Define standards for dataset refresh frequency, data retention, and acceptable performance.
  • Encourage reuse of certified semantic models instead of every team building their own from source.
  • Set guidelines for proof-of-concept work to avoid long-lived “temporary” workloads that continue consuming capacity.

Bringing It Together: Secure, Cost-Efficient Fabric

Access control and cost governance are two sides of the same coin. RBAC, RLS, and OLS ensure that only the right people can see and work with your data, at the right level of detail. Capacity monitoring, optimized Delta tables, efficient schemas, deployment pipelines, and enterprise chargeback ensure that you can deliver this security and insight sustainably, without runaway spend.

When you design your Fabric environment with these principles from the start, you get a platform that business stakeholders trust, security teams endorse, and finance teams can predict. That combination is what makes Microsoft Fabric not just powerful, but truly enterprise-ready and fit for long-term adoption.