Every Microsoft Fabric Feature, Explained
A living catalog of 89 Microsoft Fabric capabilities across 11 catalog tabs: what each is, when to use it, when to skip it, and its GA or preview month.
Copilot and Fabric Data Agents answer from your semantic model's metadata, so preparing the model is the real AI work. A persona-mapped, flowchart-driven guide with brownfield and greenfield checklists.
In Microsoft Fabric, Copilot and Data Agents build their answers from your semantic model's metadata, the table and column names, descriptions, synonyms, relationships, and measures, not from the raw rows underneath. So the quality of an AI answer is capped by how well the model describes itself, and "AI-ready" is something you engineer into the model, not a switch you flip.
Every AI experience in Fabric that answers a business question routes through the semantic model. Copilot in Power BI turns a natural-language question into a DAX query using the model's metadata plus its Prep for AI configuration. A Fabric Data Agent does the same across more sources, translating questions into DAX, SQL, or KQL. Publish that agent into Microsoft 365 Copilot and the same model answers questions from Teams or Word. None of these read your data to decide what a question means. They read the description of your data and generate a query from it.
The practical consequence: the highest-leverage AI work in Fabric is making the model legible, well ahead of prompt engineering or agent orchestration. DIM_GEO_01 tells an agent nothing; Sales Region with a one-line description tells it what the column is, what it filters, and how a person would ask about it.
Readiness is rarely one team's job, and treating it as "the BI developer's problem" is why so many models stall halfway. Each slice has a natural owner, and a model is ready only when every row below is satisfied.
| Persona | Owns in model prep | "Done" signal |
|---|---|---|
| Semantic model developer | Names, descriptions, measures, relationships, and the Prep for AI configuration | Schema trimmed, 90%+ descriptions, relationships complete |
| Analytics architect | Domain scoping, naming standards, endorsement and promotion gates | Models are domain-sized; standards documented and enforced |
| Data engineer | Upstream data quality, star schema, grain, and freshness | Clean grain, no unexpected nulls in filter columns |
| Data steward / business SME | Business term definitions, synonyms, and the questions Verified Answers must cover | Top questions verified and reviewed for business correctness |
| Governance / admin | Tenant settings (regions, cross-geo), RLS/CLS, Copilot enablement and capacity | Permissions enforced; Copilot enabled per policy and budget |
The pattern to notice: the developer owns the mechanics, but the steward owns the meaning. A model can be technically immaculate and still give confidently wrong answers if no one who understands the business validated what "revenue" means.
The work is the same loop whether the model is new or existing. Only the entry point differs: a brownfield model starts with an honest inventory, a greenfield model starts with a domain-scoped design. From there the path converges, and the accuracy gate at the end is a loop, not a finish line.
Three stages carry most of the outcome. Enriching metadata is the highest return on effort: descriptions written for a business reader, cryptic names fixed or given synonyms, and relationships repaired, since a missing join is a leading cause of wrong DAX. Configuring Prep for AI is where you set the boundary: the AI Data Schema decides what AI can even see, and a smaller, sharper schema is both more accurate and faster than exposing the whole model. Validating is non-negotiable, because AI-generated DAX is probabilistic and complex time-intelligence questions are where it fails. Test questions in the sandbox first, then measure against a ground-truth set of known-good answers, weekly and on every model change; Microsoft's Data Agent evaluation SDK (preview) automates that measurement.
Warning
Region and compliance. The Azure OpenAI service behind Copilot runs only in US datacenters and the EU data boundary. If your capacity is elsewhere, Copilot is off by default until an admin enables the cross-geo processing tenant setting, which carries data-residency implications worth reviewing first. Copilot is also all-or-nothing per workload: you cannot enable it for one experience and disable it for another.
Same destination, different starting work. Use whichever matches the model in front of you.
Semantic-model prep is the foundation, and it sits inside a wider surface worth knowing. Copilot is embedded across Data Factory, Data Engineering, Data Warehouse, and Real-Time Intelligence, each grounded in item-level metadata. AI Functions (generally available) bring one-line LLM enrichments like ai.classify and ai.summarize to notebooks, with a preview set now in Data Warehouse via T-SQL. Fabric IQ (preview) is Microsoft's direction for shared business semantics, spanning ontology, the Power BI semantic model, Fabric Graph, Plan, Data Agents, and Operations Agents, with ontologies now exposable through a Model Context Protocol endpoint so outside agents can ground on them. Every layer rewards the same discipline: the better the model describes itself, the better everything above it performs.
A living catalog of 89 Microsoft Fabric capabilities across 11 catalog tabs: what each is, when to use it, when to skip it, and its GA or preview month.
Delta Lake and Apache Iceberg now match on core capabilities, so the choice comes down to three questions: which engine writes the table, which catalog governs it, and who must read it without a copy. A decision guide with the Microsoft Fabric interop paths.
A Power BI semantic model in Microsoft Fabric can be tuned for self-service exploration, certified analytics, or AI agents, but not all three at once. Six dimensions pull the model in different directions, and the one-source-three-models pattern resolves the conflict.