Posts

Five Ways to Get Data from Fabric Semantic Models in Excel

/0 Comments/in /by

Ask a business user where they want to work with the data, and Excel would probably top the list. Regardless of how hard we try to lure users away from it, Excel remains the endpoint of self-service BI for many organizations. I have clients who have built custom apps or purchased Excel add-ins simply to get data into Excel—or manipulate it once it gets there.

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:

Option Pros Cons
Export from published Power BI or paginated reports Power BI collaboration features; sharing; subscriptions; dynamic subscriptions; familiar report experience Export limitations; additional effort to create reports just to get data into Excel
Excel PivotTables and PivotCharts Familiar reporting experience; live connection to semantic models; customizable drillthrough; ability to share Excel reports in Power BI Service and generate them online. Outdated report experience; MDX query interface; rigid report layout; Excel workbook must be shared; must open report from OneDrive/SharePoint to interact
Power BI connected tables Data is delivered directly into an Excel table; designed specifically for Power BI semantic models; good UI for selecting fields and filters Less flexible than a full report; users don’t get the full Power BI report experience
Power Query Transform data; mash up multiple data sources; reusable queries Suboptimal MDX queries, additional complexity; connector limitations; licensing/connection considerations
Excel Copilot Natural-language instructions; can retrieve and augment data; can transform data Still evolving; can be slow; not yet ideal for creating a reusable library of data-extraction definitions

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.

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.

Atlanta Microsoft BI Group Meeting on August 3rd (Getting Hands-On with Microsoft Fabric IQ)

/0 Comments/in , /by

Atlanta BI fans, please join us online for our next meeting on Monday, August 3rd at 18:30 ET. Dean Jurecic will introduce you to Fabric IQ that helps organizations unleash AI on top of your enterprise data. For more details and sign up, visit our group page.

Delivery: In-person
Level: Beginner/Intermediate
Food: Pizza and drinks will be provided

Agenda:
18:30-19:00 Organizer time (events, news, sponsor marketing)
19:00-20:15 Main presentation
20:15-20:30 Q&A

Overview: This practical session guides attendees through the Microsoft Fabric IQ interface: exploring workspaces, semantic models, and how ontologies are surfaced within the platform. We’ll connect a sample dataset to a semantic layer, define key business entities and relationships, and demonstrate how Fabric IQ uses that ontological context to generate richer, more accurate insights. No prior Fabric experience required. You’ll leave with a foundational understanding of how to begin structuring your own organization’s knowledge model.

Speaker: Dean Jurecic is a solutions engineer and consultant who specializes in Microsoft Fabric and Power BI. He has worked with Power BI and Fabric in a variety of industries including utilities, retail, construction, government and education. Dean is an active member of the data community, a Microsoft Fabric Certified Data Engineer and Analytics Engineer Associate and a 3x Fabric Community Super User.

Sponsor: For almost 20 years, Wiiisdom has helped customers by providing first-class Analytics Governance Solutions that enable organizations to automate their analytics operations. The Wiiisdom Cloud Platform for Power BI and Tableau consists of 3 modules: Continuous Certification, Lifecycle Management and Predictive Monitoring that are designed to help you move from reactively to proactively managing your analytics estate

PowerBILogo

Atlanta Microsoft BI Group Meeting on July 6th (Using Generative AI on Structured Data)

/0 Comments/in , /by

Atlanta BI fans, please join us online for our next meeting on Monday, July 6th at 18:30 ET. James Serra (Data & AI Solution Architect at Microsoft) will show you how AI can transform our interaction with structured data, providing practical applications for enhanced automation, decision-making, and efficiency in data analysis. For more details and sign up, visit our group page.

Delivery: Online via MS Teams
Level: Beginner/Intermediate
Food: Pizza and drinks will NOT be provided

Agenda:
18:30-19:00 Organizer time (events, news, sponsor marketing)
19:00-20:15 Main presentation
20:15-20:30 Q&A

