Enabling AI integration scenarios

As I mentioned in my first post, Fabric semantic models are very feature-rich and what can be mapped to Ossie are just tables and relationships. So why bother? One scenario is to allow Snowflake agentic interfaces to interact with Fabric semantic models along the following diagram, which was actually a scenario a client was asking about in a current project:

User
|
| “What was the revenue by product last quarter?”
|
v
Snowflake AI Agent / LLM
|
+—- reads —-> Ossie model
| |
| +– Revenue = metric
| +– Product = dimension
| +– relationships
| +– synonyms
| +– AI instructions
|
| Agent understands what the user means
|
v
Fabric query tool / API
|
| DAX query
|
v
Power BI Semantic Model
|
v
Result
|
v
AI Agent
|
v
“Total Revenue was $12.4B…”

In that diagram, the Snowflake agent composes the DAX, so it needs enough context to do that well. Microsoft’s guidance is that DAX generation against a semantic model draws on the model’s metadata plus its Prep for AI configuration, covering synonyms, descriptions, AI instructions, verified answers, and report visual metadata.

Another option via MCP protocol

Another integration option would be Snowflake agentic interface delegating to a Fabric Data Agent using the MCP protocol. This implementation keeps a single definition inside Fabric. Publishing a Fabric data agent exposes it as an MCP server with one tool, and Snowflake Cortex Agents can register external MCP servers over OAuth. The data agent is generally available, the MCP consumption path is currently documented as preview, and there is no prebuilt Snowflake connector, so either route is a custom integration.

What’s supported?

The Microsoft documentation leaves us with the false impression that the setup is pretty straightforward. However, a real-life project proved otherwise because the integration complexity depends on how the table was created. If the table uses EXTERNAL_VOLUME = ‘SNOWFLAKE_MANAGED’, a shortcut is not possible, because those files sit in Snowflake’s own storage which OneLake shortcuts don’t support (only S3, S3 compatible, GCS, or ADLS Gen2 are supported). In other words, you don’t create a shortcut to Snowflake. Instead, you create a short to the underlying storage. By the way, Fabric Mirroring carries the same requirement for Iceberg tables.

Besides S3, GCS, and ADLS Gen2, Snowflake tables can be configured to save data directly into Fabric OneLake. Of course, this defeats the purpose to keep the data where it’s processed (more than likely on AWS), but it’s allowed in your environment, it probably could be the easiest solution.

If the data is saved in external storage to Fabric, the Microsoft supported path is an external volume on your own S3, GCS, or ADLS Gen2 storage. Run SELECT SYSTEM$GET_ICEBERG_TABLE_INFORMATION(‘<table>’) to confirm the metadata location, then create the shortcut in the Tables section of your lakehouse and point it at the table folder, the one containing /metadata and /data rather than the metadata folder itself. OneLake generates the Delta log automatically, usually within 5 seconds to 2 minutes. A few limits worth planning around: Iceberg V2 only, fewer than 5,000 commits, no bucket, truncate, or void partition transforms, and no support on workspaces with private links enabled.

Authentication options

So, now that we know that Snowflake is out of the picture, the shortcut must authenticate directly against the storage provider. In case of S3 (the likely external storage outside the Snowflake managed storage), Fabric authenticates using Entra, AWS issues short-lived STS credentials through OIDC trust, and Fabric accesses the Iceberg-backed Parquet files in S3 via a OneLake shortcut. This eliminates AKIA key management while maintaining full CloudTrail auditing and aligns with enterprise cross-cloud security best practices.

The table below illustrates the authentication options for S3, with the Entra Service Principal being the current recommended approach by Microsoft:

Creating Microsoft Entra service principals presented a challenge in our project because of the additional security clearance required. Note that Snowflake supports additional authentication options, such as Apache Iceberg REST Catalog Integration, but they are not currently supported by Fabric.

On the downside, the user interface is lost once data is exported. Consequently, the user must modify the underlying DAX query—an option a client immediately dismissed after learning about it—if they want to make changes like adding additional fields. This would be a great option if there were a way to bring that interface back. Even better: let users pick fields from a Field List as they do with pivots, but output directly to a table. What could be simpler?

