Build your enterprise IQ

Prepare the source and permissions

I reused the SalesAnalytics workspace and its existing SalesAnalytics_Model. Everything in this example is AdventureWorks or similar synthetic data. We do not need a real-time stream to prove the business-context layer.

• Use a Fabric-capacity-backed workspace.
• Ask your administrator to enable Users can create Fabric items and Users can create ontology (preview) items.
• Use Contributor or higher for authoring, plus Read and Build on the source semantic model.
• Viewing a metric's original DAX additionally requires Write on the source semantic model. Do not give every consumer admin rights.

The agent acts with your identity. Ontology access does not grant access to the bound sources or bypass their security. I used my demo administrator account for setup, not as a recommended production access pattern.

Before prompting, know the grain. My source has seven tables, 69 columns and 17 measures. The fact table is at order-line grain; the order dimension represents the header.

Your AdventureWorks transformation may use different names, row counts or keys. Substitute your actual model and check its relationships. The results in this article are a baseline for this demo, not universal AdventureWorks totals.

Create the new ontology

In the workspace, select New item, search for Ontology (preview) and open it. Enter EnterpriseIQ_Sales, confirm the workspace and select Create.

Provisioning took roughly two minutes in my run. I waited for the item to finish rather than creating a second one. The portal then displayed You are in the new experience.

Yes, use “Start with Ontology agent”

On the empty item, select Start with Ontology agent. This is the route I used, rather than manually drawing seven entities.

Keep the agent in Plan mode. It can discover, draft, validate, explain and query, but cannot apply ontology changes. Act mode enables those writes.

This was my discovery prompt. It names the source, sets a boundary and gives the agent the business distinction it should not guess:

Build a sales ontology for the AdventureWorks demo using only SalesAnalytics_Model in this workspace. Stay in Plan mode: discover, draft and validate, but do not apply yet.

Reuse the model's seven tables and six existing relationships, calculated columns and all DAX measures as metrics. Preserve the source model and data unchanged.

Make the business meaning explicit: fact_salesorder is an order LINE, not one row per order; dim_order is the order header; dim_customer and dim_product describe the customer and product. Keep dim_orderdate and dim_shipdate distinct.

Use friendly names where possible, with clear source mappings and original stable identifiers. For sales questions reuse Total Sales, Total Orders and Avg Order Value; do not sum repeated header amounts or invent a new revenue formula.

Show the proposed entities, keys, relationships, metrics and validation warnings, and provide a canvas preview before applying.

A focused prompt matters more than a poetic one. This workspace also contains lakehouses, a warehouse and other experiments. “Use everything” would have been a very different instruction.

Review meaning, not just green ticks

The agent discovered the complete model and returned seven entity types, six relationships and all 17 metrics. Its validation reported no warnings.

The documented agent flow can also expose a read-only canvas preview. Open it if offered and inspect properties, bindings and relationships there. The exact suggestions and preview presentation can vary.

My review focused on four things: the line key was SalesOrderDetailID, not the repeated order ID; all six source joins were represented; Order Date and Ship Date remained separate roles; and sales calculations referred back to existing measures.

Read the generated descriptions too. A plausible phrase such as “allocated freight” is not evidence that an allocation actually happened upstream. Keep ambiguous semantics qualified until the source owner confirms them.

Apply the reviewed draft

Switch the toggle to Act, then explicitly ask the agent to apply the scoped draft:

Apply the validated AdventureWorks sales ontology draft now. Only update this EnterpriseIQ_Sales ontology.

Preserve all seven source table bindings, six source relationships and 17 source-owned metrics, friendly names and the distinct date roles as reviewed.

Do not modify any source model or data. Confirm the applied entity/relationship/metric counts and whether the definition was persisted.

The agent confirmed that the definition was persisted. The empty Get started page became the ontology canvas. I also read back the saved definition through the Fabric API: it contained the seven entity definitions, six entity relationships and source-linked measures. This was no longer just a chat proposal.

