Entity

Ask three teams one simple question: how many customers do we have?

Sales says 40,000. Billing says 38,000. Support says 44,000.

No one is wrong. No one made a mistake. The three teams just never agreed on what a "customer" is, so each of their tables decided on its own.

One definition, on top of the tables

Where does "customer" actually live? Not in any single table. The sales CRM has one version, billing has another, the support desk a third. Each one is a slightly different picture of the same real companies.

An entity sits on top of all of them and says: this is what a Customer is, and these three tables all describe it. Three tables, one definition, one answer.

Why this matters for an AI agent

This matters most once an AI agent is involved. Point an agent at the raw tables and ask how many customers you have, and it runs into the same problem the teams did. Three tables, three answers. It picks one and sounds completely sure.

Give it the entity instead, and it has one clear definition to work from. An agent is only as good as the meaning you give it, and the entity is that meaning.

You can try that decision yourself at the end of this page: bind the three department sources to one Customer and watch the rows join into one shared definition. The widget also asks you to pick the column that identifies a customer. That choice is a preview of a concept two pages ahead, the key, and the widget shows why it will matter.

Where the decision lives in Fabric

In Microsoft Fabric this decision has a name: the entity type. You define Customer once, above the tables, and connect all three sources to it. The entity type carries the properties that describe a customer, and an entity type key is what identifies one single instance of it.

Connecting it to real data is a binding. The entity type points at a source in OneLake: a lakehouse table, an eventhouse KQL table, or a Power BI semantic model. All three of your department sources can bind to the same entity type. Sales, billing, and support keep their own tables. The one definition above them stays single, which is exactly what we want.

It helps to know which parts are solid here, because the status is mixed, not one label for everything. As of July 2026 the graph engine is generally available, and so are the data agent (Fabric's name for an AI agent grounded in your data) and the Power BI semantic model. The ontology item, which is where entity types live, is still in preview, and so is pointing a data agent at a graph or an ontology. The idea is settled. Some of the parts are still changing.

The one trap

Do not point at a single table and call it "the customer entity." That just gives the definition back to that one table, and you are right back to three answers. The entity sits above your tables, never inside one of them.

You have named a thing. Next you describe it, with properties.