It dawned on me that while waiting on Microsoft, I could fill these gaps myself by creating an Excel add-in. That is how the Semantic Table add-in was born. It picks up right where default connected tables leave off.

Others have already explored this path, such as Jörg Schmidt with his PBIXL add-in. However, I’ve taken a different implementation approach focused on these core features:

• Flexible Integration: Supports both existing connected tables (created using Microsoft’s Insert Table) and tables built from scratch.
• Field List UI: Provides a familiar PivotTable-like Field List directly within the table context.
• Dual Execution Modes: Supports both Deferred Mode (apply updates manually to prevent constant re-querying) and Interactive Mode (live field updates).

You can download the Semantic Table add-in directly from the GitHub Repository. I hope the community finds it useful, and I’m looking forward to your feedback.

Fair warning: the add-in is likely as buggy as Atlanta in the summer, so use it at your own risk!

So rather than fighting Excel, let’s look at the options Microsoft provides for bringing governed Power BI data into it. In particular, I’m interested in getting data from Fabric semantic models into Excel.

Many things have changed over the years in the data analytics space, but semantic models have stood the test of time. The technology has changed—from multidimensional OLAP cubes to tabular models and now Power BI and Fabric semantic models—but the basic idea has remained remarkably consistent: put business logic and governed data in a centralized model, then let different tools consume it.

Here are the main options Microsoft provides today to make data from semantic models available in Excel:

Export from published reports

This is probably the most obvious option. A Power BI or paginated report can serve as the interface for users, with Excel being the ultimate destination. This approach can be particularly attractive when the organization wants to take advantage of everything Power BI has to offer: report sharing, subscriptions, dynamic subscriptions, annotations, and other collaboration features.

For example, a report can be designed specifically for a group of users and distributed through a subscription. Paginated reports provide even more flexibility when the objective is to produce formatted Excel or CSV files on a recurring basis.

The problem is that Power BI report exports have limitations. Depending on the report and export method, there are limits on the amount of data that can be exported. Paginated reports are considerably more flexible for large-scale tabular output. There is also an architectural question: do we really want to build a Power BI report whose primary purpose is to get data into Excel? If the report exists only because Excel is the final destination, we’re arguably using the report layer as an unnecessary intermediary.

The better architecture is often: Semantic model → Excel rather than: Semantic model → Power BI report → Excel

Excel PivotTables and PivotCharts

Excel has supported PivotTables since the 1990s and OLAP PivotTables for more than 25 years. This is hardly new technology. And that’s part of the appeal. The experience is familiar to generations of Excel users. A user can connect to a Power BI semantic model, select fields, slice and dice the data, and create PivotTables and PivotCharts without building a Power BI report.

The problem is that the fundamental PivotTable interaction model has changed surprisingly little. Slicers and timelines improved the experience, but the overall model still feels much closer to the Excel/OLAP world of the early 2000s than to today’s Power BI experience. As such, it generates suboptimal MDX queries although not as bad as Power Query in import mode.

For an Excel user, however, there is one particularly interesting capability: customizable drillthrough. When a user double-clicks a PivotTable cell, the semantic model can provide a detailed table of the underlying records. A semantic-model developer can control this behavior using the measure’s Detail Rows Expression, which can return a table-producing DAX expression. This is a powerful capability when the semantic model has been designed with Excel users in mind.

Another useful feature could be converting pivots into OLAP formulas. This gives finance professionals the precise, cell-by-cell control they need to build tailored financial reports.

There is a catch, though. If you are developing a semantic model that must support both Power BI and Excel users, you need to design for the least common denominator. Excel’s live-connection experience does not expose all the capabilities available in Power BI reports. For example, there are differences around field parameters, some filtering scenarios, custom visuals, and metadata behavior. Even seemingly small modeling decisions can affect how the semantic model appears in the Excel Field List.

In other words, a semantic model that works beautifully in Power BI isn’t necessarily going to provide the same experience in Excel.

Power BI connected tables

This is the option that could have the most potential if it wasn’t another half-baked Excel reporting feature. Microsoft introduced connected tables in 2023, but the experience has evolved considerably since then. Excel can now discover Power BI semantic models directly, and users can choose to insert either a PivotTable or a Table from the semantic model.

