DAX UDFs just went GA, there’s a new REST API for running DAX queries at scale, and a network security feature most people haven’t even heard of yet is quietly changing how enterprises govern their semantic models. In this episode of Fabric Insider, I sit down with Kay Unkroth, Program Manager on the Power BI side of the Fabric organization, focused on semantic models and the Analysis Services engine, to unpack all three.
Meet Kay Unkroth (Video: 0:28)
Reza: Thank you for joining us. Would you introduce yourself, who you are, what you do, and which part of the product you’re responsible for?
Kay: My name is Kay Unkroth and I work on the Power BI side of the Fabric organization. My focus is really on semantic models and the Analysis Services engine. I’m a program manager in that area, so I talk to customers, take their requirements and feature requests, organize them, and bring them to the engineering team. Then we define what the feature should look like in the product, see it through execution and rollout, and I get to explain to customers how to use it best. That’s the job in a nutshell, though there’s a lot more under the covers than that.
What Are DAX UDFs, and Why Do They Matter (Video: 1:31)
Reza: Talking about the Fabric semantic model in Power BI specifically, we’ve had a lot of announcements recently, some really interesting ones, some just in the past few days. One is DAX UDFs going GA. Everyone who’s worked with Power BI understands what DAX is, but not everyone is familiar with what a UDF is. Can you explain that in simple terms, what it is and why we should use it?
Kay: In the simplest terms, it’s what the name suggests, you can define your own function that you can then use in your expressions, which helps you streamline or simplify complex expressions. DAX expressions can be quite overwhelming sometimes, and if you take critical components out of those expressions and pack them into UDFs with meaningful names, your expressions become more readable. Once you have a function defined, you can call it in multiple expressions too, which reduces the overall complexity of your semantic model.
Personally, I think DAX UDFs are one of the most innovative improvements to the DAX language in a decade, that’s how groundbreaking I view user-defined functions. The naming is a bit unfortunate, since we already have User Data Functions, which we also call UDFs, and now we have DAX UDFs too. I personally prefer calling them DAX UDFs specifically, to make clear this isn’t the other UDF.
Reza: Right, the UDF in Fabric isn’t the UDF in DAX. From my point of view, it creates two main benefits, readability, I can get part of the expression as a UDF, give it a name, and know exactly what’s happening without reading a long DAX expression. And reusability, of course.
One of the things I found in your recent announcement about DAX UDFs going GA was optional parameter availability. How is that helpful, what can it do for us? (Video: 4:20)
Kay: Optional parameters were feedback we received during the public preview phase, and I was very happy we were able to put this in for general availability. It helps in scenarios where your expression has conditional pathways, however complex you want to construct it. Sometimes you need two, three, or four parameters, and without optional parameters, you’d need to create multiple expressions that basically duplicate large portions of logic. It’s better to define one signature, then define whatever parameters you want and react accordingly within your expression.
I’d recommend every model creator look strongly at UDFs, they provide so many advantages. Reusability certainly within a single semantic model, but also across the entire semantic layer, when you look at Git integration and TMDL files, you can pack your UDFs into a TMDL file and include it in every semantic model that needs those functions. They also support IntelliSense fully, so if you write meaningful descriptions, or use Copilot or your favorite AI tool to write good descriptions for you, that tremendously helps when sharing your functions and intellectual property with others on your team, or across an entire organization.
DAX UDFs Work Across Every Storage Mode (Video: 6:57)
Reza: Now, one thing about DAX UDFs, does it matter how I create my semantic model, Import, DirectQuery, Direct Lake? Is it supported only in certain scenarios?
Kay: No, it generally doesn’t matter what storage mode your tables are underneath. The DAX language is independent of that, and for the most part the query language works in the formula engine on top of the storage engine. So you have your metadata, your tables, your columns, your other expressions. You can call UDFs within UDFs too, for example. You’re not constrained to a particular storage mode.
Reza: Fantastic. I’d encourage everyone watching to go search around for DAX UDFs, people in the community have created a lot of interesting functions already.
Execute DAX Queries API and the Arrow Format (Video: 7:58)
Reza: The other announcement, not brand new, it was a few weeks ago, but got a good reaction from the community, was the ability to execute DAX queries from an API, using REST API, notebook, or any other coding approach. Can you explain the use cases for this, and why you built it?
Kay: The ability to execute DAX queries through a REST API isn’t new, we shipped that quite a few years ago, that’s the original Execute Queries API, and it’s very successful, high adoption, available for example in Power Automate and other low-code, no-code environments that can load our AS client libraries.
The drawback of that API is that it returns results in JSON. That works well for smaller result sets, but parsing JSON just to get to your values isn’t optimal. Arrow is a better format, it’s a stream, we use it ourselves for the DAX query view, wherever we want the highest performance without relying straight on XMLA and our AS client libraries.
As we integrated that API into our own features, the next step was making it public so customers could consume it in their own solutions. Because Arrow isn’t readily consumable in a low-code, no-code environment (Power Automate doesn’t have a straightforward way to handle an Arrow stream right now), we put it into a new API rather than the existing one. That’s how we arrived at the Execute DAX Queries API, sitting side by side with the original Execute Queries API. I hope the naming isn’t too confusing.
What it does is basically the same thing, send a DAX query as a request to our API endpoint, and you get back an Arrow stream you can process directly. It has real advantages in Python environments, it’s very easy to process and materialize into a Delta table, for example. I’ve published some tutorials in the Power BI developer section, one takes David’s mid-tier service .NET solution and swaps out the XMLA portions for the Arrow API. Another walks through Python and Fabric notebooks specifically. And a new one coming shows PowerShell, which is a bit harder since parsing an Arrow stream directly in PowerShell is tricky, but I provide additional types to solve that. That last tutorial also shows sending multiple EVALUATE statements in one query and getting multiple Arrow streams back in the response, useful if you’re running into request limits, I believe it’s 120 requests per user per minute, so combining multiple evaluates into one request can raise your effective ceiling. Just stay within reason though, don’t put thousands of evaluates in one query.
One important note: this API requires a Fabric capacity or Premium capacity, it doesn’t work on shared capacity. That was also the motivation for bringing this API forward, high performance for our own components as well as for customers, and getting past limitations the original Execute Queries API has, specifically around result set size. The original is documented at around a million values or 100,000 rows, those limits don’t apply to the Arrow API. So if you want to download a large table from a model through a REST API, the Arrow API is the way to do that.
Reza: So in short, this is a new API, the difference is the response type, Arrow instead of JSON, giving better performance and fewer limitations. But because it’s not consumable in low-code, no-code environments yet, that’s why it needed its own API.
What This API Is Not For (Video: 14:51)
Reza: We’ll make sure to put links to documentation for people to use it. Having this API, this was one of the questions I got in the community when I posted about it on LinkedIn, doesn’t mean we’re now supposed to go run our DAX queries from a notebook by default, right?
Kay: No, it doesn’t mean that at all. It just means the ability exists, and you can do plenty of things with it if you ever need to. You can monitor your semantic model using INFO functions, for example, in a DAX expression run through a notebook, or many other things. You might want to export part of your data, and that API gives you the ability to do that.
Outbound Access Protection (OAP) Explained (Video: 14:56)
Reza: The other thing you’ve been working on, which is quite interesting and not many people are aware of, is OAP, Outbound Access Protection. Can you tell us what that is and why we should care?
Kay: Outbound Access Protection is a network security feature, if you want to frame it that way. It essentially lets you limit the data connections that a semantic model, or another artifact inside a workspace, can use to connect to specific endpoints or data sources. If you’re concerned that in a given workspace your model creators might bring in unauthorized data, as a workspace admin you can configure an Outbound Access Protection policy that says only the lakehouses in a specific other workspace are allowed. Then you can be assured that model creators in that workspace can only connect to that specific whitelisted data source or sources.
The other relevant scenario is closing data leaks. I have an example in my blog article where, perhaps unbeknownst to the model creator, certain filter values can flow across boundaries to a data source you don’t want sensitive information landing in, since with every modern data source you have a query that can carry sensitive values along with it. This extends to intentional data exfiltration scenarios too, making sure nobody inside your sensitive workspaces can construct a semantic model that pushes data out to another data source.
I’d put a caveat on that though: Outbound Access Protection doesn’t protect you from inbound connections. It’s not restricting who can connect to your semantic model and query it, say, with the Arrow REST API, and pull a whole table down that way. That’s part of a bigger network security story that will unfold over time, one of the areas I work on. The next piece coming, hopefully next week, is the preview for the report side: when a report sits in a workspace that’s OAP enabled, we constrain that report so it can only talk to its local semantic models, not any others. So if you have a report against a model in DirectQuery mode, you can be assured that report itself doesn’t go and connect to or leverage other data sources that aren’t authorized. In enterprise environments that’s a highly sought after feature, and semantic models and reports pretty much always have to go hand in hand for us on the Power BI side.
OAP as Governance, Not Just Access Control (Video: 18:42)
Reza: So when we look at OAP, it goes beyond individual user access. For example, I could be a report builder with access to a semantic model in a workspace, and I could go build a semantic model that combines things, but OAP goes beyond my access level, it says the semantic model of this workspace should not be combined with that workspace. That’s a level of governance on top of individual access.
Kay: Exactly. You’re basically putting the administrator in charge of allowing data sources and blocking those you don’t want, set at the level of the workspace, controlling which sources it can connect to. And of course this coming to reports as well is also great news.
Redesigning the Semantic Model Settings Pane (Video: 19:40)
Reza: You’ve also been working on changes to the semantic model settings page, which is quite interesting, since it never really had a great UI. Tell us about that.
Kay: The semantic model settings have evolved over time. The current version of Power BI is now 10 years old, if I’m not mistaken, and settings evolved along that journey. We now have almost 30 dataset settings, well, we should call it semantic model settings now, and it was time to restructure and modernize. In Fabric land, we’re putting the settings into the right-hand settings pane, which is one of the goals of this improvement.
It is a significant change though. If you’re accustomed to configuring your semantic models one way, and now we’re flying it out on the right side instead of a separate page, that can be hard for users, so we’re going baby steps. The first preview didn’t even enable it by default, we just left the existing settings page as-is and gave you a link to check out the new one and give early feedback. We got good feedback, though one major issue that came up was losing the ability, within the pane, to flip between semantic models. In the existing settings page you get a list of models in the workspace and can switch between them, in the right pane that list isn’t there. I’m still in touch with the team that owns the shell to see what we can do, one option might be selecting from the workspace list, but that’s still being worked out.
Beyond that, we’re shifting to the right pane, and we also plan to consolidate sections that logically belong together, and improve critical sections, particularly data connections and gateway configuration.
Reza: It’s also important to have everything about the semantic model in one place, previously it was a bit hard to locate things, where’s security, where’s refresh settings. One big scenario is web modeling too, where you model something and then need to bind a new data source. With the old settings page, you’d lose your whole web modeling context, jump into the page, configure it, then reopen web modeling and navigate back. With the pane, you configure the connection and it just goes away, without losing your work context.
Kay: Exactly. And personally, I also just like the settings pane better, it’s prettier, with collapsible sections you can organize. It’s a more modern look and feel, and semantic models certainly deserve that. But semantic models are the most used artifact in Fabric and Power BI across the board, reports are closely behind, these are the two heavy hitters, so changing such a fundamental experience is something we take really cautiously.
The plan is baby steps: first get users familiar with having it in the settings pane, then consolidate sections that logically belong together, then tackle the bigger pieces, we’re still debating whether to improve data connections first or the refresh schedule first, those are the two areas where we get the most feedback.
Reza: A lot of people would love any improvement to the refresh schedule configuration.
Kay: Yeah, when we improve things there, aligning it more with the Fabric scheduler, that’s all part of what we internally call the Trident unification, Trident being the old internal code name for Fabric.
Time Intelligence and Custom Calendars (Video: 25:07)
Reza: You also mentioned upcoming features you’re working on, time intelligence and calendars.
Kay: Custom calendar has been in preview for quite some time now, and we’ve gotten good feedback from the community during that time.
Reza: Time intelligence is what, at least 60% of BI? I haven’t seen a single model that doesn’t have some form of time intelligence.
Kay: Right, and when we look at time intelligence, we have auto date tables, classic date tables, and now custom calendars, and the configuration isn’t as intuitive as it should be, that’s clear feedback we’ve received. I’m working on improvements in this area that will hopefully ship later this year, to make the custom calendar experience more user friendly and intuitive, because I think custom calendars represent as fundamental an improvement to time intelligence as UDFs are to DAX generally.
Anyone who works with time intelligence has noticed some time intelligence functions perform better than others, and with custom calendars there are significant performance improvements under the covers. But you have to go through certain steps to define the calendar correctly, otherwise you don’t get to leverage that improvement. Right now it’s not very intuitive, you really need to know what you’re doing before you approach it. I think you should just be able to say “I want a custom calendar” and have the UI guide you through to a successful outcome. That’s one of the things I’m currently working on getting nailed down, ironing out a few more things before we can finally declare GA for this feature too.
Reza: Custom calendar is amazing. Whenever I talk about it, even in a video I published when it first came into preview, people love it. The only thing, exactly as you mentioned, is that the configuration could be simpler and more user friendly, which I’m sure your team can build a really nice UI for.
Where to Find Kay and Closing Thoughts (Video: 27:58)
Reza: What’s the best way for people to connect with you?
Kay: When people want to reach out, ideas or comments in the blog post is probably the best way, rather than email.
Reza: Sounds good. We’ll put those links down in the description below. Thank you for your time, it was really great.
Kay: Thank you for having me, it was great.
Summary
DAX UDFs going GA with optional parameters, a new Arrow-based REST API for high-performance DAX queries, Outbound Access Protection quietly reshaping semantic model governance, and a settings pane redesign years in the making. If you’re building semantic models in Power BI or Fabric today, this episode is worth a full watch. If you have questions on any of these features, drop them in the comments, Kay reads them.
Related Reading on RADACAD
- Power BI Direct Lake, What Is It and Why It Is Important
- DATEADD vs PARALLELPERIOD vs SAMEPERIODLASTYEAR: A DAX Time Intelligence Question
- Power BI Date or Calendar Table: Best Method, DAX or Power Query
Previous Fabric Insider Episodes
- Ep. 1 Wilson Lee, Mirroring/Copy Job/SAP: https://youtu.be/LRrqxRP2ltk
- Ep. 2 Zoe Douglas, Visualization Updates: https://youtu.be/PDEYc37VbE4
- Ep. 3 Miguel Escobar, Power Query/Dataflows: https://youtube.com/watch?v=mgxEYGKgYis
- Ep. 4 Santhosh Kumar Ravindran, Spark Performance: https://youtube.com/watch?v=VayYW4REKzc
- Ep. 5 Christian Wade, Semantic Models: https://youtube.com/watch?v=zndWuBB1JTo
- Ep. 6 Yitzhak Kesselman, RTI/Fabric IQ: https://youtu.be/euaMnOWD81Y
- Ep. 7 Rie Merritt, MVP Program: https://youtu.be/d6iAp7clwzc
- Ep. 8 Hasan Abo-Shally, MCP Servers/CLI: https://youtube.com/watch?v=TTqyHBAHuP4
- Ep. 9 Wee Hyong Tok, Data Integration/ETL Future: https://youtube.com/watch?v=nDPufHNSC5Y
- Ep. 10 Mohammad Ali, Next Evolution of Power BI: https://youtube.com/watch?v=jpGtEvKty-k
- Ep. 11 Sachin Patney, Fabric Apps/Rayfin: https://youtu.be/PjV1bc1Rqwo
- Ep. 12 Josh Caplan, OneLake Updates: https://youtu.be/R5i-CigLwSM
Full playlist: YouTube Podcast: Spotify Series page: radacad.com/category/fabric-insider-2026
About Reza Rad
Reza Rad is a Microsoft Regional Director and a 16-year consecutive Microsoft Data Platform MVP, recognized as one of the world’s leading voices on Power BI and Microsoft Fabric. He is co-founder of RADACAD, a Microsoft Gold Partner delivering Power BI and Fabric consulting and training to organizations across 80+ countries, and co-founder of the Difinity Conference and the Power BI & Fabric Summit. Reza has authored more than 10 books on Power BI and Microsoft BI technologies, published over 1,000 technical articles, and personally trained thousands of data professionals worldwide. Whether you need a full analytics architecture built from the ground up, a stuck DAX formula or performance issue solved, or a team trained from the basics to advanced Fabric implementation, Reza and the RADACAD team offer both hands-on consulting and structured training to get you there. Learn more at radacad.com.
Reza is author of more than 14 books on Microsoft Business Intelligence, most of these books are published under Power BI category. Among these are books such as Power BI DAX Simplified, Pro Power BI Architecture, Power BI from Rookie to Rock Star, Power Query books series, Row-Level Security in Power BI and etc.
He is an International Speaker in Microsoft Ignite, Microsoft Business Applications Summit, Data Insight Summit, PASS Summit, SQL Saturday and SQL user groups. And He is a Microsoft Certified Trainer.
Reza’s passion is to help you find the best data solution, he is Data enthusiast.
His articles on different aspects of technologies, especially on MS BI, can be found on his blog: https://radacad.com/blog.