Building a Governed Customer 360 Data Product on Microsoft Fabric

[Saradha]

AI is not making enterprise data architecture obsolete. It is making the quality of that architecture more consequential, because AI systems depend on the same definitions, context, controls, and history that made enterprise data useful in the first place. Copilots and agents are now consumers of enterprise data alongside people.

Ask an agent "What was our revenue last quarter?" and a database will happily return a number. It cannot say whether that is gross, net, booked, billed, or recognized revenue. That context (ownership, calculation logic, freshness, lineage, business rules) lives in metadata, catalogs, and semantic layers. Making data available is step one. Making its meaning discoverable is what makes it usable by AI.

The architecture​

The design rule is simple: build the governed data product once, expose it through many interfaces, and add explicit business context on top. The interface changes; the definition does not.

How the layers map to Fabric (Figure 2 shows them in one picture)

Layer	Fabric component	What a developer ships
Ingest	Mirroring, Data Factory, Eventstreams	Pipelines, mirrored sources, CDC and stream configs
Curate	Lakehouse (Bronze, Silver), notebooks	PySpark transforms, DQ rules, quarantine tables
Publish	Gold layer, SQL analytics endpoint	Customer 360 view and data contract
Consume	Direct Lake, GraphQL, vector index	Views, API schema, feature tables, retrieval index
Context	OneLake catalog, Purview, Fabric IQ, semantic model	Glossary terms, ontology relationships, DAX measures
Serve AI	Fabric IQ MCP, Fabric MCP, custom server	Scoped tools with typed inputs and outputs
Agents	Fabric data agent, Foundry, Copilot Studio	Agent definitions bound to approved tools
Govern	Entra ID, OneLake security, Purview policies	Roles, masking, audit logging, traces

Figure 1 is the platform-neutral blueprint from the book. Each layer answers one question: what is the trusted product, who consumes it, what does it mean, and what may an agent touch. Meaning sits before agent access, so an agent never has to infer what "active customer" or customer_id means. Figure 2 is the same model built on Microsoft Fabric, with the ingestion pipeline underneath, a catalog and glossary in the context layer, and MCP servers as the agent interface.

Step by step​

1. Ingest. Bring CRM, order, product, and support data into OneLake with Mirroring or CDC for operational databases, Data Factory for batch, and Eventstreams for events. Land it raw in Bronze with lineage columns.

2. Curate. Deduplicate, standardize, and validate in Silver. Send bad rows to a quarantine table and gate the load on a quality threshold so a bad batch never reaches the product.

PySpark: Silver with dedupe and a data quality gate

from pyspark.sql import Window, functions as Fw = Window.partitionBy("customer_id").orderBy(F.col("updated_at").desc())silver = (spark.table("bronze.crm_accounts").withColumn("rn", F.row_number().over(w)).filter("rn = 1").drop("rn"))ok = F.col("customer_id").isNotNull() & F.col("email").rlike(r"^[^@\s]+@[^@\s]+$")silver.filter(~ok).write.mode("append").saveAsTable("silver.quarantine_customer")assert silver.filter(~ok).count() / max(silver.count(), 1) < 0.01, "DQ gate failed"silver.filter(ok).write.mode("overwrite").saveAsTable("silver.dim_customer")

3. Publish the data product. A Customer 360 product is not a wide table. It is a governed view with a declared grain, owner, freshness target, and contract. Publish it as a view over Gold so the contract stays stable while the implementation evolves, and keep the contract in source control.

SQL analytics endpoint: Customer 360 view (one row per customer)

CREATE VIEW gold.customer_360_v AS
SELECT c.customer_id, c.customer_name, c.segment, c.account_status,
o.orders_12m, o.net_revenue_12m, s.open_cases
FROM silver.dim_customer c
LEFT JOIN (SELECT customer_id, COUNT(*) AS orders_12m,
SUM(gross_amount - discount) AS net_revenue_12m
FROM gold.fact_orders
WHERE order_date >= DATEADD(month, -12, CAST(GETDATE() AS date))
GROUP BY customer_id) o ON o.customer_id = c.customer_id
LEFT JOIN (SELECT customer_id, COUNT(*) AS open_cases
FROM gold.fact_support_cases WHERE status <> 'Closed'
GROUP BY customer_id) s ON s.customer_id = c.customer_id;

customer_360.contract.yaml

data_product: customer_360
owner: customer-data-team
grain: one row per customer_id
freshness_sla_minutes: 60
quality: [customer_id: unique_not_null, email: valid_format]
columns:
- {name: net_revenue_12m, glossary_term: Net Revenue}
- {name: account_status,  glossary_term: Active Customer}

