# Fabric IQ Explained: What It Is, Why It Matters, and How to Build Your First Ontology

> If you've worked in data long enough, you know the quiet pain. Your warehouse is full of tables called factsales, dimstore, and dimproducts. Your business, meanwhile, talks about customers, shipments, and cold-chain breaches. Every time someone asks a "simple" question, a domain expert has to sit down and translate it into joins, filters, and column names. That translation tax is the thing slowing everyone down — and it's exactly the thing Fabric IQ is built to remove.

**Category:** microsoft-fabric  
**Published:** 2026-06-06T07:20:50.534643Z  
**Canonical:** https://allaboutspark.com/posts/fabric-iq-explained-what-it-is-why-it-matters-and-how-to-build-your-first-ontology
**Tags:** microsoft fabric, fabricIq, GenAI data engineering

---

This article is the one-stop guide. By the end you'll know what Fabric IQ actually is, where it sits in Microsoft's bigger picture, why it's worth your attention as a data engineer, and the part most people skip. How to actually turn it on and build your first ontology, step by step.

> **Heads up:** Most of Fabric IQ (the IQ workload, ontology, plan, operations agent) is currently in **preview**. The concepts are stable, but UI and behavior can still shift.

## What is Fabric IQ?
 
Fabric IQ is part of a larger family called **Microsoft IQ**, the layer Microsoft describes as the "enterprise intelligence layer" sitting across its whole stack. Think of Microsoft IQ as four different lenses on your organization, each answering a different kind of question:

- **Work IQ** - context on *how your people work* (their documents, meetings, collaboration patterns).
- **Foundry IQ** - context on your organization's *policies and authoritative documents*.
- **Web IQ** - context from *the public web*.
- **Fabric IQ** - context on your *business entities and data*.

So Fabric IQ is the piece that understands the **state of your business through its data**. And here's the important nuance: it isn't just "more data." Fabric IQ takes all your analytical, real-time, and operational data and **lifts it up into the language your business actually speaks**. Once data carries that meaning, both people *and* AI agents can reason about it correctly - in terms of business concepts and goals, not table names.


That's the one-line pitch: **Fabric IQ is the semantic layer that lets humans and AI agents understand your data the same way your business does.**

## The three layers of Fabric IQ
 
Fabric IQ delivers business context in three stacked layers. The two layers you'll work with most directly map to two core Fabric items - the **semantic model** and the **ontology** - and they sit on top of **OneLake** as the shared foundation.