Overview: Generative AI, traditionally used for processing unstructured text, is rapidly advancing to handle structured data like relational databases, spreadsheets, and CSV files. New tools now enable AI to extract meaningful insights, identify patterns, and generate predictions from structured datasets. This presentation will explore how AI transforms our interaction with structured data, providing practical applications for enhanced automation, decision-making, and efficiency in data analysis. I will discuss ChatGPT, Copilot, and Microsoft Fabric Data Agents and provide a level-set on GenAI definitions, RAG, fine-tuning, and cover industry use cases for using both unstructured and structured data to make better business decisions.

Speaker: James Serra works at Microsoft as a data solution engineer where he has been for most of the last twelve years. He is a thought leader in the use and application of Big Data and advanced analytics, including data architectures such as the modern data warehouse, data lakehouse, data fabric, and data mesh. He has over 40 years of IT experience. He is a popular blogger ([JamesSerra.com](https://www.jamesserra.com/)) and speaker, having presented at dozens of major events. He is the author of the book “Deciphering Data Architectures: Choosing Between a Modern Data Warehouse, Data Fabric, Data Lakehouse, and Data Mesh”.

PowerBILogo

Prologika Newsletter Summer 2026

/0 Comments/in /by

If Microsoft Fabric was the Statue of Liberty, the inscription would be “Give me your data”. Fabric is obsessed with owning the data when it makes sense and when it doesn’t. As I wrote before, this pattern was probably borrowed from Palantir and to align Fabric with the push for “modern” medallion architectures. Or, to establish a permanent dependency on Fabric…

In this newsletter, I make a case that Fabric should support better data virtualization that goes beyond creating shortcuts to files.

Auto-replicating data to Fabric

To satisfy the Fabric data appetite and facilitate data ingestion into OneLake, Fabric offers two primary options that don’t require explicit ETL: mirroring and shortcut transformations.

  1. Mirroring targets a growing number of relational and non-relational database engines. Although described as “easy-to-use”, mirroring could prove challenging to set up in real life. For example, in one case, the client simply refused to set up mirroring from Google BigQuery because of the requirement to grant excessive permissions. In another case, we are still trying to figure out why mirroring doesn’t work from Azure SQL MI configured on private network. Not to mention that mirroring even from Microsoft SQL SKUs has limitations, such as historical temporal tables can’t be mirrored.
  2. This leaves with the second option: shortcut transformations. They target a subset of file formats (not databases). Like mirroring, Fabric polls periodically the shortcut target folder and synchronizes the data in OneLake Delta tables. These transformations could be useful to provide convenient access to this data from Fabric workloads, such as to access reference data a business user maintains in an Excel spreadsheet in a Fabric Data Warehouse. On the downside, data must be exported and saved as files.

OneLake Shortcuts

Yet, many scenarios could be addressed by simply accessing the data where it is. In other words, by data virtualization. As it stands, Fabric has limited file-based data virtualization capabilities with OneLake shortcuts. OneLake shortcuts shouldn’t be confused with the shortcut transformations mentioned before. OneLake shortcuts are read-only pointers to external files. These shortcuts are typically listed in the unmanaged section of OneLake (the Files folder). OneLake shortcuts don’t import the data in Delta tables. How are they useful then? The main thought is to conveniently share data between teams, workspaces, or domains, workloads, without moving it.

As an exception to the rule, if the OneLake shortcut points to a Delta table, such as OneLake or elsewhere, or Iceberg table, the shortcut still doesn’t copy the data but exposes it as OneLake Delta table. This lets you utilize Delta-specific features, such as a DirectLake semantic model without moving the data. I find this inspiring to imagine a simplified data integration in a world where one day other vendors could embrace standard file formats.

What about databases?

Based on experience, a typical company has 90+ percent of its data in relational databases or connectable non-file sources, such as REST APIs and SFTP servers. In my opinion, mirroring these (sometimes huge) datasets into a file-based, pseudo-relational lakehouse rarely makes sense. Wouldn’t be nice to have shortcuts to tables in these sources and then shape and get the data you need instead of writing ETL? And even better, run cross-database queries? Wouldn’t this be a great Fabric differentiator compared to other vendors?

Since time immemorial, SQL Server has been supporting linked servers and heterogenous joins across databases. Then PolyBase was supposed to replace linked servers and be the Microsoft answer to broader data virtualization. Alas, both technologies didn’t make it to Fabric. Linked servers are available only in on-prem SQL Server and with limited support in Azure SQL MI. Polybase was relegated to the on-prem SQL Server.

I think it’s time Fabric to fulfil its zero-copy promise and say “Let me connect the dots, don’t move that data”.


Teo Lachev
Prologika, LLC | Making Sense of Data
logo

Open Semantic Interchange (OSI)

/0 Comments/in /by

An excited enterprise client came back from a conference where Snowflake delighted them with AI demos and semantic views built on Open Semantic Interchange (OSI) standard. Snowflake even went further to show how their Cortex Analyst tool returns deterministic AI answers. Naturally, given their existing investments in Snowflake data lake and ODS, the client questioned why we don’t build everything in Snowflake instead of bringing Microsoft Fabric and two vendors into the mix.

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.

 

 

Give Me Your Data!

/0 Comments/in /by

If Microsoft Fabric was the Statue of Liberty, the inscription would be “Give me your data”. Fabric is obsessed with owning the data when it makes sense and when it doesn’t. As I wrote before, this pattern was probably borrowed from Palantir and to align Fabric with the push for “modern” medallion architectures. Or, to establish a permanent dependency on Fabric…

Auto-replicating data to Fabric

To satisfy the Fabric data appetite and facilitate data ingestion into OneLake, Fabric offers two primary options that don’t require explicit ETL: mirroring and shortcut transformations.

  1. Mirroring targets a growing number of relational and non-relational database engines. Although described as “easy-to-use”, mirroring could prove challenging to set up in real life. For example, in one case, the client simply refused to set up mirroring from Google BigQuery because of the requirement to grant excessive permissions. In another case, we are still trying to figure out why mirroring doesn’t work from Azure SQL MI configured on private network. Not to mention that mirroring even from Microsoft SQL SKUs has limitations, such as historical temporal tables can’t be mirrored.
  2. This leaves with the second option: shortcut transformations. They target a subset of file formats (not databases). Like mirroring, Fabric polls periodically the shortcut target folder and synchronizes the data in OneLake Delta tables. These transformations could be useful to provide convenient access to this data from Fabric workloads, such as to access reference data a business user maintains in an Excel spreadsheet in a Fabric Data Warehouse. On the downside, data must be exported and saved as files.

OneLake Shortcuts

Yet, many scenarios could be addressed by simply accessing the data where it is. In other words, by data virtualization. As it stands, Fabric has limited file-based data virtualization capabilities with OneLake shortcuts. OneLake shortcuts shouldn’t be confused with the shortcut transformations mentioned before. OneLake shortcuts are read-only pointers to external files. These shortcuts are typically listed in the unmanaged section of OneLake (the Files folder). OneLake shortcuts don’t import the data in Delta tables. How are they useful then? The main thought is to conveniently share data between teams, workspaces, or domains, workloads, without moving it.

As an exception to the rule, if the OneLake shortcut points to a Delta table, such as OneLake or elsewhere, or Iceberg table, the shortcut still doesn’t copy the data but exposes it as OneLake Delta table. This lets you utilize Delta-specific features, such as a DirectLake semantic model without moving the data. I find this inspiring to imagine a simplified data integration in a world where one day other vendors could embrace standard file formats.

What about databases?

Based on experience, a typical company has 90+ percent of its data in relational databases or connectable non-file sources, such as REST APIs and SFTP servers. In my opinion, mirroring these (sometimes huge) datasets into a file-based, pseudo-relational lakehouse rarely makes sense. Wouldn’t be nice to have shortcuts to tables in these sources and then shape and get the data you need instead of writing ETL? And even better, run cross-database queries? Wouldn’t this be a great Fabric differentiator compared to other vendors?

Since time immemorial, SQL Server has been supporting linked servers and heterogenous joins across databases. Then PolyBase was supposed to replace linked servers and be the Microsoft answer to broader data virtualization. Alas, both technologies didn’t make it to Fabric. Linked servers are available only in on-prem SQL Server and with limited support in Azure SQL MI. Polybase was relegated to the on-prem SQL Server.

I think it’s time Fabric to fulfil its zero-copy promise and say “Let me connect the dots, don’t move that data”.

 

Atlanta Microsoft BI Group Meeting on June 1st (Build Your First Agent in Copilot Studio)

/0 Comments/in , /by

Atlanta BI fans, please join us in person for our next meeting on Monday, June 1st at 18:30 ET. Elayne Jones (Senior Solution Engineer at Microsoft) will show you how to build enterprise-ready agents with Copilot Studio. These agents can source data from a variety of data sources including Fabric Data Agents. I will sponsor the meeting. For more details and sign up, visit our group page.

Delivery: In-person
Level: Intermediate
Food: Pizza and drinks will be provided

Agenda:
18:15-18:30 Registration and networking
18:30-19:00 Organizer and sponsor time (news, Power BI latest, sponsor marketing)
19:00-20:15 Main presentation
20:15-20:30 Q&A

Overview: A practical, hands‑on session for anyone ready to move beyond generic AI chat and start building purpose‑built, enterprise‑ready agents. You’ll learn what agents really are, how they differ from traditional chatbots, and where Copilot Studio fits alongside Microsoft 365 Copilot and Azure AI services.

Speaker: Elayne Jones is a Senior Solution Engineer at Microsoft. Elayne specializes in Microsoft Power Platform, delivering scalable solutions through Copilot Studio, Power Apps, Power Automate. She helps organizations modernize workflows, build low‑code applications, and unlock insights through integrated, data‑driven experiences.

Sponsor: Prologika (https://prologika.com) helps organizations of all sizes to make sense of data by delivering tailored BI solutions that drive actionable insights and maximize ROI. Your BI project will be your best investment, we guarantee it!

PowerBILogo

Replicating BigQuery to Fabric Reloaded

/0 Comments/in /by

In a previous post, I referred to an engagement where we used the Fabric Copy Job activity to replicate Google BigQuery tables to Fabric, so we can use Direct Lake semantic models. A few months later, the client reported that they pivoted from the Copy Job to notebooks using the Spark BigQuery connector for two main benefits:

  1. Much better copy performance – Although the Copy Job would copy tables in parallel, the Spark BigQuery connector reduced significantly the data transfer time. The Copy Job would fully copy all tables in about 40 min.  With the Notebook, while the tables run sequentially instead of in parallel, most tables would take between 20-30 sec and one huge 140M fact table takes around 2 minutes to copy fully.  Altogether, the required tables take about 20-22 minutes to load, which is almost half the time less than the Copy Job. Upon further research to understand the difference in performance, I’ve discovered that the Spark BigQuery connector (the official one from Google) uses the high-performance BigQuery Storage Read API. This is a highly optimized, columnar, parallel reader designed for analytical workloads. It can push down filters, projections (column selection), and sometimes aggregations directly to BigQuery. It streams data very efficiently to Spark executors. By contrast, the Copy Job is generic, and I don’t expect such performance gain with other sources, such as copying data from Azure SQL DB.
  2. Custom code flexibility – For example, the client implemented data-driven metadata discovery to determine which columns to copy per table. In addition, they could trigger the notebook execution via REST API.

In summary, there are various options to replicate data from Google BigQuery to Fabric, including mirroring, Copy Job, and notebooks. Each approach has its pros and cons. Notebooks using the Spark BigQuery connector would probably give you the best throughput for batch-oriented, massive replication.

BigQuery to Fabric flow

 

Atlanta Microsoft BI Group Meeting on May 4th (Making Sense of Copilot in Power BI)

/0 Comments/in , /by

Atlanta BI fans, please join us in person for our next meeting on Monday, May 4th at 18:30 ET. Jackie Kiadii will show you how you use the Copilot capabilities in Power BI. CloudStaff will sponsor the meeting. For more details and sign up, visit our group page.

Delivery: In-person
Level: Beginner/Intermediate
Food: Pizza and drinks will be provided

Agenda:
18:15-18:30 Registration and networking
18:30-19:00 Organizer and sponsor time (news, Power BI latest, sponsor marketing)
19:00-20:15 Main presentation
20:15-20:30 Q&A

Overview: Copilot in Power BI is generating excitement — and significant confusion. Between multiple Copilot experiences, Fabric capacity requirements, and differences across Desktop, Service, and Fabric, many Power BI professionals struggle to explain what Copilot actually does and when it makes sense to use it.
This session provides a clear, practical overview of:

  • Copilot use cases that exist today
  • Where Copilot works (and where it doesn’t)
  • Licensing and capacity requirements
  • Current limits that impact real‑world adoption

Rather than a technical deep dive or demo, the focus is on clarity and expectation‑setting — helping attendees evaluate Copilot realistically and explain it confidently to Excel users, business stakeholders, and clients.
Attendees will leave with a framework they can use to make informed decisions about Copilot and confidently explain it to others.

Speaker: Jackie Kiadii is a Power BI trainer specializing in helping Excel users successfully transition to Power BI and adopt Microsoft analytics tools with confidence. She is a retired Microsoft Excel MVP, Microsoft Certified Trainer (MCT), Microsoft Data Analyst Associate (PL‑300), and Microsoft Office Specialist: Excel Expert. Jackie focuses on turning complex Microsoft BI topics into clear, practical guidance that supports real‑world adoption. Her work emphasizes licensing clarity, user expectations, and helping teams avoid costly or unnecessary decisions when implementing Power BI and Copilot.

Sponsor: CloudStaff.ai

PowerBILogo

Prologika Newsletter Spring 2026

/0 Comments/in /by

At Ignite in November, 2025, Microsoft introduced Fabric IQ. I noted to go beyond the marketing hype and check if Fabric IQ makes any sense. The next thing I know, around the holidays I’m talking to an enterprise strategy manager from an airline company and McKinsey consultant about ontologies. In this newsletter I share my thoughts of FabricIQ based on my initial evaluation. Let’s start with what ontology is and how Fabric IQ uses it to integrate your enterprise data.

Ontology – A branch of philosophy, ontology is the study of being that investigates the nature of existence, the features all entities have in common, and how they are divided into basic categories of being. In computer science and AI, ontology refers to a set of concepts and categories in a subject area or domain that shows their properties and the relations between them.

What is Fabric IQ?

According to Microsoft, Fabric IQ is “a unified intelligence platform developed by Microsoft that enhances data management and decision-making through semantic understanding and AI capabilities.” Clear enough? If not, if you view Fabric as Microsoft’s answer to Palantir’s Foundry, then Fabric IQ is the Microsoft equivalent of Palantir’s Foundry Ontology, whose success apparently inspired Microsoft.

Therefore, my unassuming layman definition of Fabric IQ is a metadata layer on top of data in Fabric that defines entities and their relationships so that AI can make sense of and relate the underlying data.

For example, you may have an organizational semantic model built on top of an enterprise data warehouse (EDW) that spans several subject areas. And then you might have some data that isn’t in EDW and therefore outside the semantic model, such as HR file extracts in a lakehouse. You can use Fabric IQ as a glue that bridges that data together. And so, when the user asks the agent “correlate revenue by employee with hours they worked”, the agent knows where to go for answers. This screenshot shows how you can define such relationships between two entities.

Screenshot of the renamed entity types.

Following this line of thinking, Microsoft BI practitioners may view Fabric IQ as a Power BI composite semantic model on steroids. The big difference is that a composite model can only reference other semantic models while Fabric IQ can span data in multiple formats.

The Good

Palantir had a head start of a decade or so compared to Microsoft Fabric, but yet even in its preview stage, I like a thing or two about Fabric IQ from what I’ve seen so far:

  • Its oncology can span Power BI semantic models (with caveats explained in the next section), powered by best-in-class technology. As I mentioned before, this allows you to bridge all the business logic and calculations you carefully crafted in a semantic model to the rest of your Fabric data estate.
  • Fabric IQ integrates with other Microsoft technologies, such as real-time intelligence (eventhouses), Copilot Studio, Graph. This tight integration turns Fabric into a true “intelligence platform,” reducing duplicated logic, one-off models, and maintenance while enabling multi-hop reasoning and real-time operational agents.
  • Democratized and no-code friendly – Visual tools allow business users to build and evolve the ontology, lowering barriers compared to more engineering-heavy alternatives. Making it easy to use has always been a Microsoft strength.
  • Groundbreaking semantics for AI Agents: Fabric IQ elevates AI from pattern-matching to true business understanding, allowing agents to reason over cascading effects, constraints, and objectives—leading to more reliable, auditable decisions and automation.
  • Compared to Palantir, I also like that Fabric OneLake has standardized on an open Delta Parquet format and embraced data movements tools Microsoft BI pros and business users are already familiar with, such as Dataflows and pipelines, to bring data in Fabric and therefore Fabric IQ.

The Bad

I hope some of these limitations will be lifted after the preview but:

  • Only DirectLake semantic models are accessible to AI agents. Import and DirectQuery models are not currently supported for entity and relationships binding. Not only does this limitation rule out pretty much 99.9% of the existing semantic models, but it also prevents useful business scenarios, such as accessing the data where it is with DirectQuery instead of duplicating the data in OneLake.
  • No automatic ontology building – It requires cross-functional agreement on business definitions, workshops, and governance—labor-intensive for organizations without mature semantic models. I hope Microsoft will simplify this process like how Purview has automated scans.
  • Risk of overhype vs. delivery gap – We’ve seen this before when new products got unveiled with a lot of fanfare, only to be abandoned later.

The Ugly

OneLake-centric dependency. Except for shortcuts to Delta Parquet files which can be kept external, your data must be in OneLake. What about these enterprises with investments in Google BigQuery, Teradata, Snowflake, and even SQL Server or Azure SQL DB? Gotta bring that data over to OneLake. Even shortcut transformations to CSV, Parquet, JSON files in OneLake, S3, Google Cloud Storage, will copy the data to OneLake. By contrast, Palantir has limited support for virtual tables to some popular file formats, such as Parquet, Iceberg, Delta, etc.

What happened to all the investments in data virtualization and logical warehouses that Microsoft has made over years, such as PolyBase and the deprecated Polaris in Synapse Serverless? What’s this fascination with copying data and having all the data in OneLake? Why can’t we build Fabric IQ on top of true data virtualization?

Which is where I was thinking that semantic models with DirectQuery can be used as a workaround to avoid copying data over from supported data sources, but alas Fabric IQ doesn’t like them yet.

Summary

Microsoft Fabric IQ is a metadata layer on top of Fabric data to build ontologies and expose relevant data to AI reasoning. It will be undoubtedly appealing to enterprise customers with complex data estates and existing investments in Power BI and Fabric. However, as it stands, Fabric IQ is OneLake-centric. Expect Microsoft to invest heavily in Fabric and Fabric IQ to compete better with Palantir.


Teo Lachev
Prologika, LLC | Making Sense of Data
logo