4. Expose the consumption layer. One product, many consumers: SQL and Direct Lake for analysts, GraphQL for applications, feature tables for ML, a retrieval index for generative apps, and constrained tools for agents. This is the reuse boundary that stops every team from building its own definition of a customer.

5. Add context. This is what lets an agent understand the data instead of guessing:

• Catalog: the OneLake catalog is built into Fabric and gives discovery, lineage, sensitivity labels, and access views for every item, with no setup.
• Business glossary: approved terms like "active customer" with owners and definitions, held in the Microsoft Purview Unified Catalog.
• Ontology: relationships such as Customer places Order and Customer submits Support Case. In Fabric this is Fabric IQ, generated from your Power BI semantic models.
• Semantic layer: approved metrics, so "net revenue" means one thing everywhere.

Power BI semantic model: approved measures (DAX)

Net Revenue = SUMX ( Orders, Orders[gross_amount] - Orders[discount] )

Active Customers = CALCULATE ( DISTINCTCOUNT ( Orders[customer_id] ),
DATESINPERIOD ( 'Date'[Date], MAX ( 'Date'[Date] ), -12, MONTH ) )

6. Govern and observe. For AI, governance is a runtime control. Enforce identity and permissions with Entra ID and OneLake security, mask sensitive columns, and trace every agent call so one record connects the question, the glossary term, the ontology path, the tool, the data product, and the answer.

7. Serve AI through MCP. Agents should use constrained tools, not raw table access. Fabric IQ exposes the ontology through an MCP server (list_ontology_entity_types and search_ontology), and Fabric offers MCP servers for catalog and item operations. For your own product actions, write a small custom server: narrow, typed, read-only by default, parameterized, and logged.

Custom MCP server (Python MCP SDK): one scoped, read-only tool

import logging, os, pyodbcfrom mcp.server.fastmcp import FastMCPmcp = FastMCP("customer360")log = logging.getLogger("c360.audit")@mcp.tool()def get_customer_summary(customer_id: str) -> dict:    """Approved Customer 360 profile for one customer (read-only)."""    # connect as the caller so OneLake security and masking apply    with pyodbc.connect(os.environ["FABRIC_SQL_CONN_STR"]) as conn:        cur = conn.cursor()        cur.execute("SELECT * FROM gold.customer_360_v WHERE customer_id = ?", customer_id)        row, cols = cur.fetchone(), [c[0] for c in cur.description]        log.info("tool=get_customer_summary customer_id=%s found=%s", customer_id, bool(row))        return dict(zip(cols, row)) if row else {"error": "customer_not_found"}if name == "main":    mcp.run()

What the agent can answer. Once the product, ontology, and tools are in place, questions like these resolve through a defined path rather than free-form SQL:

Question	Resolved through
Summarize this customer's recent orders and open support cases	Tool get_customer_summary on gold.customer_360_v
Which products has this customer bought in the last 12 months?	Ontology path: Customer, Order, Product
Is there an unresolved support case tied to an order?	Ontology path: Customer, SupportCase, Order
What is this customer's lifetime value, and how is it defined?	Semantic measure plus the glossary definition
Which systems contributed to this profile?	OneLake catalog lineage for the data product

Agents built on the Fabric data agent, Foundry, or Copilot Studio can then use the ontology and these tools as their approved sources. Several of these pieces, including the ontology and its MCP server, are in preview today, so keep the semantic model and custom tools as the stable base.

Designing for scale and safety​

• One copy of data. OneLake, shortcuts, and Direct Lake avoid duplicating data per consumer.
• Add consumers, not copies. A new use case gets a new interface over the same product, never a separate "AI customer table".
• Contracts as code. Version the contract, glossary mappings, and semantic model in Git and promote them through deployment pipelines.
• Guardrails for agents. Tools declare inputs, outputs, permissions, and side effects; high-impact actions get validation, human review, and rollback.

How we apply this​

This is the approach we follow in our organization, built on the concepts in Rangdale Srinivasa Rao’s book: build trusted data products once, make them reusable, add explicit business context, and expose governed interfaces to AI. A practical order of work is to publish the data product, add the semantic model and glossary, register it in the catalog, define the ontology, expose read-only MCP tools, and turn on tracing and permissions before widening agent access.

The warehouse may now sit beside a lakehouse, a semantic layer, a vector index, and an agent runtime. Its discipline remains essential, because AI is only as useful as the context, permissions, and trustworthy data around it.

This article is adapted from Rajaganapathi Rangdale Srinivasa Rao’s book, Unlock the Future of Enterprise Intelligence: From Traditional Data Warehousing to Agentic AI. The book examines the evolution from relational and warehouse systems to cloud platforms, governed data products, AI pipelines, and agentic architectures.