![Diagram showing the three layers of Fabric IQ: unified data with OneLake, business intelligence with Power BI semantic models, and operational intelligence with ontologies.](https://learn.microsoft.com/en-us/fabric/iq/media/overview/fabric-iq-layers.png)

*The three layers of Fabric IQ, from the unified OneLake foundation up to operational intelligence.*

### 1. Unified data with OneLake
 
[OneLake](https://learn.microsoft.com/en-us/fabric/onelake/onelake-overview) is the foundation. It pulls your enterprise data across clouds and even on-premises  into a single, governed source of truth. Using **shortcuts**, **mirroring**, and the **OneLake catalog**, it kills the usual fragmentation and gives you one multicloud lake to work from.
 
For a data engineer, the killer detail here is *shortcuts*: Fabric IQ can reference external operational data **in place**, without copying it or building yet another ETL pipeline. OneLake is also the distribution layer, so whatever you define once stays consistent across Fabric, Foundry, and Copilot Studio.
 

### 2. Business intelligence with Power BI semantic models
 
[Power BI semantic models](https://learn.microsoft.com/en-us/fabric/data-warehouse/semantic-models) are the curated analytics layer you probably already know  measures, hierarchies, dimensions, trusted KPIs. The clever bit in Fabric IQ is that **you can generate an ontology directly from a semantic model you already have in production.** You're not starting from a blank page; you're bootstrapping from logic and definitions your business already trusts. Define a concept like *Customer*, *Shipment*, or *Breach* once, and reuse it everywhere.

### 3. Operational intelligence with ontologies
 
[Ontologies](https://learn.microsoft.com/en-us/fabric/iq/ontology/overview) are where it gets interesting. An ontology defines your core business **entities, relationships, properties, rules, and actions**. Because actions are part of the definition, agents understand not just *what things mean* but *what they can do* — operations agents can watch live data, spot anomalies, and take governed action.
 
You can also query an ontology in plain English through the **NL2Ontology** layer, which turns a business question into a structured query under the hood. No more "let me write the SQL for that."
 
## Why should a data engineer care?
 
Let's be honest about the core problem. We organize data as tables and schemas because that's convenient for machines. But the business runs on concepts. Without a semantic layer in between, AI stays unfit for high-stakes decisions, because **every single question needs a human to manually translate it first.** That doesn't scale.
 
Fabric IQ gives you three concrete wins:
 
- **Cross-domain reasoning.** Because concepts are linked through a graph, you can traverse relationships to *explain* outcomes. The classic example: `Order → Shipment → Temperature Sensor → Cold Chain Breach`. That chain answers "why did this delivery spoil?" without you hand-writing a five-table join.
- **Faster onboarding.** Declare a business concept once, and every new dashboard, agent, and app inherits the same meaning. New experiences light up with consistent business semantics out of the box.
- **Governance and trust.** One definition instead of fifteen slightly-different ones across teams. Constraints (types, ranges, uniqueness) baked into the concept layer quietly improve data quality.
But here's the reality check straight from Microsoft: **you can't start at the IQ layer.** You need a solid data foundation first. Fabric delivers that through four core capabilities.
 
![Diagram showing the Fabric IQ framework: unify the data estate, process and harmonize data, curate semantic knowledge, and empower AI agents.](https://learn.microsoft.com/en-us/fabric/iq/media/overview/fabric-iq-framework.png)
 
*The four capabilities Fabric relies on to make the IQ layer possible.*
 
1. **Unify the data estate.** Bring analytical and operational data together  lakehouses, eventhouses, semantic models  into one consistent model. Pull in external operational data with OneLake shortcuts, no ETL required.
2. **Process and harmonize data.** Query acceleration and AI-powered analytics mean less time babysitting performance and more time delivering insight.
3. **Curate semantic knowledge.** One definition of *Customer* or *Asset* drives how Power BI, notebooks, and agents all interpret the data. Ambiguity gone.
4. **Empower AI agents.** Fabric IQ gives copilots and agents structured grounding, so their answers reflect *your* enterprise language as defined in your ontology  not a guess.

## IQ as a workload in Fabric: the items
 
Inside Fabric, **IQ (preview)** is a workload - a grouping of related items for unifying and contextualizing business data. The two core items are the **ontology** and the **semantic model**, but the workload bundles several more for analyzing, consuming, and operationalizing that context.
 
One thing worth knowing: **items can belong to multiple workloads.** Several IQ items are shared with Real-Time Intelligence and Power BI, because they're relevant across scenarios.
 
Here's the full lineup:
 
| Fabric item | What it's for |
| --- | --- |
| **Ontology (preview)** | Defines your shared business vocabulary — entity types, relationships, properties, rules. The grounding layer for cross-domain consistency and AI agents. |
| **Power BI semantic model** | Curated analytics models with measures, hierarchies, and relationships. Trusted KPIs and fast visuals. Ontologies can be generated from these. *(Also a Power BI item.)* |
| **Plan (preview)** | A no-code experience for planning, forecasting, and reporting on a single data foundation, without tool-switching. |
| **Graph (preview)** | Stores and queries connected data nodes, edges, traversals. The engine behind impact chains, dependencies, and shortest paths. *(Also a Real-Time Intelligence item.)* |
| **Data agent** | A virtual analyst that answers natural-language questions for a specific domain, grounded in your semantic models and ontologies. Publishable to Microsoft 365, Foundry, Copilot Studio, and custom apps. *(Also a Data Science item.)* |
| **Operations agent (preview)** | Monitors real-time data and recommends business actions, reasoning across your business concepts to detect anomalies and trigger governed responses. *(Also a Real-Time Intelligence item.)* |
 
> **Note on OneLake:** OneLake isn't listed as an "item" because it's the foundation underneath *everything*. Every item above reads and writes OneLake tables natively.
 
### How the items fit together
 
The magic is in the connections:
 
- **Ontology + semantic model** - define a concept once, then keep KPIs and terminology consistent across reports and agents.
- **Ontology + Graph** - the ontology declares *what connects and why*; Graph stores and traverses those connections (tracing a shipment through a risky route to a breach).
- **Ontology + data/operations agents** - the ontology grounds agents in shared language and rules, so they reason correctly and act within guardrails.
- **Plan + semantic model** - Plan pulls in dimensions and measures for plan-versus-actuals and dynamic forecasting.
Put simply: semantic models deliver trusted KPIs, the ontology defines the shared language for them, Graph powers relationship analysis, Plan turns insight into action, and the agents provide concept-aware conversation over live and historical data.
 
---
 
## A closer look at the ontology (the heart of it all)
 
If you only learn one Fabric IQ item deeply, make it the ontology. It's the shared, machine-understandable vocabulary of your business. Think of it as a **business context layer** containing a catalog of reusable concepts, the bindings that link those concepts to real data, a graph view of how they relate, and a query surface you can ask questions against.
 
### The four building blocks
 
| Concept | What it is | Everyday example |
| --- | --- | --- |
| **Entity type** | The reusable logical model of a real-world concept. Standardizes the name, identifiers, properties, and constraints - so "shipment" means the same thing to everyone. | `Customer`, `Shipment`, `Sensor` |
| **Entity instance** | A concrete occurrence of an entity type, populated from your data. Tracks which source created it and when it was true. | One specific customer record |
| **Property** | A named fact about an entity, with a declared data type. Enforces consistent types, units, and naming. | A customer's `name` and `email` |
| **Relationship** | A typed, directional link between entities. Can carry attributes (distance, confidence, validity) and cardinality rules. | `Customer places Order` (one customer, many orders) |
 
The big idea: an entity type lifts a concept *above any single table*, which is what kills those conflicting column-level definitions scattered across your sources. And relationships make context explicit and reusable - you get traversal and dependency analysis **without writing custom join logic every time**.
 
### Data binding: wiring concepts to real data
 
Defining an ontology is only half the job. **Data binding** is where you connect those definitions to concrete data living in OneLake - lakehouse tables, eventhouse streams, Power BI semantic models. A binding describes data types, identity keys, how columns map to properties, and how keys map to relationships across multiple sources.
 
This is the step that turns raw rows and events into **governed business objects**, with schema-evolution rules, quality checks (nullability, ranges, uniqueness), and provenance attached at the concept level.
 
> **One gotcha to remember:** Updates in your upstream sources (like new rows) don't appear automatically. You need to **manually refresh** the ontology's graph model before they show up.
 
### The ontology graph
 
Once data is bound, you get a **queryable instance graph**: nodes are entity instances, edges are the links between them (asserted or derived), each carrying source lineage. This is what lets you visually explore business context and run graph algorithms - paths, centrality, communities - over your actual business data.
 
> The graph feature depends on **Graph in Microsoft Fabric**, so you'll need the Graph tenant setting enabled (more on that below).
 
### Querying with NL2Ontology
 
Here's the part business users love. Ontology querying lets you ask **business-level questions** over your bound sources using business terms. You start with an entity type, filter by properties, traverse relationships, aggregate by time.
 
The clever engineering underneath: the ontology layer **automatically routes your query to the most efficient system** - GQL for Graph, KQL for Eventhouse - so you don't have to know where the data physically lives. And the **NL2Ontology** layer translates plain-English questions into structured queries, while making sure filters, joins, units, and validity windows line up with your published definitions.
 
---
 
## What you need to turn it on (prerequisites)
 
Before you build anything, the plumbing has to be in place. Here's the honest prerequisite list.
 
**You need:**
 
- A **workspace** backed by a **Fabric-enabled capacity**. Use one workspace for everything you build.
- A **Fabric administrator** to flip on the required **tenant settings** in the admin portal.
The tenant settings to enable (admin portal → tenant settings):
 
- **Enable Ontology item (preview)** - *required* to create ontology items.
- **User can create Graph (preview)** - *required*, because the ontology graph runs on it.
- **Users can create and share Data agent item types (preview)** - needed if you'll use a data agent.
- **Users can use Copilot and other features powered by Azure OpenAI** - needed for the AI/NL features.
- **Data sent to Azure OpenAI can be processed outside your capacity's region** - for NL2Ontology and agents.
- **Data sent to Azure OpenAI can be stored outside your capacity's region** - same.
![Screenshot of enabling the Ontology item setting in the Fabric admin portal.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/overview-tenant-settings/prerequisite-ontology.png)
 
*Turning on "Enable Ontology item (preview)" in the admin portal.*
 
![Screenshot of enabling the Graph setting in the Fabric admin portal.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/overview-tenant-settings/prerequisite-graph.png)
 
*The Graph setting - skip this and you'll hit errors the moment you open a new ontology.*
 
> **If you skip the Graph setting**, creating an ontology may *look* fine, but you'll hit an error like *"Unable to create the Ontology (preview) item"* when you open it. So enable both the ontology and graph settings together.
 
---
 
## How to create your first ontology (hands-on)
 
The official tutorial uses a fictional company, **Lakeshore Retail** - an ice cream seller with sales data and freezer streaming data. You build entity types like `Store`, `Products`, and `SaleEvent`, bind streaming `freezer temperature` from Eventhouse, and answer questions like *"What's the top product by revenue across all stores?"*
 
There are **two ways** to create an ontology, and your choice depends on what you already have:
 
1. **Generate from a semantic model** - best when you already have a well-structured Power BI semantic model. Fastest path; you bootstrap and extend.
2. **Build directly from OneLake** - best when you have no semantic model, or you want full control over the design from the start.
We'll walk both. First, the shared setup.
 
### Step 0 - Set up the sample data
 
Download the sample CSVs from the [Fabric samples GitHub repo](https://github.com/microsoft/fabric-samples/tree/main/docs-samples/iq): `DimStore.csv`, `DimProducts.csv`, `FactSales.csv`, `Freezer.csv`, and `FreezerTelemetry.csv`.
 
**Prepare the lakehouse:**
 
1. In your workspace, create a new **Lakehouse** called `OntologyDataLH`.
2. From the ribbon, choose **Get data → Upload files** and upload four CSVs: `DimProducts`, `DimStore`, `FactSales`, and `Freezer`. *(Leave `FreezerTelemetry.csv` for Eventhouse later.)*
3. For each file, select **... → Load to Tables → New table**, keeping defaults.
![Screenshot of the loaded delta tables in the lakehouse.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-0-introduction/lakehouse-tables.png)
 
*Your lakehouse after loading the CSVs to delta tables (names come through in lowercase).*
 
**Prepare the semantic model** (only if you're taking the semantic-model path):
 
1. From the lakehouse ribbon, select **New semantic model**, name it `RetailSalesModel`, and pick three tables: `dimproducts`, `dimstore`, `factsales`. *(Don't include `freezer` — that gets added manually later.)*
2. Open the model in **Editing** mode and use **Manage relationships** to create two relationships:
| From table | To table | Cardinality | Cross-filter | Active? |
| --- | --- | --- | --- | --- |
| `factsales` (`StoreId`) | `dimstore` (`StoreId`) | Many to one (\*:1) | Single | Yes |
| `factsales` (`ProductId`) | `dimproducts` (`ProductId`) | Many to one (\*:1) | Single | Yes |
 
![Screenshot of the created relationships in the semantic model.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-0-introduction/manage-relationships-2.png)
 
*Both relationships defined — the model is now ready to generate an ontology from.*
 
**Prepare the eventhouse** (for the live freezer data):
 
1. Create a new **Eventhouse** called `TelemetryDataEH` (a KQL database of the same name comes with it).
2. Open the KQL database, then **Get data → Local file**, and create a new table `FreezerTelemetry` from `FreezerTelemetry.csv`.
![Screenshot of the FreezerTelemetry table loaded in the KQL database.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-0-introduction/eventhouse-table.png)
 
*The streaming telemetry table sitting in Eventhouse, ready to bind later.*
 
---
 
### Path A - Generate an ontology from a semantic model
 
This is the shortcut. Fabric reads your semantic model and builds the ontology scaffold for you.
 
**1. Generate it.** Open the `RetailSalesModel` semantic model. In the top ribbon, click **Generate Ontology**.
 
![Screenshot of the Generate Ontology button in the semantic model ribbon.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-1-create-ontology/semantic-model/generate-ontology.png)
 
*One button to bootstrap an ontology from logic you already trust.*
 
**2. Name it.** Pick your workspace, name it `RetailSalesOntology`, and click **Create**.
 
> **Naming rule:** Ontology names can use letters, numbers, and underscores - **no spaces or dashes.**
 
The ontology opens when it's ready.
 
![Screenshot of the newly generated ontology.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-1-create-ontology/semantic-model/ontology-start.png)
 
*Your freshly generated ontology — now you verify and polish what it created.*
 
**3. Verify and rename entity types.** The generator names entity types after your tables (`factsales`, `dimstore`, `dimproducts`). Give them human-friendly names:
 
| Old name | New name |
| --- | --- |
| `factsales` | `SaleEvent` |
| `dimstore` | `Store` |
| `dimproducts` | `Products` *(plural, to avoid clashing with the GQL reserved word `PRODUCT`)* |
 
![Screenshot of the three renamed entity types.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-1-create-ontology/semantic-model/all-entity-types.png)
 
*The three entity types after renaming.*
 
> **If you see no entities at all**, check that your semantic model is published, the tables aren't hidden, and relationships are defined.
 
**4. Verify properties and keys.** Each entity type should carry the expected columns. The catch: `SaleEvent` won't have an auto-imported key, so add one manually - open `SaleEvent`, choose **Add entity type key**, and select `SaleId`. (`Store` keys on `StoreId`, `Products` on `ProductId`.)
 
**5. Verify bindings.** On the **Bindings** tab, confirm each entity type is wired to its source table (`SaleEvent → factsales`, `Store → dimstore`, `Products → dimproducts`).
 
**6. Configure relationships.** The relationships come in defined but not fully wired. Update them to match:
 
| New name | Source table | Source entity (column) | Target entity (column) |
| --- | --- | --- | --- |
| `soldIn` | `factsales` | `Products` (`ProductId`) | `SaleEvent` (`SaleId`) |
| `has` | `factsales` | `Store` (`StoreId`) | `SaleEvent` (`SaleId`) |
 
![Screenshot of a fully configured relationship on the SaleEvent entity type.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-1-create-ontology/semantic-model/verify-relationship-types.png)
 
*A relationship bound to its source columns — context made explicit.*
 
---
 
### Path B - Build an ontology directly from OneLake
 
No semantic model? No problem. You build the same thing by hand, which also gives you full control. The flow is: create the ontology item → create entity types → bind data → set keys → create and bind relationships.
 
**1. Create the ontology item.** In your workspace, click **+ New item**, search for **Ontology (preview)**, and select it.
 
![Screenshot of selecting the Ontology (preview) item from New item.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-1-create-ontology/onelake/new-ontology.png)
 
*Creating an ontology from scratch.*
 
Name it `RetailSalesOntology` and click **Create**. You get a blank canvas to work on.
 
**2. Add your first entity type (`Store`).** From the ribbon or canvas, click **Add entity type**, name it `Store`.
 
![Screenshot of the Add entity type action.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-1-create-ontology/onelake/add-entity-type.png)
 
*Adding an entity type manually.*
 
Then on the **Bindings** tab, choose **Add data to entity type**, connect to the `OntologyDataLH` lakehouse, pick the `dimstore` table, keep the binding type as **Static**, let the columns map automatically, and **Save**. Finally, **Add entity type key** and select `StoreId`.
 
**3. Add the other entity types.** Repeat the same steps for:
 
| Entity type | Source table | Key |
| --- | --- | --- |
| `Products` *(plural)* | `dimproducts` | `ProductId` |
| `SaleEvent` | `factsales` | `SaleId` |
 
**4. Create relationships.** Click **Add relationship** and define each one, then bind it to its source columns in `factsales`:
 
| Relationship | Source entity (column) | Target entity (column) |
| --- | --- | --- |
| `has` | `Store` (`StoreId`) | `SaleEvent` (`SaleId`) |
| `soldIn` | `Products` (`ProductId`) | `SaleEvent` (`SaleId`) |
 
![Screenshot of the two relationships targeting the SaleEvent entity type.](https://learn.microsoft.com/en-us/fabric/iq/ontology/media/tutorial-1-create-ontology/onelake/all-relationship-types.png)
 
*Both relationships pointing at `SaleEvent` — same result as the generated path, built by hand.*
 
Either way, you now have an ontology populated with entity types, properties, keys, and relationships. From here the tutorial goes on to **enrich** it with the live freezer telemetry (binding both static and time-series data), then explore it through the graph and natural-language queries via a data agent.
 
---
 
## When should you actually reach for this?
 
Fabric IQ isn't for every reporting job. It earns its place when:
 
- You need **cross-domain consistency** - the same concept used cleanly across many teams and tools.
- You care about **governance** - one trusted definition, with constraints enforcing quality.
- You're **grounding AI agents** and need them to speak your business's language, not hallucinate joins.
- Your decisions depend on **relationships and impact chains**, not just flat aggregations.
If your need is a single dashboard off one star schema, a plain semantic model is plenty. But the moment you're building agentic experiences, or you're tired of every team redefining "active customer" their own way, the ontology layer starts paying for itself.
 
---
 
## The takeaway
 
Fabric IQ is Microsoft's answer to a problem every data team eventually hits: **data without shared meaning doesn't scale to AI.** It sits on the unified OneLake foundation, reuses the Power BI semantic models you already trust, and adds an ontology layer that turns tables into the actual language of your business - complete with relationships, rules, a graph, and natural-language querying.
 
For us as data engineers, the appealing part is how little it asks us to throw away. Got a good semantic model? Generate an ontology from it in one click. Prefer full control? Build it from OneLake by hand. Either way, you end up with one governed, queryable, agent-ready model of your business - and you stop being the human translation layer.
 
It's still in preview, so expect some rough edges. But the direction is clear, and it's a genuinely good moment to start learning it hands-on.
 
---
 
### Useful links
 
- [What is Fabric IQ?](https://learn.microsoft.com/en-us/fabric/iq/overview)
- [What is ontology (preview)?](https://learn.microsoft.com/en-us/fabric/iq/ontology/overview)
- [Required tenant settings for ontology (preview)](https://learn.microsoft.com/en-us/fabric/iq/ontology/overview-tenant-settings)
- [Ontology tutorial — Part 0: Setup](https://learn.microsoft.com/en-us/fabric/iq/ontology/tutorial-0-introduction)
- [Ontology tutorial — Part 1: Create an ontology](https://learn.microsoft.com/en-us/fabric/iq/ontology/tutorial-1-create-ontology)
- [Sample data on GitHub](https://github.com/microsoft/fabric-samples/tree/main/docs-samples/iq)