Generating a Fabric IQ Ontology from a Semantic Model - What It Does and Where It Falls Short

Microsoft has been quietly building something interesting inside Fabric over the last year. They call it Fabric IQ, and the part that matters most for organisations doing AI work is the ontology layer. The pitch is simple. If you have a well-defined Power BI semantic model already, Fabric can generate an ontology from it. That ontology then becomes the structured, queryable knowledge layer that AI agents and other consumers can ground themselves against. Less hallucination, more answers tied to real entities and relationships.

Whether that pitch holds up depends on how much you trust your semantic model, what mode it runs in, and what you are actually trying to do with the ontology once it exists. We have been kicking the tyres on this with a few Australian clients, and there are some real strengths and some genuine sharp edges worth knowing about. Microsoft's own documentation on generating an ontology from a semantic model is the authoritative reference, but it reads as a feature description rather than a buyer's perspective. Here is the consultant version.

What ontology generation actually does

The feature takes a semantic model in Fabric - which in practice is a Power BI semantic model, since Fabric semantic models are built on the same engine - and generates a new ontology item in your workspace. The ontology contains entity types that mirror your semantic model tables, static properties on each entity type that come from the columns, data bindings linking ontology entities to rows in the underlying lakehouse tables, and relationship types between entities that follow the relationships you have already defined in the model.

The selling point is the time saved. If you have spent six months building a clean semantic model for a Power BI deployment, that work captures a lot of business meaning. The dimension tables, the relationships, the column names that people understand. Throwing all of that away to build an ontology from scratch would be wasteful. The generator reuses that effort.

After generation, there is still manual work to do. Time series properties are not created automatically. Entity type keys need to be reviewed, especially in multi-key situations. Relationship types need data bindings added in some modes. And you should walk the whole thing end to end to make sure entities, properties and relationships line up with how you actually think about the business.

In practice the generated ontology gets you maybe seventy to eighty percent of the way there for straightforward domains. Customers, products, orders, transactions. For more complex domains - manufacturing bills of materials, healthcare patient pathways, financial product hierarchies - the generator gives you a starting point but you need to do real domain modelling on top of it.

The semantic model mode question matters a lot

This is where the documentation deserves close reading and where many teams trip up. Ontology generation behaves differently depending on whether the underlying semantic model is in Import mode, Direct Lake mode, or DirectQuery mode.

For Import mode models, the generator can produce entity type definitions, property definitions and relationship definitions. But it cannot create entity type bindings to data sources, cannot create relationship type bindings to data sources, and you cannot query data through the ontology bindings. In other words, you get a structural skeleton but not a queryable knowledge graph. The entities exist, their relationships exist, but the rows do not flow through.

For Direct Lake mode, you get everything Import mode gives you plus actual data bindings. There is a catch though. Entity type bindings only generate when the backing lakehouse is in a workspace with inbound public access enabled. If your lakehouse is in a workspace that has public access disabled - which is what any sensible security posture would have for production data - the ontology item still gets created, but that entity type ends up with no data bindings. You have to enable public inbound access on the workspace to get the bindings, then presumably tighten it back down. That is not a great story for organisations with regulated data.

For DirectQuery mode, the generator can produce structural definitions but no data bindings. Same as Import mode in terms of the practical outcome.

For querying through the ontology bindings, Direct Lake is the only supported mode, and even then measures and calculated columns are not supported in the query path. You query the raw column data only.

The honest summary is that if you want a working, queryable ontology generated from your existing investment, you need Direct Lake mode and you need the workspace to allow inbound public access. Anyone with stricter network requirements is going to find this preview is not yet built for them.

The data shape constraints

Even within a supported mode, the data your semantic model is built on has to meet some specific requirements before it works cleanly.

The ontology only supports managed lakehouse tables - tables stored inside the lakehouse's own OneLake directory. If your semantic model references external tables that physically live elsewhere but are surfaced through the lakehouse, those will not work. This affects a lot of Fabric deployments where teams have been federating data across multiple storage accounts.

