Integrations

A salesperson opens Copilot in Teams and types a question in the middle of a busy morning: which of my accounts are at risk this quarter?

Two floors down, a developer is building an app in Azure AI Foundry. Same question, but it goes out as a line of code. Across the building, an analyst is building an agent in Copilot Studio. She drags a step onto a canvas that asks the same thing a third way.

Three people. Three tools. Three completely different doors. And all three get the same answer, down to the same three account names and the same numbers behind them.

That last part is the whole story. It only happens because those were never three models. It was one.

Rebuilding in every tool fails slowly

Here is what happens when nobody decides otherwise. The chat tool builds its own small model of what an "account at risk" means. The app team codes their own version. The agent builder makes a third. Each one is fine on its own. Together they are three answers waiting to disagree.

And they will disagree, because they drift apart. Someone changes the risk rule in one place and not the others. Six months later the salesperson, the developer, and the analyst are looking at three different truths. The meeting to sort them out costs more than building the model right would have. The failure is quiet. It is a slow spread of near-copies that no longer match.

The fix is simple and strong: build the meaning once, in one governed place, and let every tool read it instead of working it out again.

One model, many doors

Reuse changes the whole shape. Instead of the model living inside a tool, the tools sit around the model. Each surface is just a different door onto the same shared meaning.

The salesperson asks in plain words. The developer asks in code. The analyst asks with a flow step. Those are three truly different ways to ask, and they should be, because those are three truly different jobs. What must not differ is the meaning underneath. When it is one model, the wording can change freely and the answer still holds, because every door opens onto the same room.

This is also why doing the earlier work well matters. Every entity you named, every key you picked, every relationship you bound: that effort is not spent once and forgotten. It gets reused on every surface, forever. The value adds up across your whole organization. A messy model spreads its mess to every door. A good one spreads its care.

Try the doors yourself. Pick a surface, watch it ask its own way, and read back what stays the same.

The question changed shape three times. The answer never moved, and the rebuild counter sat at zero, because there was one model the whole time.

The Fabric IQ ontology reaches past Fabric

You built the ontology and the knowledge graph inside Fabric, over your data in OneLake, with no copy out to a separate store. The reuse idea is that this model does not have to stay in Fabric to be useful.

The Fabric IQ ontology is meant to surface beyond Fabric. The same governed model can ground agents in Microsoft 365 Copilot, in Azure AI Foundry, and in Copilot Studio. On each of those surfaces the thing answering you is a data agent, an AI agent grounded in your data, and what grounds it is the one ontology you already published. The salesperson in Copilot, the app on Foundry, the custom agent in Copilot Studio: different front doors, one shared meaning underneath.

The payoff is the same one you saw in the general idea. One knowledge graph, governed once over OneLake, reasoned over through GQL when a surface needs to traverse it, and reused across every place work happens instead of rebuilt per tool. That is what makes the ontology worth building, rather than a fourth private model nobody trusts. Fabric IQ is in preview as of July 2026, so treat the exact list of surfaces and the details of each integration as still changing. The lasting part is not any one connector. It is the shape: one governed model, many surfaces reading it.

The one trap, and where to go build it

The trap is treating integration as an afterthought, a thing you add on once the model is done. It is the opposite. Reuse is the reason to build the model at all. If the meaning only ever lives inside one tool, you have not built shared infrastructure. You have built a fourth silo with a nicer name. Build your model as if every tool in your organization will read it, because the good ones will.

That completes the journey. You started at a spoiled freezer and a number nobody could understand. You gave things names and properties, picked keys that decide identity, drew relationships, bound them to real rows, and watched a knowledge graph get built. You saw an AI agent walk through it to answer questions no table held, planned the model as a shared asset, and now brought that one governed meaning to every door people and agents work behind.

There is one thing left, and it is the best one: build it. Open the ontology lab, bring your own data or the demo set, and take a model all the way from a pile of CSVs to a graph an agent can reason over. Everything on these pages was leading here.