Power BI Semantic Model
Enterprise guide to semantic model design, calculation groups, field parameters, composite models, Direct Lake, governance, and shared model architecture.
Power BI Semantic Model Enterprise Guide 2026 — enterprise reference guide from EPC Group, built from 29 years of Microsoft consulting engagements at Fortune 500 scale. Covers architecture, governance, compliance, pricing benchmarks, and implementation timelines for the Microsoft ecosystem.
Key Facts
- Built from EPC Group enterprise consulting engagements at Fortune 500 scale.
- Compliance-native guidance for HIPAA, SOC 2, FedRAMP, FINRA, CMMC, and GxP environments.
- Includes pricing benchmarks, timelines, and decision-framework matrices where applicable.
- Authored by EPC Group senior architects with 10+ years Microsoft enterprise experience.
- Microsoft Solutions Partner with experience across core current designations.
- Free consultation to apply this guide to your specific environment.
What Is a Semantic Model in Power BI?
What is a semantic model in Power BI? A Power BI semantic model is a centralized data layer. It defines various elements for reporting, including:
- Tables
- Relationships
- DAX measures
- Hierarchies
- Calculation groups
- Security rules
In 2023, Microsoft renamed it from "dataset" to emphasize its role as a meaning-based layer between raw data and business insights.
The semantic model is the single source of truth for your data. A well-designed model can support numerous reports, from dozens to hundreds. It offers:
- Consistent metrics
- Controlled access
- Improved performance
The semantic model is crucial for your Power BI deployment. Every report, dashboard, and metric relies on the quality of this model. A poorly designed model can lead to:
- Slow reports
- Inconsistent numbers
- Unmanageable analytics sprawl
In contrast, a well-designed model delivers fast and reliable enterprise-grade business intelligence.
EPC Group has designed and optimized Power BI semantic models for Fortune 500 organizations across healthcare, financial services, and government. This guide covers every aspect of enterprise semantic model design — from the fundamental rename from "dataset" to advanced features like calculation groups, field parameters, composite models, and Direct Lake in Microsoft Fabric.
Are you designing a new semantic model, migrating from old datasets, or optimizing an existing model for Fabric? This guide outlines the enterprise methodology that EPC Group uses for every engagement.
Semantic Model vs Dataset vs Datamart
Microsoft's terminology has evolved, and the distinctions matter for architecture decisions. Understanding what each component does — and does not do — prevents costly design mistakes.
| Component | What It Is | Engine | Best For |
|---|---|---|---|
| Semantic Model (Dataset) | In-memory analytical model with tables, relationships, DAX measures, RLS, and calculation groups | Vertipaq (columnar compression) | Primary analytics layer — reports, dashboards, metrics |
| Datamart | Self-service relational database with SQL endpoint, no-code ETL, and auto-generated semantic model | Azure SQL (relational) | Teams needing SQL access to curated data subsets |
| Lakehouse (Fabric) | Delta Lake storage with SQL analytics endpoint and auto-created semantic model | Spark + SQL + Direct Lake | Enterprise data platform with unified storage in OneLake |
| Warehouse (Fabric) | Full T-SQL data warehouse with cross-database queries and semantic model | Distributed SQL engine | Complex transformations requiring full T-SQL support |
Key Takeaway: Every Fabric item, including Lakehouse, Warehouse, and Datamart, automatically generates a default semantic model. However, these default models often lack optimized relationships, measures, and governance.
EPC Group develops a custom semantic model on top of Fabric storage. We view the auto-generated model as a starting point rather than a final product.
Six Enterprise Semantic Model Design Principles
These foundational principles guide every semantic model EPC Group builds. Violating any one creates performance, governance, or trust problems.
Star Schema Foundation
Every semantic model starts with a star schema — fact tables with numeric measures surrounded by dimension tables with descriptive attributes. The Vertipaq engine is optimized specifically for this pattern.
Single Source of Truth
One certified semantic model per business domain. All reports connect to the shared model via live connection. No duplicate models, no conflicting numbers.
Calculation Groups
Replace hundreds of duplicate measures with reusable calculation items. Time intelligence, currency conversion, and scenario analysis as modular, maintainable groups.
Optimal Storage Modes
Choose Import, DirectQuery, composite, or Direct Lake based on data volume, freshness requirements, and capacity constraints. No one-size-fits-all.
Governance & Certification
Endorsement levels (Promoted, Certified), workspace permissions, lineage tracking, and a formal certification process with documented quality criteria.
Shared Model Architecture
Publish certified models to dedicated workspaces. Report authors connect via live connection. Centralized security, single refresh schedule, consistent metrics.
Relationships and Cardinality in Semantic Models
Relationships impact the functionality of filters in your semantic model. A misconfigured relationship can lead to inaccurate numbers and poor performance. To ensure accuracy, EPC Group examines each relationship during our semantic model audit.
Cardinality Rules
- One-to-many (1:*) is the default and preferred cardinality — dimension tables (one side) filter fact tables (many side)
- Many-to-one (*:1) is the reverse perspective of 1:* — functionally identical, direction depends on which table you start from
- One-to-one (1:1) typically indicates tables that should be merged — two tables with the same grain and the same key should be a single table
- Many-to-many (*:*) should be avoided unless modeling bridge tables for multi-valued dimensions (e.g., a product with multiple categories) — always use a bridge table with two 1:* relationships instead
Cross-Filter Direction
Single-direction cross-filtering (dimension filters fact) is the recommended default setting. Enable bidirectional filtering only when a specific visual requirement calls for it.
In those cases, use CROSSFILTER() in DAX instead of model-level bidirectional settings.
Bidirectional relationships can lead to:
- Ambiguous filter paths
- Degraded Vertipaq query optimization
- Unexpected results in visuals with multiple fact tables
Role-Playing Dimensions
When a single dimension table links to a fact table through multiple columns, use one active relationship. For the other connections, use USERELATIONSHIP() in DAX.
For instance, a Date dimension can connect to:
- OrderDate
- ShipDate
- DueDate
Do not duplicate the dimension table. Duplicates waste memory and create maintenance issues. Instead, use a single Date dimension with three relationships:
- One active relationship
- Two inactive relationships
Calculation Groups: Eliminate Measure Sprawl
Calculation groups improve the maintainability of enterprise semantic models. They remove the need for many duplicate measures. Instead, a single reusable group of calculation items can dynamically change any measure.
How Calculation Groups Work
A calculation group is a unique table with one column for calculation items. It applies DAX transformations to any measure chosen in a visual.
For example:
- When a user selects "Sales Amount" as a measure and "Time Intelligence" as a slicer, choosing "YTD" applies TOTALYTD() to Sales Amount.
- Selecting "PY" applies SAMEPERIODLASTYEAR().
The measure itself remains unchanged; the calculation group wraps it dynamically.
Common Calculation Group Patterns
Time Intelligence
Items: YTD, QTD, MTD, PY, PY YTD, YOY, YOY%, Rolling 12 Months
Replaces 8 variants per measure — 30 base measures x 8 = 240 measures reduced to 30 + 1 group
Currency Conversion
Items: USD, EUR, GBP, JPY, Local Currency
Replaces 5 variants per measure — eliminates currency-specific measures entirely
Scenario Analysis
Items: Actual, Budget, Forecast, Variance, Variance %
Replaces 5 variants per measure — enables dynamic actual-vs-budget on any KPI
Display Formatting
Items: Per Unit, Per 1000, Percentage of Total, Running Total, Moving Average
Replaces 5 variants per measure — report authors apply formatting without new measures
Enterprise Impact: EPC Group implemented calculation groups for a Fortune 500 financial services client with over 1,200 measures. After consolidation, the client had:
- 180 base measures
- 4 calculation groups
Model maintenance time decreased from 40 hours per month to just 8 hours. Additionally, measure consistency issues, such as differing YTD formulas across departments, were completely resolved.
Field Parameters: Dynamic Report Experiences
Field parameters let report users modify the measures or columns displayed in visuals. This can be done without editing the report itself.
This feature transforms static, single-purpose pages into dynamic, multi-purpose dashboards.
As a result, organizations can:
- Reduce report page count by 40-60%
- Enhance user experience
Use Cases for Field Parameters
- Executive dashboards where users toggle between Revenue, Profit, Margin, and Units Sold on the same visual
- Comparison charts where users select which dimension to analyze by — Region, Product, Department, or Customer Segment
- Mobile reports where screen space is limited and every visual must serve multiple purposes
- Self-service scenarios where business users need flexibility without editing the underlying report
- Drill-through pages that adapt their columns based on the source visual context
Limitation: Field parameters create a disconnected table with NAMEOF(). They do not support dynamic security, meaning RLS does not apply to field parameter selections.
Test thoroughly before deploying in compliance-sensitive environments. EPC Group validates field parameter behavior against RLS in every deployment.
Composite Models and Direct Lake in Fabric
Choosing the right storage mode is crucial in designing a semantic model. This decision significantly impacts performance and usability. The best option depends on several factors:
- Data volume
- Freshness requirements
- Capacity budget
- Fabric migration timeline
| Storage Mode | Performance | Data Freshness | Best For |
|---|---|---|---|
| Import | Fastest (in-memory Vertipaq) | Scheduled refresh (minutes to hours) | Datasets under 1GB, dashboards needing maximum speed |
| DirectQuery | Depends on source (slower) | Real-time (every query hits source) | Real-time requirements, source handles query load |
| Composite | Fast dimensions + live facts | Hybrid (cached dimensions, live facts) | Datasets 1-100GB, balance speed and freshness |
| Direct Lake (Fabric) | Near-Import speed | Near-real-time (reads OneLake Parquet) | Fabric environments, eliminating refresh pipelines |
Direct Lake: The Fabric Game-Changer
Direct Lake solves the main challenge in enterprise Power BI: data refresh. It eliminates the need for importing data into the Vertipaq engine. This traditional method requires:
- Scheduled refresh pipelines
- Timeout management
- Capacity allocation for refresh processing
In contrast, Direct Lake reads Delta/Parquet files directly from OneLake. The data is already available, allowing the semantic model to read it seamlessly.
EPC Group worked with a client who managed a 50GB dataset. This dataset needed a 45-minute import refresh twice a day. We successfully migrated the semantic model to Direct Lake. The results were impressive:
- Improved data refresh times.
- Enhanced performance of the semantic model.
- Streamlined data management processes.
- Improved data refresh speed
- Enhanced performance
- Increased reliability
- Zero refresh time, with data updating as soon as Lakehouse pipelines write new Parquet files.
- Query performance within 10% of Import mode.
- Complete elimination of refresh timeout failures.
Direct Lake needs Fabric capacity of F64 or higher for production workloads. It also requires data to be stored in Delta format.
EPC Group includes the Lakehouse-to-Direct Lake pipeline as a standard feature in every Fabric deployment.
Semantic Model Performance Optimization
Performance optimization is not an afterthought — it is a design discipline. Every decision from schema to DAX affects query speed, refresh time, and capacity cost.
Remove Unused Columns
Every column in the semantic model consumes memory — even columns referenced by zero visuals. Audit with DAX Studio VertiPaq Analyzer and remove all unused columns.
Impact: 20-40% memory reduction
Use Integer Surrogate Keys
Replace text keys with integer keys for all relationships. Integer comparisons are 3-5x faster than text comparisons and compress more efficiently in Vertipaq.
Impact: 30-50% faster joins
Implement Incremental Refresh
For datasets over 1GB, configure incremental refresh to process only new and changed partitions. Requires a DateTime column and query folding support.
Impact: 80-98% refresh time reduction
Optimize DAX Measures
Use CALCULATE with explicit filters, avoid FILTER() on large tables, prefer SUMMARIZECOLUMNS, minimize iterator functions on high-cardinality columns.
Impact: 40-70% query speed improvement
Leverage Aggregation Tables
Create pre-aggregated summary tables for executive dashboards. Power BI automatically routes queries to the smallest table that satisfies the visual.
Impact: 70-90% dashboard load improvement
Enable Query Folding
Ensure Power Query transformations fold to the source database. Unfolded steps require Power BI to download raw data before transforming — exponentially slower.
Impact: 50-80% refresh improvement
Semantic Model Governance: Endorsement, Certification, and Lineage
Without proper governance, semantic model sprawl can happen. Organizations might create several competing models that yield different results for the same metrics. To address this issue, EPC Group uses a three-tier governance framework for each enterprise deployment.
Three-Tier Endorsement Framework
Exploratory
No Endorsement
Personal workspace models for ad-hoc analysis. Not shared, not governed, not trusted for decisions. Any user can create.
Promoted
Promoted
Team-level models that have been reviewed by the data team. Published to shared workspaces. Useful but not yet certified against organizational standards.
Certified
Certified
Enterprise-grade models that meet all quality, accuracy, security, and documentation standards. Only designated certifiers (Power BI admins) can certify. The gold standard.
Certification Criteria
- Data accuracy validated against source systems — reconciliation within 0.01% tolerance for financial metrics
- Star schema design with documented relationships, grain definitions, and column descriptions
- Row-level security implemented and tested for all applicable security scopes
- Performance benchmarks met — average visual render under 3 seconds, refresh under SLA
- DAX measures documented with business definitions, formulas, and owners
- Lineage documented — source systems, transformation logic, refresh schedule, and downstream reports cataloged
- Incremental refresh configured for datasets over 1GB with partition management documented
- Owner assigned with clear escalation path for data quality issues
Shared Semantic Model Architecture
The shared semantic model pattern is a key governance decision for enterprise Power BI. It stops each report author from making their own data model. This prevents the creation of over 50 models that may have conflicting numbers.
Instead, a centralized team is responsible for building and certifying shared models. All report authors connect to these certified models, ensuring consistency and accuracy across reports.
Architecture Pattern
- Dedicated model workspace — certified semantic models live in a dedicated workspace (e.g., "Finance - Certified Models") with restricted Build permissions
- Live connection — report authors connect to the shared model via Live connection, consuming zero additional capacity (no data duplication)
- DirectQuery to dataset — when report authors need to extend the model with local tables, they use DirectQuery to Power BI dataset (now semantic model)
- Separation of model and reports — the model workspace contains only models; report workspaces contain only reports. This enables independent deployment cycles
- Centralized RLS — row-level security defined once in the shared model applies to every connected report automatically
- Single refresh schedule — one refresh schedule per model instead of 50 separate refreshes for 50 duplicate models
Enterprise Impact: EPC Group implemented shared semantic models for a healthcare system with 12 hospitals. Previously, there were:
- 340 separate datasets
- 15 different revenue calculation formulas
- 8 conflicting patient volume numbers
After the implementation, the results included:
- 7 certified shared models
- One revenue formula
- One patient volume definition
The report count remained over 200, but the model count decreased by 95%. Additionally, the monthly refresh capacity cost dropped by $4,200.
EPC Group Semantic Model Methodology
Our 4-phase approach takes any organization from ungoverned model sprawl to a certified, optimized, shared semantic model architecture.
Discovery & Audit
Week 1
Inventory all existing datasets, their refresh schedules, RLS configurations, measure definitions, and downstream reports. Identify duplicate models, conflicting measures, and performance bottlenecks using DAX Studio and ALM Toolkit.
Deliverable: Semantic model landscape audit with consolidation roadmap
Model Design
Week 2
Design the target star schema with fact/dimension tables, relationships, calculation groups, field parameters, and storage modes. Define the shared model workspace architecture, endorsement criteria, and governance processes.
Deliverable: Semantic model design document with governance framework
Build & Migrate
Weeks 3-5
Build the certified semantic models in Tabular Editor. Implement calculation groups, RLS, incremental refresh, and composite/Direct Lake storage. Migrate existing reports to connect to shared models.
Deliverable: Certified semantic models with migrated reports
Validate & Govern
Week 6
Performance test every connected report. Validate data accuracy against source systems. Certify models through the endorsement framework. Train model owners on maintenance and governance workflows.
Deliverable: Certified production models with trained governance team
Frequently Asked Questions
What is a semantic model in Power BI?
A semantic model in Power BI is the unified data layer that defines tables, relationships, measures, hierarchies, and business logic for reporting. Previously called a "dataset," Microsoft renamed it to "semantic model" in late 2023 to better reflect its purpose — it provides a semantic (meaning-based) layer between raw data sources and report visuals. The semantic model contains the star schema design, DAX measures, row-level security rules, calculation groups, and field parameters that transform raw data into business-ready analytics. EPC Group designs semantic models as the single source of truth for enterprise analytics — one well-governed model that serves dozens or hundreds of reports.
What is the difference between a semantic model, dataset, and datamart in Power BI?
A semantic model and dataset are the same thing — Microsoft renamed "dataset" to "semantic model" in 2023. Both refer to the data model containing tables, relationships, and DAX logic published to the Power BI Service. A datamart is a self-service, fully managed relational database within Power BI Premium that allows analysts to create SQL-queryable data stores without Azure SQL or Synapse. Key differences: semantic models use Vertipaq in-memory compression and DAX; datamarts use a SQL endpoint with T-SQL queries. Semantic models are the primary analytics layer for reports. Datamarts are useful when teams need SQL access to a subset of enterprise data. EPC Group recommends semantic models as the primary analytics layer and datamarts only for teams that require direct SQL access.
How do calculation groups work in Power BI semantic models?
Calculation groups are reusable sets of DAX calculation items that modify how measures behave — eliminating the need to create dozens of duplicate measures for common transformations like time intelligence. For example, instead of creating "Sales YTD," "Profit YTD," "Revenue YTD," and "Cost YTD" separately, you create one calculation group called "Time Intelligence" with items like YTD, QTD, MTD, PY, PY YTD, and YOY%. Every measure in the model can then be combined with any calculation item. This reduces a 200-measure model to 30 base measures plus a single calculation group. EPC Group implements calculation groups in every enterprise semantic model — they reduce measure count by 60-80% and dramatically simplify maintenance.
What are field parameters in Power BI and when should you use them?
Field parameters allow report consumers to dynamically switch which columns or measures appear in visuals without editing the report. Users select from a dropdown (e.g., "Revenue," "Profit," "Units Sold") and the visual updates to show the selected metric. Under the hood, field parameters create a disconnected table with NAMEOF() references to measures or columns. Use cases: executive dashboards where users toggle between KPIs, comparison visuals where users pick which dimensions to slice by, and mobile reports where screen space is limited. EPC Group uses field parameters in 90%+ of executive dashboards — they reduce the number of report pages by 40-60% while giving users more flexibility.
What is Direct Lake mode in Microsoft Fabric and how does it affect semantic models?
Direct Lake is a new storage mode in Microsoft Fabric that reads Parquet files directly from OneLake into the Vertipaq engine — combining the performance of Import mode with the freshness of DirectQuery. Unlike Import (which copies data during refresh) or DirectQuery (which queries the source live), Direct Lake reads columnar Parquet files on demand without a data copy step. Benefits: near-instant "refresh" because data is already in OneLake, query performance close to Import mode, no separate ETL pipeline to maintain. Limitations: requires Fabric capacity (F64 or higher for production), data must be in Delta/Parquet format in OneLake, and not all DAX functions are supported in the initial framing. EPC Group is migrating enterprise clients from Import and DirectQuery to Direct Lake as part of Fabric adoption — typical refresh times drop from 30-60 minutes to under 30 seconds.
How do you govern and certify semantic models in Power BI?
Power BI provides two levels of semantic model endorsement: Promoted (any dataset owner can promote their model as recommended) and Certified (only designated certifiers approved by the Power BI admin can certify a model as meeting organizational quality standards). Governance best practices: 1) Establish clear certification criteria — data accuracy validation, performance benchmarks, RLS implementation, documentation requirements, 2) Create a semantic model registry that tracks all certified models, their owners, refresh schedules, and downstream reports, 3) Use workspace-level permissions to control who can build reports against certified models, 4) Enable lineage view to track data flow from source through semantic model to reports. EPC Group establishes governance frameworks that typically include a 5-step certification process with automated validation checks.
What are shared semantic models and why are they important for enterprise Power BI?
Shared semantic models (also called shared datasets) allow multiple reports across different workspaces to connect to a single published semantic model — creating a true single source of truth. Without shared models, every report author creates their own data model, leading to conflicting numbers, duplicated refresh schedules, and ungovernable sprawl. With shared models, one team maintains the certified semantic model, and report authors use "Live connection" or "DirectQuery to Power BI dataset" to build reports against it. Benefits: consistent metrics across the organization, reduced capacity consumption (one model instead of 50 copies), centralized security through model-level RLS, and simplified governance. EPC Group implements shared semantic model architectures for every enterprise client — a typical deployment has 5-10 certified models serving 200+ reports.
How do composite models improve Power BI semantic model performance?
Composite models allow a single semantic model to combine multiple storage modes: Import (fast, cached), DirectQuery (real-time, source-queried), and Dual (both). The enterprise strategy: Import small dimension tables (products, customers, dates — fast filtering), keep large fact tables in DirectQuery (transactions, events — always current, no refresh needed), and use aggregation tables in Import mode for high-level visuals while DirectQuery serves detail-level drill-through. Composite models also support DirectQuery to Power BI datasets — enabling you to extend a certified shared semantic model with additional local tables without duplicating the entire model. EPC Group designs composite model architectures for datasets between 1-100GB, balancing performance, freshness, and capacity consumption.
What are the best practices for Power BI semantic model performance optimization?
Enterprise semantic model performance optimization covers five areas: 1) Schema design — star schema with integer keys, minimal columns, proper cardinality, 2) DAX efficiency — use CALCULATE with explicit filters, avoid FILTER() on large tables, prefer SUMMARIZECOLUMNS over ADDCOLUMNS/SUMMARIZE, 3) Storage modes — use composite models with Import dimensions and DirectQuery facts, or migrate to Direct Lake in Fabric, 4) Refresh optimization — implement incremental refresh with partition management, use query folding to push transformations to source, 5) Capacity management — right-size Premium/Fabric capacity, monitor with Capacity Metrics app, set max memory per dataset limits. EPC Group performance audits typically improve semantic model query times by 50-80% and reduce refresh duration by 60-90%.
Related Resources
Power BI Consulting Services
Enterprise Power BI implementation, optimization, and managed services from EPC Group.
Read morePower BI Data Modeling Best Practices
Deep technical guide to star schema design, relationships, calculated columns vs measures, and performance optimization.
Read moreEnterprise Analytics Solutions
Full-stack Microsoft analytics: Fabric, Power BI, Azure AI, and enterprise operating models.
Read moreGet Your Semantic Model Optimized
Schedule a free semantic model assessment with EPC Group. We will review your current models and find ways to consolidate them. Our goal is to provide a shared semantic model architecture that:
- Improves data consistency
- Enhances collaboration across teams
- Supports better decision-making
- Eliminates conflicting metrics
- Reduces capacity costs
- Improves query performance by 50-80%
Power BI Semantic Model: Enterprise Guide 2026
A Power BI semantic model (formerly dataset) is the governed data layer. It defines measures, relationships, hierarchies, and security.
This guide includes:
- Enterprise design patterns
- Direct Lake mode
- Row-level security
- Copilot readiness for 2026
Last updated: June 2025 · Read time: 22 min
Key facts
- A semantic model (formerly "dataset") is the governed data layer for all Power BI reports.
- Star schema design — one fact table, multiple dimension tables — is the required pattern for performance.
- Row-level security (RLS) is defined in the semantic model and applies to all connected reports.
- DirectLake mode in Fabric reads Parquet files in OneLake without importing data into Vertipaq.
- Copilot answer quality depends directly on field names, descriptions, and synonyms in the semantic model.
Overview and Context
Enterprise guide to semantic model design, calculation groups, field parameters, composite models, Direct Lake, governance, and shared model architecture.
The semantic model is essential for your Power BI deployment. It impacts every report, dashboard, and metric. A high-quality semantic model is vital for achieving overall success.
A poorly designed model produces slow reports, inconsistent numbers, and ungovernable analytics sprawl. A well-designed model produces fast, trustworthy, enterprise-grade business intelligence.
- One-to-many (1:*) is the default and preferred cardinality — dimension tables (one side) filter fact tables (many side)
- Many-to-one (*:1) is the reverse perspective of 1:* — functionally identical, direction depends on which table you start from
- One-to-one (1:1) typically indicates tables that should be merged — two tables with the same grain and the same key should be a single table
Technical Architecture
Relationships affect how filters operate within your semantic model. If a relationship is misconfigured, it can result in incorrect numbers or poor performance, or both.
EPC Group carefully examines each relationship in our semantic model audit.
Calculation groups improve the maintainability of enterprise semantic models. They remove the need for many duplicate measures. Instead, a single reusable group of calculation items can dynamically change any measure.
- Many-to-many (*:*) should be avoided unless modeling bridge tables for multi-valued dimensions (e.g., a product with multiple categories) — always use a bridge table with two 1:* relationships instead
- Executive dashboards where users toggle between Revenue, Profit, Margin, and Units Sold on the same visual
- Comparison charts where users select which dimension to analyze by — Region, Product, Department, or Customer Segment
Implementation Steps
EPC Group worked with a client who managed a 50GB dataset. This dataset required a 45-minute import refresh twice a day. We migrated the semantic model to Direct Lake, which led to significant improvements:
- Reduced refresh time
- Enhanced data accessibility
- Improved overall performance
- Faster data refresh times
- Enhanced performance
- Improved user experience
- Zero refresh time, with data updates occurring as soon as Lakehouse pipelines write new Parquet files.
- Query performance within 10% of Import mode.
- Complete elimination of refresh timeout failures.
Direct Lake needs a Fabric capacity of F64 or higher for production workloads. It also requires data to be stored in Delta format.
EPC Group includes the Lakehouse-to-Direct Lake pipeline as a standard part of every Fabric deployment.
- Mobile reports where screen space is limited and every visual must serve multiple purposes
- Self-service scenarios where business users need flexibility without editing the underlying report
- Drill-through pages that adapt their columns based on the source visual context
Enterprise Considerations
The shared semantic model pattern is crucial for enterprise Power BI governance. It stops each report author from building their own data model. Without this, organizations can end up with over 50 models that show conflicting numbers.
Instead, a centralized team is responsible for building and certifying shared models. All report authors connect to these certified models, ensuring consistency and accuracy across reports.
Our 4-phase approach takes any organization from ungoverned model sprawl to a certified, optimized, shared semantic model architecture.
- Data accuracy validated against source systems — reconciliation within 0.01% tolerance for financial metrics
- Star schema design with documented relationships, grain definitions, and column descriptions
- Row-level security implemented and tested for all applicable security scopes
Frequently Asked Questions
What is a Power BI semantic model?
A semantic model (formerly dataset) serves as the governed data layer for Power BI reports. It defines important elements such as:
- Measures
- Relationships
- Row-level security
- Field metadata
All reports linked to the model share one source of truth.
What is DirectLake mode?
DirectLake mode allows you to read Parquet files stored in OneLake. You can access these files without importing data into Vertipaq. This mode offers query speeds that are almost as fast as Import mode. Additionally, it eliminates the costs associated with refresh windows.
To use DirectLake mode, you need:
- Microsoft Fabric F-SKU capacity
How do I design a semantic model for Copilot?
Use descriptive field names, add descriptions to every measure and dimension, configure synonyms for common terms, and remove unused columns. These steps directly improve Copilot answer accuracy.
What is the difference between Import and DirectQuery?
Import loads data into Vertipaq. This allows for quick queries, but the data is only as fresh as the last refresh. DirectQuery sends live queries to the source, ensuring the data is always current, but it is slower. DirectLake is the third option that is native to Fabric.
Should I use row-level security in every model?
Yes, this applies to any model that includes sensitive, role-specific, or regulated data. Row-Level Security (RLS) is defined in the semantic model. It impacts all reports and Copilot responses associated with that model.
Work with EPC Group
EPC Group has completed over 1,500 Power BI deployments for Fortune 500 companies and clients in regulated industries. Our architects literally wrote the book on Power BI.
Founder Errin O'Connor is a Microsoft MVP, first awarded in 2003. He was also a member of the original Power BI Beta Team.