I usually do not write about announcements and new features until we have had time to try and test them in the real world. However, there are always exceptions, and some of the announcements at the Microsoft Fabric Conference 2025 fall into this category because I have worked with them enough to provide hands-on feedback.

In short, these are the topics I am covering in this blog post:

  • Direct Lake and Import mode
  • Calendars in DAX
  • User-Defined Functions (UDF) in DAX

Direct Lake and Import mode

One year ago, after two conferences where the announcement of Direct Lake was misleading to many attendees, I felt the need to write a comparison article between Direct Lake and Import to clarify several misconceptions. Last week, I presented a “Choosing between Import mode, Direct Lake, and composite models” session on stage. I did not change my mind: Microsoft released new features and announced a roadmap that will make it easier to make the right choices, case by case.

  • Two flavors of Direct Lake: Direct Lake on SQL endpoint is the “legacy” version of Direct Lake, which falls back to DirectQuery when there is not enough memory to complete a query or when SQL-based security must be enforced. Direct Lake on OneLake is a new mode that will be integrated with OneLake security.

    Creating Direct Lake models in Power BI Desktop: A model in Direct Lake is always stored on the cloud, and it does not store anything on the local computer. However, this integration opens up the possibility of using external tools and simplifies the introduction of other features, like the next one.
  • Composite models with Direct Lake and Import mode: In the same model, you can mix tables in Direct Lake mode (also coming from different sources) and in Import mode. While this seems to be another case of composite models, it is very special because it does not create “limited” relationships between tables from different data sources. All the tables are managed by the same VertiPaq storage engine, using “regular” relationships instead of limited ones.
    The table in Import mode does not have the current limitations of tables in Direct Lake: calculated columns, calculated tables, and user hierarchies in MDX (required for Excel consumption) are all available and supported.
  • Materialized views on Lakehouse: It will be possible to materialize a view on Lakehouse using SQL statements. This feature does not depend on the semantic model and makes the materialized view available as a Delta table to any Fabric workload, including semantic models. While an accurate timeline has not been provided, this should be the first feature released to address the need for columns and tables specifically designed for a semantic model.
  • Calculated tables and calculated columns in Direct Lake: It will also be possible to create calculated tables and calculated columns based on tables connected through Direct Lake. We do not have more details; we only know that the calculated tables will be released before the calculated columns. These features will address the need for physical structures required by “aesthetic” requirements of a semantic model: combine first and last name in one column, show a month name in three letters, create a categorization of elements based on user-defined ranges, just to name very common ones. From an organizational point of view, requiring these additional columns from the data engineer team responsible for maintaining the Lakehouse structure – with or without the use of materialized views – would introduce unnecessary development overhead. While some organizations will be happy to apply strict rules for transforming data only in the Lakehouse, many others would like to choose a pragmatic and productive approach, using calculated tables and columns wisely.

My 60-minute session was well attended at the conference, but many people were unable to enter the room. I will record and publish a video with the content of the session in a few weeks, as soon as the new Direct Lake + Import feature becomes available in public preview. Stay tuned!

Calendars in DAX

The semantic model will introduce the notion of “Calendars”: any Date table will have one or more calendars, based on the columns of the Date table itself. This way, the DAX time intelligence functions will be aware of the specific structure of the Date table, making it possible to operate on any calendar, including week-based calendars like ISO and 4-4-5.

From a DAX standpoint, the changes are minimal: instead of specifying the Date column of the Date table in a parameter, we will specify the Calendar name:

CALCULATE (
    [Sales Amount],
    DATESYTD ( Fiscal445 )
)

We will also have new DAX time intelligence functions to support weeks as time units, like DATEWTD.

This feature is not yet available in public preview, and it will take a few months (hopefully not too long) before you can use it. We will publish new articles and videos about this feature by then. Moreover, external tools like Bravo for Power BI will leverage this new feature to improve the automatic creation of a Date table and time intelligence measures.

User-defined functions (UDF) in DAX

The last announcement is the more important one for the long term. You will be able to write and use functions defined in DAX. These are called User-Defined Functions (UDFs), which you should not confuse with User Data Functions in Azure: the DAX UDFs exist in semantic models, are written, and can be consumed in DAX. The User Data Functions exist on the Fabric workspace and can be used by any Fabric workload, but the User Data Functions are written in Python and cannot be used by DAX. To simplify it, we will use “DAX UDFs whenever there is a risk of confusing the two tools.

For example, you could use a library of SVG custom visuals like the ones presented by Kurt Buhler in a previous article by just invoking a function:

Timeline SVG = 
TimelineSVG ( [Days to Deliver], [Days in Progress] , [OTD Status] = "WIP", [Days to Requested Delivery] )

The DAX function definition syntax resembles the M syntax:

FUNCTION ConvertDateToEpoch =
(    
        // The date to convert
        dateTime : DATETIME
) =>
    DATEDIFF ( DATE ( 1970, 1, 1 ), dateTime, SECOND

FUNCTION ConvertEpochToDate =
(
    // The epoch to convert
    epoch: INT64
) =>
    DATE ( 1970, 1, 1 ) + ( epoch / 86400 )

FUNCTION TimelineSVG =
(   _Actual: Scalar Val,
    _WIP: Scalar Val,
    _IsSafe: Scalar Boolean,
    _Target: Scalar Val
) => 
    ...

DAX UDFs will have the biggest long-term impact compared to other announcements at the Fabric Conference 2025. We will change how we write DAX code in small and large models. We will see generic libraries of functions that can be used in any semantic model and model-specific functions, making it easier to share a central definition of critical business logic shared by many model measures.

It will take a few years before we see a pervasive adoption of this feature in any semantic model, but I expect that we will look at DAX code without functions like we look at DAX code without variables today.

Like the Calendars, UDFs are not available yet, but a public preview should be available in a few months—even if an accurate timeline has not been provided. Expect huge support from the community regarding tools, examples, and content that we will produce as soon as the feature is available in public preview. There is no timeline, but it should be a few months!