“Publish” in this agent flow means saving the ontology definition in Fabric. It does not publish your data or this article to the internet.

Inspect a metric instead of inventing revenue

Select Sales Order Line, open View Entity Type details, then find the Metrics section on Configure. This entity has 17 because the source measures live on fact_salesorder.

Search for Total Sales, open it and use Resolve underlying DAX in the Expression area. The first resolution was slower in my run. The returned expression was the existing source measure:

Total Sales = SUM(fact_salesorder[LineTotal])
Total Orders = DISTINCTCOUNT(fact_salesorder[SalesOrderID])
Avg Order Value = DIVIDE([Total Sales], [Total Orders])

Ontology metrics proxy source measures. The source model owns the calculation; ontology adds context and a source link. Source changes are not automatically reflected everywhere: refresh the ontology when reviewing changed measures.

Ask a business question, then read the query

Reopen Ontology agent from Home and return to Plan. Querying does not require Act mode. Ask for evidence, not just an answer:

Run a read-only post-create validation against the saved ontology and its bound SalesAnalytics_Model.

Across all available data, with no current-date filter, what are Total Sales, Total Orders and Avg Order Value? Reuse exactly those source measures.

Also report the sales order line row count, distinct SalesOrderDetailID count, first and last OrderDate. Show the DAX query actually executed and the returned values.

Explain why sales order line count is not order count, and why Order Date and Ship Date stay separate. Do not change the ontology or source. Do not infer currency.

The agent ran DAX and returned the same three business-metric values as my independent pre-build query against the source model.

I have left the values in source units rather than inferring a business currency from formatting. This is also a small, single-day demo: it does not establish performance, seasonality or behavior across a production estate.

EVALUATE
ROW(
    "Total Sales", CALCULATE([Total Sales], REMOVEFILTERS()),
    "Total Orders", CALCULATE([Total Orders], REMOVEFILTERS()),
    "Avg Order Value", CALCULATE([Avg Order Value], REMOVEFILTERS()),
    "Sales Order Line Row Count", COUNTROWS('fact_salesorder'),
    "Distinct SalesOrderDetailID Count",
        DISTINCTCOUNT('fact_salesorder'[SalesOrderDetailID]),
    "First OrderDate", MIN('fact_salesorder'[OrderDate]),
    "Last OrderDate", MAX('fact_salesorder'[OrderDate])
)

Three practical questions through Copilot

Then I switched to Act and asked the Ontology Agent three ordinary sales questions. Copilot executed DAX against SalesAnalytics_Model, using the ontology's Order Date, Customer and Product concepts. I ran equivalent DAX directly against the source model as an independent check. All returned rows and values matched.

These are the prompts I actually sent in Act mode. You can copy them into your own Ontology Agent conversation:

Using the source-bound metrics in this ontology, show Total Sales, Total Orders, and Avg Order Value by Order Date year. Identify the year with the highest Total Sales. Use the canonical measures, not a line-row count or repeated order-header amount.

Which five customers generated the highest Total Sales? Return each customer's CompanyName and Total Sales, sorted from highest to lowest. Use the Customer relationship and the canonical Total Sales measure.

Which product categories generated the most Total Sales? Show CategoryName and Total Sales, sorted from highest to lowest, and return the top five categories. Use the Product relationship and the canonical Total Sales measure.

EVALUATE
SUMMARIZECOLUMNS(
    'dim_orderdate'[year],
    "Total Sales", [Total Sales],
    "Total Orders", [Total Orders],
    "Avg Order Value", [Avg Order Value]
)
ORDER BY 'dim_orderdate'[year]

EVALUATE
TOPN(
    5,
    SUMMARIZECOLUMNS(
        'dim_customer'[CompanyName],
        "Total Sales", [Total Sales]
    ),
    [Total Sales], DESC
)
ORDER BY [Total Sales] DESC

