If you have been following Power BI closely in 2026, you will have noticed that the updates shipping through Microsoft Fabric are no longer incremental improvements to existing features. They are structural changes to how the platform works, how security is applied, how data models are built, and increasingly, who or what does the building.
This article covers the most significant Power BI semantic model developments from mid-2026, drawn from a detailed conversation between two people who sit closest to these changes: a Power BI product architect at Microsoft and one of the most knowledgeable independent voices in the Power BI community.
Four developments stand out as genuinely important for any organisation running Power BI at meaningful scale. OneLake Security reaching general availability. The distinction between Direct Lake on OneLake and Direct Lake on SQL, and why it matters which one you are using. Composite models that mix Direct Lake and Import tables in a single semantic model. And an AI agent that builds an enterprise-grade semantic model, complete with relationships, DAX measures, business definitions, and renamed columns, in under a minute.
Each of these changes has practical implications for how Power BI environments should be architected, governed, and maintained going forward.
What Is a Power BI Semantic Model and Why Does It Matter in the Age of AI?
Before covering the specific updates, it is worth being clear about what a semantic model is and why it has become more important, not less, as AI capabilities enter the Power BI ecosystem.
A semantic model sits between raw data and the people or systems that need to make sense of it. It abstracts the complexity of joins, relationships, and calculations away from the end user, whether that user is a business analyst building a dashboard, an executive asking a question in natural language, or an AI agent querying the data on their behalf.
The semantic model defines which tables exist, how they relate to each other, what measures mean, what the data is called in language a business user recognises, and what security rules determine who can see what. It is, as Microsoft describes it, the intelligence layer of the analytics architecture.
In a world where AI agents are increasingly the consumer of enterprise data rather than just humans, the semantic model becomes more critical, not more redundant. An AI agent asking a data question about year-over-year revenue growth for the top ten customers in a specific region needs the same semantic context a human analyst needs. Without it, the AI is operating on raw data it cannot reliably interpret. With a well-built semantic model, the AI can ask business-oriented questions and get back consistent, trusted, repeatable answers.
This is the architecture story running underneath all four of the updates covered in this article.
OneLake Security Is Now Generally Available
The general availability of OneLake Security was one of the most significant governance announcements to come out of FabCon Atlanta in 2026, and it changes the security architecture conversation for any organisation running multiple workloads within Microsoft Fabric.
Before OneLake Security, defining security in a Fabric environment meant defining it at every layer. Security rules applied in a data warehouse needed to be separately replicated in the SQL endpoint, and again in the semantic model. Every layer of the architecture required its own security definition, even when the underlying rules were the same.
OneLake Security changes this by allowing security to be defined once at the source, in OneLake, and then observed automatically by every workload and every consumer that sits downstream. Define it once. Everything respects it.
For Power BI specifically, this means that the security configuration applied in a lakehouse or warehouse flows through to the semantic model without needing to be redefined at the semantic layer. Row-level security, column-level security, and access controls that previously needed to be maintained in multiple places now need to be maintained in one.
There is an important setup requirement worth flagging for teams implementing this. OneLake Security requires the lakehouse or warehouse to be configured in User Identity Mode rather than Delegated Identity Mode. Any new lakehouse or warehouse created in Fabric will now default to User Identity Mode, but environments created before this change may still be using Delegated Identity Mode and will need to be checked before OneLake Security roles can be applied correctly.
For organisations that have historically found multi-layer security configuration in Fabric to be complex and inconsistent, this is a meaningful architectural simplification. The governance overhead of maintaining security definitions across multiple layers of the analytics stack is one of the most common reasons security configurations drift over time. Defining security once removes that drift.
Direct Lake on OneLake vs Direct Lake on SQL: A Distinction That Matters
A significant number of Power BI practitioners are not aware that Direct Lake on OneLake and Direct Lake on SQL are two different things, and that choosing between them has meaningful implications for query performance, feature availability, and the path forward for their semantic model architecture.
Direct Lake on SQL was the earlier implementation of Direct Lake in Microsoft Fabric. It falls back to DirectQuery when security rules are defined at the SQL endpoint, which means any organisation using SQL-based security on a Direct Lake model will be triggering DirectQuery fallback regularly. That fallback has performance implications because DirectQuery query plans are more complex and the queries submitted to the source system are significantly larger.
Direct Lake on OneLake is the current implementation and, as Microsoft has confirmed, the path forward for investment. The differences between the two are substantial.
| Direct Lake on SQL | Direct Lake on OneLake | |
|---|---|---|
| Security model | SQL endpoint security, triggers DirectQuery fallback | OneLake Security, no DirectQuery fallback |
| Multiple Direct Lake sources | Single source only | Multiple sources supported |
| Composite models | Limited support | Full support — Import and Direct Lake in same model |
| Calculated columns | Standard only | Standard and User Context expression modes |
| Modeling features | Limited | Strong relationships, composite models, user hierarchies on Import tables |
| Performance | Falls back to DirectQuery with SQL security | Simpler query plans, faster perceived performance |
| Investment direction | Maintenance mode | Primary development focus |
The clearest signal of which to use is this: if there is no specific reason to use Direct Lake on SQL, Direct Lake on OneLake is the correct choice. Microsoft has confirmed it will receive the most investment going forward and that Direct Lake on SQL will not be receiving the new modeling capabilities being added to the OneLake version.
For teams currently on Direct Lake on SQL without a specific reason for it, migrating to Direct Lake on OneLake is the architecture decision that aligns with where the platform is heading. When creating a new semantic model from the SQL endpoint, Power BI now gives a choice between the two modes and will default to Direct Lake on OneLake when the SQL endpoint is configured in User Identity Mode.
Composite Models: Mixing Direct Lake and Import Tables
The ability to combine Direct Lake tables and Import tables in a single semantic model is one of the features Power BI practitioners have been requesting for some time, and it is now available in Direct Lake on OneLake.
The practical value of this capability is best understood through the architecture pattern it enables.
Large fact tables, the ones with hundreds of millions or billions of rows, benefit most from Direct Lake mode. Direct Lake reads directly from Delta files in OneLake without requiring a refresh or maintaining a copy of the data in the VertiPaq in-memory engine. There is no refresh management overhead, no import storage cost, and query performance that takes advantage of the VertiPaq engine's optimisation without the cost of a full data load.
Dimension tables, the ones with tens of thousands or a few million rows, are small enough that Import mode is practical. And Import mode on dimension tables offers capabilities that Direct Lake does not currently support for those tables, including user hierarchies and full Power Query transformation capabilities for creating derived columns.
The composite model pattern combines both: Direct Lake for the large fact tables where refresh management would be expensive and unnecessary, Import for the dimension tables where the additional modeling capabilities matter most. The relationship between an Import dimension table and a Direct Lake fact table is a strong relationship, persisted by the VertiPaq engine, rather than the weaker join-on-the-fly relationship that DirectQuery and Import combinations required previously. This makes the composite model perform significantly better than the older DirectQuery-Import combination.
One important availability note: the ability to convert Direct Lake tables to Import within a composite model was not yet in the production environment at the time this content was produced. It was expected to deploy in summer 2026. If this feature is not yet visible in your environment, checking the Microsoft Fabric release notes will confirm its current availability status.
User-Context-Aware Calculated Columns: What They Enable
Calculated columns in Power BI have historically been evaluated at refresh time, which meant they could not reference user-specific information like the current user's language, region, or identity. That limitation made certain types of personalisation impossible at the data layer.
Direct Lake on OneLake introduces a new expression context property for calculated columns called User Context. When a calculated column is set to User Context, it is evaluated at query time rather than refresh time, and it can reference DAX functions that depend on the current user's session, including username, user culture, and custom data attributes.
The most immediately practical application of this is multilingual semantic models. A calculated column set to User Context can use the UserCulture DAX function to detect the current user's browser locale and return data values in the appropriate language. A user in the United States sees product names in English. A user in France sees the same column values in French. A user in Brazil sees them in Brazilian Portuguese. The semantic model serves the right language to each user automatically without requiring separate models, separate reports, or any action from the user.
Microsoft describes this as completing the full multilingual semantic model stack: data translations via user-context calculated columns, metadata translations for table and column names, and format string conversion for locale-specific number and currency formatting. All three layers are now available within a single semantic model.
Beyond multilingual reports, user context expression mode opens up a range of personalisation scenarios that previously required workarounds, including multi-tenant models that surface different data to different users and RLS configurations that reference the current user's attributes dynamically.
An AI Agent That Builds Enterprise Semantic Models
The most striking development in this space is not a new feature of the semantic model itself but what can now be done to create one. The Power BI Modeling MCP Server, available through VS Code, allows an AI agent to build a complete enterprise-grade semantic model from a business requirements specification.
In a live demonstration, an AI agent given access to a lakehouse and a set of business requirements expressed in natural language, accompanied by a modeling guidelines document defining best practices, produced the following without any manual modeling steps:
- Renamed tables to business-friendly names
- Renamed 120 columns across all tables
- Created relationships between tables, including inactive relationships for role-playing dimensions
- Built DAX measures for time intelligence including year-over-year growth
- Hidden technical foreign key columns not needed by business users
- Written business definitions on every table, column, and measure
The entire process took under a minute. The resulting semantic model was built on Direct Lake on OneLake, meaning it required no data refresh. It was immediately queryable across whatever volume of data existed in the lakehouse.
This is meaningful for two reasons. First, it removes the argument that semantic model creation is too time-consuming to justify the investment. The modeling work that previously consumed seventy to ninety percent of a BI project's time can now be compressed dramatically. Second, it addresses the consistency problem that large organisations have with semantic model governance. Architecture documents and modeling guidelines exist in most organisations but are inconsistently followed by individual developers. An AI agent follows a guidelines document more consistently than a distributed team of developers does, which means the models it produces are more architecturally uniform.
For teams already exploring AI-assisted Power BI development, our blog on connecting Power BI to Claude AI using the MCP Server covers how the MCP layer works in practice for DAX generation and model interrogation directly inside a Power BI file.
TMDL in the Browser: Developer-Grade Editing Without Desktop
One additional update worth noting is the availability of TMDL, Tabular Model Definition Language, directly in the browser through a VS Code IDE embedded in the Fabric web experience.
TMDL represents the full semantic model definition as editable script. Rather than clicking through UI dialogs to make changes one at a time, TMDL allows bulk edits across all tables, columns, measures, relationships, user hierarchies, and translations in a single view. Multilingual translations for multiple languages can be added in the same TMDL script simultaneously rather than through separate translation dialogs.
The significance of TMDL being available in the browser, rather than only through Power BI Desktop or a local VS Code installation, is that it removes the desktop dependency for advanced semantic model editing. Microsoft has explicitly stated that the web experience now supports composite models better than Desktop does, which indicates where the development investment for the modeling environment is being directed.
Where Versich Fits
The Power BI updates covered in this article are architectural changes, not just feature additions. OneLake Security changes how governance is implemented across a Fabric environment. The shift from Direct Lake on SQL to Direct Lake on OneLake changes the foundation of the semantic model architecture. Composite models change how large-scale models are designed. And AI-assisted model creation changes how that design work gets done.
For organisations that need to evaluate what these changes mean for their current Power BI environment, determine whether migration from Direct Lake on SQL to Direct Lake on OneLake is the right next step, or implement OneLake Security correctly across an existing Fabric architecture, these decisions benefit from the kind of expertise that comes from working across multiple Power BI environments at enterprise scale.
Versich's Power BI consulting services cover semantic model architecture, governance implementation, and ongoing environment optimisation. For organisations that need support maintaining and evolving an existing Power BI environment as these platform changes continue to ship, our Power BI support services provide direct access to senior consultants rather than a generic help desk.
Conclusion
The Power BI semantic model updates shipping through Microsoft Fabric in 2026 are not incremental improvements. They are foundational changes to how security is governed, how data models are architected, how the platform scales across enterprise environments, and how the creation work that has historically consumed most of a BI project's time gets done.
OneLake Security GA simplifies governance in a way that enterprise customers have needed for years. Direct Lake on OneLake is the architecture to build on going forward. Composite models remove the constraint that forced a choice between Direct Lake performance and Import flexibility. And AI-assisted semantic model creation removes the bottleneck that made serious modeling work expensive and inconsistently executed across large organisations.
For Power BI teams that have built their environments on earlier architectural assumptions, understanding what these changes mean in practice and where to prioritise updates is the work that determines whether the platform continues to deliver at the level the business expects from it.