The Table option is particularly important because it delivers the data in the format most business users actually want: an Excel table. The user can select the fields they need and apply filters through a dedicated interface, rather than having to write DAX or build a Power BI report first. This is a significant improvement over the traditional export experience.

For years, the missing piece in the Microsoft BI stack was obvious: Excel users wanted the flexibility of a PivotTable’s field-selection interface but wanted the result as a regular Excel table. Connected Tables finally moves in that direction. It is also a much better architectural model: Fabric semantic model → Excel table. There is no Power BI report in the middle.

On the downside, the user interface is lost once data is exported. Consequently, the user must change the underlying DAX query (a client immediately dismissed this option after learning about this) if they want to make changes, such as adding additional fields. This could be a great option if there is a way to bring back that interface. Even better, let the user pick fields from Field List as they can with pivots but export to a table. What could be simpler?

Power Query

Another option is hiding in Excel’s Get Data experience. Power Query can connect to Power BI semantic models and provides considerably more flexibility than a simple connected table. Once the data is retrieved, users can transform it and even mash it up with other sources. For example, a user could combine:

Power BI semantic model + Excel file + another data source → Power Query → Excel table

It also makes Power Query a compelling option when the requirement isn’t simply “show me this data,” but rather: “Get this data, transform it in these ways, combine it with my other data, and give me a reusable result.”

The biggest issue we faced with this option was performance. For reason unknown, in import mode the Analysis Services connector generates horrible MDX queries, with nested CROSSJOINs, one for each imported field.  This was another showstopper for us. In addition, Power Query is a data-transformation tool, not a simple business-user reporting interface. Users must understand queries, transformations, refresh, data sources, and credentials. Excel’s Power Query implementation also doesn’t expose every connector and capability available elsewhere in the Microsoft data platform.

So, while Power Query is powerful, it isn’t necessarily the best answer for a business user who simply wants to select a few fields from a semantic model.

Excel Copilot

And, of course, there is AI. I’ve personally found Excel Copilot very useful for tasks such as generating test data, transforming data, and working with existing spreadsheets. Microsoft is now taking this a step further by integrating Power BI data into Copilot in Excel. The new Power BI grounding capability allows Copilot to use governed Power BI data when answering requests in Excel. This is potentially a very different way of interacting with a semantic model.

Instead of teaching a user how to navigate a Field List, write DAX, or configure a Power Query, the user can simply say what they want.

For example: “Bring me revenue, margin, and customer name for the current fiscal year. Filter to the Southeast region and sort by revenue descending.”

That’s exactly the type of task for which natural language makes sense. The technology is still rough around the edges, though. The experience can be slow, and the interaction isn’t yet ideal for creating a reusable library of data-extraction definitions. A prompt that works for one user isn’t necessarily a well-defined, portable query definition that another user can reuse with predictable results.

For Copilot to become a serious enterprise data-extraction mechanism, I’d like to see prompts evolve into something more like shareable, governed query definitions—something a business analyst can create once and distribute to other users.

The first one is letting the user select a single date by configuring the Date Picker using the Manual selection. Yes, it took a decade, so we must appreciate the engineering effort to get this implemented, so we don’t have to rely on workarounds as Patrick explains here.

More importantly, it helps with filtering the “current” period, so the end users don’t have to change filters when the calendar rolls forward. Previously, we had to resort to overwriting the current period caption, such as renaming the current month to “Current”, so the slicer automatically rolls forward when the current month changes. Or configure the slicer to use relative date, such as This Month.

The problem with both approaches has been that if the calendar has just rolled forward but there is no data yet, end users will get wonderful insights from emptiness. Apparently, the support tickets from enterprise customers reached a critical mass and Microsoft acted. Therefore, in my opinion the important feature here is rolling forward but anchored to the last date in the Date column bound to the slicer.

For example, the last month with Adventure Works data is December 2014 so the Date dimension table has dates only until this date. Let’s say January 1^st 2015 comes along but the semantic model doesn’t have data yet for January and therefore the Date table doesn’t have that date yet (or the slicer uses a DAX measure to filter dynamically the date range). The slicer will remain anchored to December 2014. Once we have data for January, the relative date configuration will switch to January.