Delta tables with column mapping enabled are not supported by the ontology graph either. Column mapping gets turned on manually in some cases, but it also gets turned on automatically when column names contain certain special characters - commas, semicolons, braces, parentheses, newlines, tabs, equals signs, spaces. It also turns on automatically for the delta tables that back Import mode semantic model tables. So if your column names have any of those characters, or if your model is in Import mode, you can end up locked out of ontology features without realising why.

There is a Decimal type issue. Fabric Graph does not currently support the Decimal type. If your semantic model has tables with Decimal columns - which is exactly what you would use for monetary values - those properties return null on every query through the ontology. Double works, but Double is a floating-point type, which is the wrong tool for currency. This is a real problem for finance use cases and is the kind of thing that makes preview features feel preview.

Property naming has constraints too. You cannot have two entity types with the same property name unless the data types match. So if Customer has a string ID and Order has an integer ID, the generator may not produce both correctly. In practice this means doing a column rename pass on your semantic model before generating, or accepting that you will fix things by hand afterwards.

And finally, you cannot generate from a semantic model in My workspace. You need to be in a proper Fabric workspace.

When it is worth doing now

Despite the constraints, there are genuine cases where ontology generation pays off today. If you already have a clean Direct Lake semantic model in a Fabric workspace with reasonable network settings, the generator gets you to a working ontology in minutes rather than weeks. That is the case for some of our Microsoft Fabric consulting clients who have built proper Lakehouse architectures and want a knowledge layer for AI agents to query.

If you are building AI agents that need structured reasoning over enterprise data, having an ontology layer is the right architecture. The alternative - asking a language model to query a SQL warehouse directly through generated SQL - is fine for some use cases but has obvious problems for others. Ontology-grounded queries give you traceability, predictable performance, and a place to define semantics once rather than re-explaining them in every prompt.

If you are doing proof of concept work, the speed of generation is hard to argue with. You can have an ontology, do some experiments, and decide whether the architecture is right for you, all in an afternoon.

When to wait

There are situations where ontology generation in its current state is not the right move.

If your most important data is in Import mode for performance reasons, you do not get data bindings, which means most of the value of the ontology disappears. You can still generate the structure, but the entities are empty shells.

If your security posture does not allow public inbound access on lakehouse workspaces, you cannot get Direct Lake bindings to generate properly. That is a deal-breaker for regulated industries until Microsoft adds private endpoint support.

If your data has heavy use of Decimal columns - finance, billing, insurance - the null-return behaviour is too disruptive to work around. Wait for Decimal support.

If your semantic model is not clean to start with, do not expect ontology generation to fix it. The output is only as good as the input. If your relationships are wrong, your column names are inconsistent, or your dimensional model has issues, those problems get carried into the ontology and made harder to spot because they now live in two places.

Practical advice for getting started

If you decide to try ontology generation, here is what we would suggest based on early engagements.

Pick a small, well-understood domain first. Customers and orders is a fine starting point. Do not try to generate from your warehouse-wide semantic model on day one.

Use Direct Lake mode for the semantic model you generate from. Accept the inbound public access requirement on a non-production workspace while you experiment.

Audit your column types. Anything Decimal needs to be converted or excluded. Look at column names for special characters that will trigger column mapping.

Plan for manual work after generation. Budget time to add time series bindings, review entity keys, and walk the whole ontology end to end with someone who understands the domain.

Treat the ontology as a draft, not a finished product. The generator gives you a starting point. The shaping is still on you.

This is the kind of work where having someone who has been through it before saves a lot of frustration. Our Azure AI Foundry consultants and our Microsoft AI specialists have been working through Fabric IQ deployments with Australian clients and there is enough nuance that an experienced second opinion is worth getting.

The full Microsoft documentation is at Generating an ontology from semantic model. The feature is in preview, so expect things to move - both improvements and breaking changes - over the next few quarters. We will keep updating our AI consulting practice recommendations as the platform matures.