Fabric IQ Ontology: Build Your First One
How to build a Fabric IQ ontology: generating one from a Power BI semantic model, the manual lakehouse route, and the finishing work Microsoft leaves to you.
An ontology is the part of Fabric IQ that does the actual work. Fabric IQ is the context layer; the ontology is the thing inside it that tells an AI agent what a Customer is, what a Store is, and how the two relate. Without one, an agent is back to inferring meaning from column names.
Microsoft documents two routes to building one. They suit very different starting positions, and picking the wrong one wastes weeks.
Everything below is preview. The ontology, the tutorials and the ontology agent are all marked preview on Microsoft Learn, the UI moves, and you should check Learn before planning around any specific screen.
Before you start
Two gates catch people:
- Tenant settings. If Fabric cannot create the ontology item at all, the required tenant settings are not enabled. That is an admin conversation, not a bug.
- Permissions. Binding a semantic model to an ontology needs both Read and Build on that model. Read alone is not enough, and this is a common first-day blocker in organisations where Build is tightly held.
Route 1: generate from a semantic model
This is the route to take if you already have a mature Power BI estate, and it is the one most enterprises should use.
Generation gives you a substantial head start. From the semantic model, Fabric creates:
- Entity types matching the tables
- Properties based on the table columns
- Data bindings connecting those entities to the source
- Relationship types drawn from the relationships already defined in the model
That is the skeleton of an ontology produced from work you have already done. Your star schemas and your defined relationships become the agent's vocabulary.
What generation does not finish
Generation is a starting point, not a finished ontology. Microsoft lists the work you complete by hand afterwards:
- Bind time series data to entity types. Generation does not do this for you.
- Review entity type keys and add any that are missing. Keys are what make instances resolvable; a missing one surfaces later as an agent that cannot find a specific record.
- Bind relationship types to data. The relationship types come across; the bindings that populate them with instances do not.
- Rename entities to friendly names. Table names are built for modellers. Agents speak to users, and `dimlocations` is not a word anyone says out loud.
Step 4 sounds cosmetic and is not. The whole point of the ontology is that the agent uses your business vocabulary. Leaving warehouse naming in place defeats the exercise.
Route 2: build manually from a lakehouse
Take this route when the data you need is in OneLake and there is no semantic model worth generating from.
The order is:
- Create an entity type.
- Add properties by binding columns from lakehouse tables to it.
- Use inheritance where it fits. Microsoft's own tutorial builds a Location entity from a locations dimension table, then builds a Store entity that *inherits* from Location. Modelling the general case once and specialising it is usually cleaner than repeating properties across several entity types.
- Add relationships last.
Relationships have a precondition
You cannot create a relationship just because the business has one. Before you bind a relationship type:
- the source data must be in OneLake, and
- it must contain keys for both the source and the target entity type
Then the sequence is: create the relationship type, then bind data to it to create the relationship instances. Type first, instances second.
If the keys are not there, that is a data engineering task upstream, not something to work around in the ontology.
Which route, and how to choose
| Starting position | Route |
|---|---|
| Mature Power BI estate, curated semantic models | Generate from the semantic model |
| Data in OneLake, no semantic model worth reusing | Build manually |
| Semantic models exist but are inconsistent | Fix the models first, then generate |
That third row is the one worth sitting with. Generation copies what it finds. If Finance and Operations have each defined their own version of a measure, generation does not reconcile them, it propagates both into the agent's vocabulary. The ontology makes existing semantic-model debt visible rather than fixing it.
A sensible first ontology
Resist the urge to model the enterprise. A first ontology that is worth building looks like:
- One subject area, with data already clean and in OneLake
- A handful of entity types, not forty
- Keys verified before you start, not discovered halfway
- Friendly names agreed with the business, because this is a vocabulary exercise as much as a modelling one
- A real agent question you want answered, so you can tell whether it worked
Then test it with the ontology agent and see whether the answers use your language. That is the acceptance criterion.
The part most teams underestimate
Building the ontology is modelling work, and modellers are comfortable with it. Agreeing the vocabulary is not. An ontology encodes a decision about what words mean, and in most organisations those decisions have never been made explicitly, only implemented differently in different reports.
That disagreement surfaces the moment you name an entity type. It is better to find it there than in an agent's answer to an executive.
*Sources: Microsoft Learn - Get started with Fabric IQ; Tutorial part 1, Create an ontology (both the semantic-model and manual routes); Generate ontology from semantic models; Bind data; Add relationship types. All preview as at 25 October 2026 - verify on Learn before planning around any specific step.*
Frequently Asked Questions
Do I need a Power BI semantic model to build a Fabric IQ ontology?
No. Microsoft documents two routes: generating an ontology from an existing semantic model, or building one manually from lakehouse tables in OneLake. The semantic-model route is faster if you already have curated models, because it creates entity types from tables, properties from columns, data bindings, and relationship types from the relationships already defined in the model.
What permissions do I need to bind a semantic model to an ontology?
Both Read and Build on the semantic model. Read alone is not sufficient, which is a common first-day blocker in organisations where Build permission is tightly controlled.
What does generating an ontology from a semantic model not do?
Four things are left to you: binding time series data to entity types, reviewing entity type keys and adding any that are missing, binding relationship types to data so they have instances, and renaming entities to friendly names. Generation produces a skeleton, not a finished ontology.
What has to be true before I can create a relationship in an ontology?
The source data must be in OneLake and must contain keys for both the source and the target entity type. You then create the relationship type first and bind data to it afterwards to create the relationship instances. Missing keys are an upstream data engineering problem.
Is Fabric IQ ontology generally available?
No. Fabric IQ itself reached general availability, but the ontology is still in preview, as are the tutorials and the ontology agent. The ontology agent is also disabled by default if your capacity sits outside the supported regions. Check Microsoft Learn for current status before planning around it.