EVALUATE
SUMMARIZECOLUMNS(
    'dim_product'[CategoryName],
    "Total Sales", [Total Sales]
)
ORDER BY [Total Sales] DESC

Ask the ontology from Microsoft 365 Copilot

The same ontology can now be used from the native Microsoft 365 Copilot experience. This is not Copilot Studio: I published the Fabric Data Agent, kept Work IQ enabled, and selected EnterpriseIQ_Sales_Copilot from the Microsoft 365 Copilot Agent Store. The agent is backed by EnterpriseIQ_Sales, not by a loose prompt over the semantic model.

1. Open Microsoft 365 Copilot with the account that has access to the Fabric workspace.
2. Open Agents, choose EnterpriseIQ_Sales_Copilot, and keep Work IQ switched on.
3. Ask a normal business question in English or Dutch.

For example, I asked: What were total sales by year? Copilot returned 2025: $35,854,355.90. I then asked which customers generated the most sales; the answer ranked the customers using the ontology's Customer relationship and the canonical TotalDue measure.

The Dutch route works as well. The same agent answered Welke klanten genereerden de meeste omzet? in Dutch and returned the same ranking, with localized numeric formatting.

Move the sales rule out of the chat

A good prompt is useful. A business definition that disappears when the conversation ends is less useful. I added a rule to the ontology so its intended interpretation is stored with the concepts.

1. In Explorer, expand Overview and select Rules.
2. Select Create rule and enter Sales grain and canonical metrics.
3. Paste the definition below.
4. Select Add concept, then select Sales Order Line, Sales Order Header, Order Date and Ship Date on the Entity types tab. Save that selection.
5. Select Save on the rule page. Reopen it to confirm the definition and links persisted.

Sales Order Line represents one order line, not an entire Sales Order Header. Sales reporting must use the source measures Total Sales, Total Orders and Avg Order Value. Do not use line row count as order count or sum repeated header amounts across lines. Order Date and Ship Date represent different business events and must remain distinct.

The preview boundaries that matter

Ontology Agent is not the same as Fabric Data Agent. I tested the agent inside the ontology item. The current troubleshooting documentation lists a known issue with a separate Data Agent consuming an ontology that uses semantic-model bindings. I did not connect the existing sales Data Agent and will not claim that path works.

The conversation is temporary. During preview, refreshing the page or closing the tab ends the agent conversation; a conversation also cannot continue beyond 24 hours. Save useful prompts and persist reviewed definitions. Do not treat chat history as version control.

Check your own rollout. This was tested on 17 October 2026. The item, agent and documentation are preview surfaces. Labels, suggestions and availability can change. If the new experience or agent is missing, check tenant settings, permissions and current known issues before falling back to legacy instructions.

For a different Fabric IQ use case, my practical guide to Plan in Microsoft Fabric covers planning input and writeback. That is a separate job: an ontology supplies business context, not an editable planning store.

Reproduce and clean up

To reproduce the workflow, use your own seven-table sales model, the mapping above, the three setup prompts and the three Copilot query prompts. Run the displayed DAX against your source model and compare your totals, key uniqueness, relationships and date range. All screenshots here are from the executed demo, cropped to the relevant controls or result.

For cleanup, delete only the new EnterpriseIQ_Sales ontology after checking its consumers. Keep SalesAnalytics_Model and its underlying data. No source cleanup or model rollback is required by this walkthrough. Do not disable tenant settings or delete a shared workspace just to remove this demo.

My take

The interesting part is not that an agent can draw a star-shaped diagram. We have had diagrams for a while.

It is that we can carry an existing semantic investment into a reusable business vocabulary, keep the calculation owner explicit and put the awkward distinctions where consumers can find them. An order line is not an order. Ship date is not order date. Imported does not mean audited.

Start with one domain, preserve the trusted calculations and make the agent show its query. Shared language is useful only when it survives contact with the numbers.