Calculated columns in Direct Lake Semantic model made its way. But do should one use them other than context aware calculated column use case
Power BI's August 2026 release brought a long list of updates. Modern visual defaults, a generally available date picker for slicers, matrix visual improvements, and OneLake file URLs for report visuals. But the one that caught my attention is Direct Lake calculated columns, now in preview.
What's new
You can now define calculated columns directly in your semantic model using DAX, in web modeling or Power BI Desktop, without changing the table storage mode or touching data upstream. No preview switch to flip. Open a Direct Lake on OneLake semantic model in the web or in Desktop, add a calculated column, and start writing DAX.
Key behaviors
- Only user context expression context is supported.
- User context aware DAX functions like USERCULTURE() and USERPRINCIPALNAME() work.
- Columns don't materialize. They get evaluated at query time, more like a measure than a traditional calculated column.
- Security context is respected. RLS and OLS still apply.
- Columns can't be used in relationships, since they never materialize into a fixed value.
- Expressions that skip user aware functions or secured columns behave like any other DAX calculated column.
Trying it out
I tested this on one of my Direct Lake models. You can confirm a model is Direct Lake by opening the semantic model, going to the model settings, and checking that Direct Lake behavior is set to automatic.
The first column I built was a simple one. In the fact sales table, I created Gross Sales Calc as sales quantity multiplied by unit price. Straightforward, no user context involved.
gross sales calc = factsalesgold[Qty]* factsalesgold[UnitPrice]
The second column used the user-context-aware side of the feature. In the product dimension, I have a Brand column that I wanted to mask depending on who's viewing the report. I wrote an IF condition around USERPRINCIPALNAME(), so the brand only shows for a specific email. Everyone else sees "All" instead. This can help us implement data masking based on the user.
brand new = if(USERPRINCIPALNAME() ="[email protected]", [Brand], "All")
I built a report with a table visual and added Brand, the original Gross Sales, and the new Gross Sales Calc. The values matched and the grand total lined up too, which confirms the calculated column is producing correct results at query time.
For the Brand column, when I was logged in as a user other than the one hardcoded in the DAX, every row showed "All." Switching the email in the DAX to my own address and refreshing brought the actual brand names back. That's the masking behavior working as intended. One set of users sees brand detail, another sees a generic placeholder, all from the same column.
Email changed in DAX formula to my login
My take
Adding calculated columns in DAX for Direct Lake gives a lot of flexibility and feels like an easy option. But that also means logic that should have stayed in the Gold layer is now moving into the semantic model. On top of that, these are runtime calculations, so they come with a performance cost. Keeping all this in mind, it's better to avoid calculated columns in Direct Lake mode where possible. Outside of user context aware scenarios, I'd still push that logic back to Gold. Calculated columns in the semantic model are harder to govern, harder to reuse across reports, and easy to lose track of.
But for USERCULTURE(), USERPRINCIPALNAME(), and similar user aware functions, there's no real alternative. Those have to live in the semantic model, the same way measures do. This preview finally gives Direct Lake models a way to handle that without switching storage mode.
If you're on a Direct Lake model, it's worth trying. Set up something small like the brand masking example, see how it behaves with different users, and get a feel for where it fits in your architecture.
I have covered the same in a video. Please have a look.
https://www.youtube.com/watch?v=Bi4bMVrpFCo&list=PLPaNVDMhUXGYo50Ajmr4SgSV9HIQLxc8L
Reference
Full details are in the official release note: Power BI August 2026 Feature Summary, Direct Lake Calculated Columns (Preview) section, and the Power BI Desktop documentation on calculated columns.
Power BI August 2026 Feature Summary | Microsoft Fabric Community