Copilot across Fabric workloads

What it does

Beyond Power BI, Copilot shows up inside each Fabric data workload as a code-and-query assistant tuned to that job: building dataflows, writing notebook code, generating SQL and KQL, and explaining what's there. Each workload has its own Copilot; they are not one shared chatbot.

Key facts

Data Factory: natural language to build Dataflow Gen2 transformations, plus code generation and explanations of existing flows.
Data Engineering / Data Science: Copilot in notebooks with context-aware code completion, task automation and code templates. It's aware of the workspace, attached Lakehouse schemas, tables, files and notebook state without you starting a session. This one is in preview.
Data Warehouse: an AI assistant for warehousing tasks. Natural language to SQL, code completion, quick actions and inline insights.
Real-Time Intelligence: turns plain-language questions into KQL queries, aimed at both KQL users and non-specialists.
All of these run on Fabric paid capacity and bill by tokens processed against Capacity Units, same model as Power BI Copilot.
Grounding is your workspace metadata and schemas, so quality tracks how well-structured and described your Fabric items are.
GA status varies by workload. Assume preview until you've checked the specific workload's docs; the notebooks Copilot in particular is still marked preview.

When to use / skip

Use these where the workload has real engineering or query work and the team wants a faster first draft of code, SQL or KQL. Copilot in notebooks and the warehouse genuinely shortens the "blank page" problem for people who half-know the syntax. Skip it as a teaching tool for people who can't read the output, since they can't tell a good suggestion from a plausible-but-wrong one. And skip assuming parity: what works in the warehouse may be thinner or preview-only in Data Science.

Configuration decisions

Enable Copilot at tenant level and confirm the specific workload's Copilot is switched on; they're not all governed by one flag.
Decide which capacity carries the consumption, especially if engineering and BI teams share a tenant.
Set data-residency and cross-geo processing choices before engineers start feeding schemas and samples into prompts.
Agree naming and description conventions on Lakehouse tables and warehouse objects so Copilot has something to ground on.

Gotchas

Generated SQL, KQL and PySpark can run and still be wrong. It needs a reviewer who knows the domain.
Context-awareness depends on attached items. A notebook with no Lakehouse attached gives Copilot far less to work with.
Preview features here change more often than the Power BI ones. Don't hard-code a workflow around behaviour that could shift.
Token consumption from chatty engineering use adds up quietly against capacity. Watch the metrics app.

Consultant notes

Frame these as productivity assists for people who already know the tool, not as a way to skip hiring the skill.
The KQL-from-natural-language feature in Real-Time Intelligence is the standout for non-specialists. Worth a targeted demo.
Check each workload's GA status live before scoping. This is the fastest-moving part of the Fabric Copilot story.

Verify per-workload preview/GA status against the workload's own Learn page before quoting capability.