TIP: If the Date table has future dates, you can use a DAX measure to filter the date range, such as SlicerDateFilter = IF(NOT ISBLANK([<SomeConditionToDetermineTheDateRange>]), 1, 0). Then drag your newly created SlicerDateFilter measure from the Data pane and drop it into the Filters On This Visual well in the Filter pane with the slicer selected.

What’s OSI?

Reading about the relatively freshly baked OSI, we learn that “the Open Semantic Interchange is an industry-wide specification effort to standardize how we exchange semantic metadata across analytics, AI and BI platforms, providing a vendor neutral, single source of truth for semantic data.” Great, I am all about standardization. If you ask me, the world should adopt the metric system and English as a universal language, and life will be much simpler. But this is about BI so let’s peek under the hood and keep ‘em honest.

Now, like ogres and cakes, a BI architecture has layers. Besides data sources, at minimum I like to see a central repository (let’s called a data warehouse) with star schema (if the star is missing, you don’t have DW, but operational data source, sorry), semantic layer (don’t skip it!), and of course reports with possibly AI – the cherry on top of the cake. “Modern” medallionists will of course dream of a bigger cake with bronze, silver, and gold layers, and then wonder what to put in them, but I digress.

OSI is an initiative from major Microsoft competitors in the BI space (Snowflake, Dbt, Google, Databricks, Salesforce) to standardize the semantic model definition so good report vendors who have bad semantic models, like Tableau and Salesforce, can integrate with vendors who have good backends but bad reporting, like Snowflake and Google. Did I get this right? I believe the main goal here is to compete more effectively against Microsoft which currently dominates the data analytics space. All that wrapped with “avoid the vendor lock-in and single version of truth” story.

About Snowflake semantic views

A Snowflake semantic view is OSI-based metadata definition described in YAML inside their database. Created similarly to a SQL view, it enumerates the star schema dimension and fact tables, their relationships, and basic metrics with SQL formulas. Inside Snowflake, the semantic views are currently used by their Cortex Analyst tool (analogous to Copilot in Microsoft Fabric) to let users and apps talk to data with natural questions. Behind the scenes, the question is translated to SQL, which is how Microsoft Fabric Data Agent works when connected to a lakehouse or warehouse.

For the most part, tables, relationships, and metrics is all OSI has defined at this point. And of course, ontology to glue semantic views together so AI knows how to reason across them (or, to check the box when you hear that catchy phrase on the golf course since every CIO has heard about ontologies by now although no one knows what it means). I’m glad Snowflake calls them “views” and not semantic models, which would be a big misnomer. By contrast, Microsoft has a 30+ years head start on semantic modeling so the two technologies (semantic view vs semantic model) can’t be meaningfully compared by any criteria (features, tooling, etc.).

Shall we standardize?

At this point, Microsoft doesn’t participate in OSI. Although to the best of my knowledge Microsoft hasn’t released official reasons, more than likely it’s because they don’t need to. There is a large distance between Microsoft and the rest of the pack. Further, they spent 20+ years on their engine and DAX tooling. I don’t think it’s even possible to retrofit many features into a new SQL-based basic standard. For example, the OSI metric language is SQL while DAX is Excel-like language because the thinking back then was to transition Excel users into self-service BI. I remember having discussions with the Analysis Services team about why not use SQL, but alas, Excel prevailed…I wonder if they’ve made a mistake there.

Now, if we are serious about open standards and interoperability, then I would argue that we should start with data formats. Wouldn’t be nice if Google and Snowflake rewrite their databases to use open formats, such as Delta or Iceberg, before getting to the semantic layer? That would immediately facilitate data integration and virtualization, such as by letting a Fabric user create shortcuts in a lakehouse to Google and Snowflake tables instead of replicating the data, as I mentioned in my “Give me your data” blog. So, if we are serious about make integration easier, let’s start from the bottom up as Microsoft and Databricks did, shall we?

Meanwhile, if you have invested in another database vendor, my advice would be to use the best of both worlds. If you like Snowflake, use their database for lake/warehouse and Power BI/Fabric for its semantic models and reporting capabilities. The best data source for AI is a rich semantic layer (sorry, Snowflake OSI semantic views).

And about the Cortex AI deterministic answers, it’s pure marketing propaganda; all LLMs might vary their answers and are not guaranteed to return the same results.