DEV Community: Shai Karmani

AI Can Build Power BI Reports Now. Here’s the Playbook I’d Use First.

Shai Karmani — Mon, 08 Jun 2026 23:33:57 +0000

Originally published at Data Ninja AI Lab.

Microsoft just opened a very interesting door for Power BI teams.

AI-powered Power BI reporting with agent skills is now in preview, and this is one of the most practical AI announcements in the Power BI space right now.

The reason is simple: this is not only chat over a report. This is AI helping with the actual report-building workflow.

Design pages. Generate PBIR files. Work inside a PBIP project. Reload Power BI Desktop. Capture screenshots. Improve the report based on what was actually rendered. Publish to Fabric when the report is ready.

That is a very different thing from asking Copilot to summarize a visual.

This is closer to giving an AI agent a real Power BI workbench.

What Microsoft released

Microsoft announced AI-powered Power BI reporting: From design to deployment with agent skills as part of the Power BI authoring plugin in Skills for Fabric.

The core idea: install a first-party Power BI authoring plugin, then use compatible AI tools, currently optimized for GitHub Copilot CLI, to build and modify Power BI reports through natural language.

The plugin can help an agent:

create report pages from a prompt
write schema-correct PBIR files
work with PBIP projects
reload an open Power BI Desktop report
capture screenshots from the rendered report
improve the report based on the screenshot output
coordinate with semantic model authoring and Modeling MCP
publish or manage reports in Fabric through companion skills

That last part is the important shift.

A lot of AI reporting demos stop at “generate a report.” This one is being designed around the artifacts Power BI developers already care about: PBIR, PBIP, semantic models, Desktop rendering, and Fabric publishing.

The repository behind this is public: microsoft/skills-for-fabric.

At the time I checked it, the repo was created on February 17, 2026, had 425 stars, 94 forks, and was still active, with a latest main-branch commit on June 7, 2026. The Power BI Authoring plugin manifest in the repo is at version 0.3.3.

This matters because it shows the direction clearly: Microsoft is not treating these as a throwaway demo prompt pack. This is a first-party skills catalog that can be installed, versioned, inspected, improved, and contributed to.

The Power BI Authoring plugin

The Power BI Authoring plugin lives under:

plugins/powerbi-authoring

The plugin currently includes these skills:

check-updates
semantic-model-authoring
powerbi-report-planning
powerbi-report-design
powerbi-report-authoring
powerbi-report-management

That split is smart.

Report building is not one task. It is a chain of decisions and artifacts.

You plan the report. You design the experience. You create or connect the semantic model. You author the PBIR files. You reload and inspect the report. You manage the Fabric item.

The plugin structure reflects that workflow instead of pretending one mega-prompt can do everything well.

The plugin also declares a local MCP server for Power BI Modeling:

"powerbi-modeling-mcp": {
  "type": "local",
  "command": "npx",
  "args": [
    "-y",
    "@microsoft/powerbi-modeling-mcp@latest",
    "--start"
  ]
}

That is where the ecosystem starts to become powerful.

Skills provide the operating instructions. MCP gives the agent live tool access. PBIP and PBIR give the work a file-based shape. Git gives the work history. Power BI Desktop gives the rendered output. Fabric gives the deployment target.

Put together, this becomes a real authoring loop.

How to install it

The install flow from Microsoft is short.

First, register the Skills for Fabric marketplace in GitHub Copilot CLI:

/plugin marketplace add microsoft/skills-for-fabric

Then install the Power BI Authoring plugin:

/plugin install powerbi-authoring@fabric-collection

If you want the broader Fabric bundle, Microsoft also documents:

/plugin install fabric-skills@fabric-collection

For a focused Power BI report pilot, I would start with powerbi-authoring@fabric-collection first. Keep the test narrow, prove the loop, then expand.

What this can actually do

Microsoft showed three practical examples in the announcement.

1. Create a report from scratch

You can ask the agent to create report pages with KPIs, slicers, tables, branding, and page structure.

For example, Microsoft’s demo prompt asks for an Opportunities page with revenue KPIs, slicers, and a table, then a Collabs page with offer status KPIs and filters.

The agent uses the powerbi-report-authoring skill to create Power BI report definitions in PBIR format.

This is a strong use case for the first draft of a report.

Not the final report. The first structured draft.

That alone can save a lot of time. Page scaffolding, KPI placement, slicer setup, table layout, and basic branding are not usually the highest-value part of BI work. They are necessary, but repetitive.

If an agent can get the first 60 percent into a usable PBIR structure, the developer can spend more time on business logic, model quality, visual clarity, and stakeholder feedback.

2. Modify an existing report from a prompt or reference image

The announcement also shows the agent updating an existing report based on a reference image and logo.

That means the workflow is not limited to greenfield reports.

You can point the agent at an existing PBIP project, describe the visual change, provide a reference image, and let it apply the style to the report pages.

This is where I see a lot of practical value.

Every BI team has reports that are useful but visually inconsistent. Different fonts. Random colors. Misaligned objects. Slicers in five different places. KPI cards that grew organically over time.

A good AI report assistant can help normalize those reports faster.

3. Modernize a messy report

Microsoft’s third example is the one that will probably resonate with the most Power BI teams: modernize a report with better design.

The prompt asks the agent to create a cleaner landing page, improve navigation, apply a consistent theme, reduce clutter, and make insights easier to scan.

Behind the scenes, Microsoft says the agent uses the powerbi-report-design skill to create a structured design brief, then passes that to the authoring skill for implementation.

This is exactly the kind of work where agent skills make sense.

The work has patterns. The output is visible. The files are structured. The result can be reloaded and checked. The agent can iterate.

That is a much better fit than asking an AI model to “make a dashboard better” with no real access to the report definition or rendered page.

The part that makes this different: screenshots in the loop

The feature I like most is the Desktop bridge.

Microsoft describes a loop where the agent can reload the report in an already-open Power BI Desktop instance, capture screenshots of the latest report pages, inspect the rendered output, and make another pass.

That changes the quality of the workflow.

Without screenshots, an agent is editing JSON and hoping the report looks right.

With screenshots, the agent can see the actual page.

That matters for:

overlapping visuals
bad alignment
poor spacing
unreadable labels
broken image placement
inconsistent card sizes
visual clutter
theme mismatch
navigation layout

This is the same reason designers do not approve a report by reading JSON. They look at the rendered page.

Giving the agent access to that rendered page is a big practical step.

Top use cases that can save real time

Here are the use cases I would prioritize first.

1. First draft report generation

Give the agent a clear brief:

audience
pages
KPIs
slicers
tables
navigation
required branding
source semantic model
examples of questions the report must answer

Then let it generate the first PBIR structure.

This is useful when the report shape is known but the build work is repetitive.

Example prompt:

Create a Power BI report for an executive sales pipeline review.

Use the Sales semantic model.

Page 1: Executive Overview
- KPI cards: Revenue Won, Revenue in Pipeline, Win Rate, Open Opportunities
- Trend: Revenue Won by Month
- Bar chart: Pipeline by Region
- Slicers: Region, Sales Owner, Close Month

Page 2: Opportunity Detail
- Table: Opportunity, Account, Owner, Stage, Risk, Expected Close Date, Revenue
- Add slicers for Stage and Risk
- Use a clean executive layout with strong navigation between pages

The point is not to make the prompt poetic. The point is to make it operational.

2. Report modernization backlog

Most organizations have a long tail of reports that people still use but nobody wants to redesign manually.

This is a perfect pilot category.

Pick five reports that are useful but ugly. Save them as PBIP. Ask the agent to improve one report at a time.

Good prompts here are direct:

Modernize this report for a monthly operations review.

Keep the same business meaning, but improve page structure, spacing, alignment, navigation, and visual hierarchy.

Create a cleaner landing page with the most important KPIs at the top.
Use a consistent theme across all pages.
Reduce clutter and make the page easier to scan in under 30 seconds.

This is where the powerbi-report-design skill should shine.

3. Brand and theme standardization

If a company has many reports across teams, style drift becomes real.

The agent can help apply a reference design, logo, color palette, or layout style more consistently.

This is not only about making reports pretty. Consistent design reduces cognitive load. Users know where to look. Filters behave more predictably. Navigation feels familiar.

4. Semantic model plus report creation

The Power BI report authoring skill can work with the Modeling MCP server and the semantic model authoring skill.

That means the bigger workflow can become:

inspect or create the semantic model
define measures and relationships
create report pages over that model
reload in Desktop
capture screenshots
refine the report
publish when ready

This is where the long-term value is.

A report without a good semantic model is just a nice-looking surface over weak logic. Pairing report authoring with semantic model authoring is the right direction.

5. Screenshot-driven report QA

The screenshot loop can save a lot of back-and-forth.

A normal report iteration might look like this:

change PBIR files
open or reload Power BI Desktop
check the page visually
fix spacing or formatting
repeat

If the agent can reload, screenshot, inspect, and adjust, it can take over a chunk of that mechanical loop.

That does not remove the BI developer. It gives the developer a faster loop.

6. Fabric publishing preparation

The powerbi-report-management skill is aimed at managing Power BI report workspace items in Microsoft Fabric through the Fabric REST API.

That includes creating, updating, downloading, and managing report definitions.

For teams already using PBIP, Git, deployment pipelines, and Fabric workspaces, this could become part of a more automated report release workflow.

My first pilot: a practical playbook

If I were testing this inside a real Power BI team, I would not start with the biggest executive dashboard in the company.

I would start with one report that is valuable, visible, and safe to iterate on.

Step 1: choose the right report

Pick a report with these traits:

already has a working semantic model
has 2 to 4 pages
needs layout or usability improvement
has clear business questions
does not require complex custom visuals for the first test
can be saved as PBIP

Good pilot examples:

sales pipeline report
inventory risk report
operations review report
finance month-end variance report
support tickets and SLA report
project portfolio status report

Avoid the monster report with 19 pages, 47 bookmarks, custom visuals, hidden pages, and years of business politics. That can come later.

Step 2: save the report as PBIP

The agent skills work with file-based Power BI report definitions. PBIP and PBIR are the important pieces here.

That means the report should live in a project folder where the report definition can be edited, inspected, and committed.

A simple structure might look like this:

sales-pipeline-report/
  Sales Pipeline.pbip
  Sales Pipeline.Report/
  Sales Pipeline.SemanticModel/
  briefs/
    report-brief.md

Create a Git branch for the experiment:

git checkout -b ai-report-skills-sales-pipeline

Now every change the agent makes has a place to live.

Step 3: write a real report brief

The quality of the output will depend heavily on the quality of the brief.

I would create a short report-brief.md file before asking the agent to touch anything.

Example:

# Sales Pipeline Report Brief

Audience: VP Sales, Sales Directors, Revenue Operations

Business goal:
Show pipeline health, revenue at risk, and opportunities that need attention this month.

Pages:
1. Executive Overview
2. Pipeline Detail
3. Risk Review

Required KPIs:
- Revenue Won
- Revenue in Pipeline
- Win Rate
- Open Opportunities
- At-Risk Revenue

Required slicers:
- Region
- Sales Owner
- Close Month
- Stage

Design direction:
Clean executive report. Strong KPI row. Simple navigation. Low clutter.
Use brand colors from theme.json.

Success criteria:
A VP should understand the pipeline status in 30 seconds.
A Sales Director should find at-risk opportunities without opening another report.

That kind of brief gives the agent something useful to work with.

Step 4: ask the agent to plan first

I would not start with “build the report.”

I would start with planning:

Use the Power BI report planning skill.
Read briefs/report-brief.md.
Inspect the semantic model metadata.
Propose the report page plan, required visuals, navigation structure, and any missing fields or measures.
Do not edit files yet.

This uses the planning skill for what it is good at: turning a request into a report specification.

Step 5: use design before authoring

Then I would ask for a design brief:

Use the Power BI report design skill.
Create a design brief for this report.
Prioritize executive scanning, clean page hierarchy, consistent navigation, readable KPI cards, and low visual clutter.

This is important because “create a report” and “create a good report experience” are not the same request.

The design skill gives the authoring skill a better target.

Step 6: let the authoring skill create or modify PBIR

Once the plan and design are clear:

Use the Power BI report authoring skill.
Implement the approved report plan in PBIR.
Create the pages, visuals, slicers, navigation, and theme updates described in the design brief.
Validate the report definition after the first implementation pass.

This is where the agent writes or updates the report files.

Step 7: reload Desktop and capture screenshots

Now the loop becomes visual:

Reload the report in Power BI Desktop.
Capture screenshots of each page.
Inspect the screenshots for layout, spacing, readability, navigation, and visual hierarchy.
Make one improvement pass based on the rendered output.

This is the part I would test hardest.

If the screenshot loop works well, this becomes much more than a prompt-to-JSON tool.

Step 8: publish only after the artifact is clean

When the report is in good shape, the management skill can help create or update report items in Fabric.

That publishing step should come after the PBIR files, semantic model binding, screenshots, and report behavior are ready.

A clean local loop first. Fabric publish second.

What I would measure in the pilot

I would measure this like an engineering workflow, not like a novelty demo.

For one report, track:

time to first useful draft
number of manual layout fixes needed
number of agent screenshot iterations
PBIR validation issues
semantic model issues discovered
how much of the report structure was reusable
whether the final output was easier to maintain than a manual build

The best result is not “AI built everything.”

The best result is this:

The team got to a useful, file-based, maintainable Power BI report faster, with more of the repetitive work handled by the agent.

That is a practical win.

Where I think this goes next

This is still preview, but the direction is obvious.

Power BI development is moving toward a more code-aware, agent-aware workflow:

PBIP makes reports file-based.
PBIR makes report definitions more editable.
TMDL makes semantic models more inspectable.
MCP gives agents access to real tools.
Skills give agents the right operating instructions.
Desktop screenshots give agents feedback from rendered output.
Fabric APIs give the workflow a deployment path.

That combination is much more interesting than isolated AI features.

It means a future Power BI workflow could look like this:

A business owner writes a report brief.
An agent proposes the page plan.
The agent creates the semantic model and report draft.
Desktop screenshots drive the first visual refinement pass.
The BI developer improves the model, measures, layout, and usability.
The report is published to Fabric.
The report definition remains in source control for future changes.

That is a strong direction for teams that already want better engineering discipline around Power BI.

My take

I am very excited about this direction.

Power BI teams spend too much time on repetitive report setup, redesign cleanup, visual alignment, theme drift, and the boring mechanics around first drafts.

Agent skills are a good fit for that work because the work is structured, file-based, visible, and iterative.

The big idea is not “AI replaces Power BI developers.”

The big idea is better:

AI agents can now participate in the same report-building loop that Power BI developers already use: model, files, Desktop, screenshots, Git, and Fabric.

That is where this becomes useful.

Start with one PBIP report. Install the Power BI Authoring plugin. Give the agent a real report brief. Let it plan, design, author, reload, screenshot, and improve.

If the loop works, you have something much more valuable than a demo.

You have the beginning of an AI-assisted Power BI development workflow.

Sources

Shai Karmani
Let’s connect on LinkedIn

Fabric IQ Is GA. This Is the Context Layer I’ve Been Waiting For.

Shai Karmani — Thu, 04 Jun 2026 23:03:52 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-06-04-fabric-iq-ga-context-layer.html.

Fabric IQ becoming generally available is one of the Fabric milestones I was waiting for.

Not because the industry needed another AI announcement.

Because production AI agents have been missing something very basic: a shared, governed understanding of the business.

Most AI agent demos can answer a question if the prompt is clean, the data source is obvious, and the scope is small. That is useful for a demo. It is not enough for an enterprise workflow where the same customer, shipment, asset, incident, product, or KPI can mean different things across systems.

Microsoft is positioning Fabric IQ as the shared context layer for people, applications, and AI agents. The GA announcement includes Fabric IQ as the production context layer, with Graph and Operations Agents generally available and Ontology continuing in preview.

That nuance matters. The whole direction is production-facing, but not every individual piece has the same maturity label yet.

My take: this is the moment where Fabric starts looking less like a reporting platform with AI features and more like an operating layer for business context.

Why this is strategically important

AI agents do not fail only because the model is weak.

They fail because the business context is scattered.

One team defines active customer one way. Finance defines revenue another way. Operations tracks incidents in a different system. A report hides business logic in measures. A warehouse stores clean tables but not the real meaning behind the process. Then an agent is expected to reason across all of it.

That is where things get risky.

A production agent needs to know more than where the data lives. It needs to know what the business entities are, how they relate, which metrics are trusted, what rules apply, and which source owns the truth.

Fabric IQ is Microsoft’s answer to that problem.

The strategic shift is simple:

Stop asking every agent, report, app, and workflow to rediscover business meaning from scratch.

Define the context once. Govern it. Reuse it.

What Fabric IQ actually does

Fabric IQ sits on top of the Fabric data foundation and gives business meaning to data that would otherwise live as tables, streams, events, reports, and models.

Microsoft describes three connected layers.

1. Unified data in OneLake

OneLake gives Fabric IQ the common data foundation. Analytical data, operational data, shortcuts, lakehouses, warehouses, semantic models, and other Fabric items can participate in the same platform story.

2. Business intelligence through semantic models

Power BI semantic models already hold a lot of trusted business logic: measures, hierarchies, dimensions, relationships, and KPI definitions.

Fabric IQ does not throw that away. It uses semantic models as part of the context layer. You can generate or align ontology from semantic models so the business language used in reports can also ground agents and applications.

Many companies already spent years building trusted semantic models. The smart move is to reuse that logic, not rebuild it in prompts.

3. Operational intelligence through ontology and graph

This is the part that gets interesting.

Ontology defines business entities, properties, relationships, rules, and actions. Think Customer, Shipment, Store, Sensor, Order, Contract, Incident, and Asset.

Graph makes connected data explicit and queryable. Instead of asking an agent to guess how things relate through joins and table names, relationships can become first-class business context.

The part I like most: agents can stop guessing relationships

Graph in Fabric is now generally available. Relationship-first modeling is no longer just a nice preview idea sitting outside the core platform conversation.

For AI agents, relationships are not decoration.

They are the difference between:

“Show sales by customer”
“Which customers are affected by a supplier delay through the products they bought and the shipments currently in transit?”

The first question is normal BI.

The second question needs relationships, paths, dependencies, and business meaning. It needs to understand how entities connect across domains.

Traditional joins can answer some of this, but they usually hide the relationship logic in technical implementation. Graph and ontology make those relationships explicit enough for humans to review and for agents to use.

A mini tutorial: how I would start small

I would not start a Fabric IQ pilot by modeling the whole company.

That is how architecture diagrams become shelfware.

I would start with one narrow process where the relationships matter.

Example: retail inventory risk.

The business question could be:

Which stores are at risk because a high-revenue product has low inventory, recent demand is increasing, and the supplier is already delayed?

That is a good Fabric IQ candidate because it crosses entities and systems: Store, Product, Inventory, SaleEvent, Supplier, Shipment, and DelayReason.

Here is the smallest practical path I would use.

Step 1: start from a trusted semantic model or OneLake data

If a Power BI semantic model already has clean relationships and trusted measures, use it as the starting point and generate an ontology from it. If not, create the ontology directly from OneLake sources.

Do not bring every table. Pick the few entities needed for the first business question.

Step 2: rename technical objects into business language

This is not cosmetic.

An agent should not reason over dimproducts, factsales, and store_id as the primary business language.

Rename entity types into business terms such as Product, Store, SaleEvent, Supplier, and Shipment. Choose stable keys. Bind properties from source data. Define relationships like Store sells Product, Supplier ships Product, Shipment supplies Store.

Step 3: bind data and verify relationships

Data binding connects the ontology definitions to real OneLake data.

Before connecting an agent, I would check:

Are entity keys correct?
Are the important properties bound?
Are relationship directions understandable?
Are source systems documented?
Is there an owner for each business concept?

Step 4: connect a Fabric Data Agent

Create a Fabric Data Agent and add the ontology as a source.

Then test questions that force relationship reasoning, not just lookup behavior:

Which stores have low inventory for products with rising revenue in the last 14 days?

Which delayed shipments affect high-revenue products?

Which suppliers are connected to the most at-risk stores this week?

The goal is to prove that the agent is using governed business context instead of guessing from table names.

The governance question teams should ask first

Fabric IQ will be powerful for teams that treat it like infrastructure.

It will become confusing for teams that treat it like another AI feature.

Before I would let an ontology-backed agent near production, I would want clear answers to these questions:

Which business concepts are in scope?
Who owns each entity definition?
Which semantic model or source system is trusted?
Which relationships are reviewed by the domain owner?
Which agents can use this context?
What actions are allowed?
How do we test whether the agent used the right definition?
What changes when the ontology changes?

This is the same lesson as semantic models, but with higher stakes.

A bad measure can create a bad report. A bad ontology can create a bad agent decision.

My takeaway

Fabric IQ going GA is not just another Fabric announcement.

It is a signal that Microsoft is building the missing layer between data platforms and production AI agents: business context that can be modeled, governed, queried, reused, and connected to action.

That is why I was waiting for this milestone.

Semantic models gave BI teams a trusted language for reporting.

Fabric IQ pushes that idea further: a trusted context layer for agents, planning, graph reasoning, and applications.

The opportunity is huge, but the implementation discipline matters.

Start with one business process, one ontology, one trusted semantic model or OneLake source, one narrow agent scenario, and one owner who can say whether the answer makes sense.

That is how Fabric IQ becomes useful infrastructure instead of another impressive demo.

Sources

Shai Karmani

Let’s connect on LinkedIn

Fabric Business Events Just Became an Architecture Pattern

Shai Karmani — Mon, 01 Jun 2026 23:28:15 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-06-01-fabric-business-events-architecture-guide.html.

A Business Event is a meaningful business signal that says something important happened and that another process, person, dashboard, model, or workflow may need to react.

That sounds simple, but the distinction matters.

A raw technical event might say a row changed, a sensor value moved, or a query returned a result. A Business Event should describe a business moment: a shipment was delayed, a high-value order is ready, a payment failed, or a demand forecast moved outside tolerance.

That is why the latest Fabric Business Events update is more than another alerting feature.

It moves Business Events closer to a real architecture pattern for turning operational signals into governed, reusable events that analytics, automation, AI, and business workflows can all consume.

The update matters because it expands the pattern in four directions:

Eventstream can publish Business Events from operational streams.
Activator can publish Business Events when a condition is detected.
Eventhouse and Real-Time Dashboards can analyze Business Events as persistent, queryable history.
Business Events now have clearer capacity consumption behavior.

The short version: this is no longer just alerting. It is event modeling for business operations.

What is actually new

The June 2026 update makes Business Events more practical across publishers, consumers, history, and cost ownership.

1. Eventstream can publish Business Events

Eventstream can act as the signal-processing layer.

Instead of sending raw telemetry, CDC rows, or low-level operational messages to every downstream process, teams can filter, enrich, correlate, and publish a named business event.

That matters because downstream consumers should not need to know every detail of the source system.

A raw event might say:

order_status_changed

A business event should say something closer to:

HighValueOrderReadyForFulfillment

The second one carries intent. It tells the organization what happened and why someone should care.

2. Activator can publish Business Events

Activator is no longer only a consumer that reacts to events.

With the preview capability, Activator can detect a condition and publish a Business Event into Real-Time Hub.

That condition can come from places like:

a Power BI report
a Real-Time Dashboard
a KQL query
a Fabric Warehouse SQL query

This is important because many business signals are not born as clean source-system events. They are detected from data.

A downtime indicator, fraud pattern, SLA breach, or inventory threshold may only become meaningful after a query or rule evaluates current state. Activator can turn that detection into a governed event other teams can discover and consume.

3. Eventhouse gives Business Events memory

Business Events can now be analyzed in Eventhouse and surfaced through Real-Time Dashboards.

That changes the operating model.

If events only trigger actions, teams can react in the moment but struggle to learn from the pattern. If events are also stored in Eventhouse, teams can ask better questions later:

How often did this event happen?
Which customers, products, regions, or systems were affected?
Did the event rate change after a deployment?
Which events usually happen together?
Should this event feed a model, a dashboard, or an automation?

Microsoft says each Business Event maps to a dedicated KQL table in Eventhouse, with no extra pipelines or manual configuration required. That is the part that makes the feature more interesting for analytics teams.

4. Capacity ownership is now part of the design

Business Events now follow a consumption model aligned with Azure and Fabric events.

The update describes two operation types:

Event operations per event, covering publish, filtering, and delivery.
Event listener per hour, charged while a consumer is actively listening.

The split matters.

Publish operations are charged to the Event Schema Set item. Filtering and delivery are charged to the consumer capacity, such as Activator or Eventhouse. Listener time is also charged to the consumer capacity.

That means event design is also a cost design. If every noisy technical signal becomes a Business Event, the architecture gets expensive and hard to reason about.

The architecture pattern I would use

I would not start with the alert.

I would start with the event contract.

A Business Event should describe a meaningful change in business state, not every technical thing that happened along the way.

Here is the practical pattern.

Step 1: decide if this is really a Business Event

Not every event deserves the label.

A Business Event should pass three tests.

Test 1: Does the business care when it happens?

Good examples:

PaymentFailed
ShipmentDelayed
HighValueOrderDetected
RefundIssued
DemandForecastDeviationDetected

Weak examples:

DiskReadError
MemoryUsagePercent
CurrentTemperature
UnhandledExceptionLogged

Those weak examples may still matter. They may belong in telemetry, monitoring, or observability. But they are not automatically Business Events.

Test 2: Should more than one consumer care?

If the signal only feeds one internal process, a direct integration may be enough.

If the same event could feed operations, analytics, automation, support, finance, or AI workflows, a Business Event starts to make sense.

This is where the decoupling matters. The publisher emits one governed event. Multiple consumers can subscribe without changing the original publisher.

Test 3: Can you name it without describing the implementation?

A good Business Event name should sound like a business fact, not a pipeline step.

Better:

CustomerCreditLimitExceeded

Weaker:

SqlQueryReturnedRows

The first one is a business state. The second one is an implementation detail.

Step 2: define the event contract before the flow

This is where teams often skip a step.

They build the stream, wire the alert, and only then realize every consumer needs a slightly different payload.

That creates a familiar mess: field remapping, version drift, unclear ownership, and consumers guessing what the event means.

The Business Events documentation points to Schema Registry as the shared source for event schemas. That should be treated as the contract layer.

For each Business Event, define:

event name
business meaning
owner
source system or publisher
schema version
required fields
optional fields
event time and processing time
correlation identifiers
consumer expectations
retention and analysis needs

A useful minimum payload might look like this:

{
  "eventName": "ShipmentDelayed",
  "eventVersion": "1.0",
  "eventTime": "2026-06-01T18:04:09Z",
  "shipmentId": "SHP-104920",
  "customerId": "CUST-8841",
  "delayReason": "CarrierCapacity",
  "estimatedDelayMinutes": 180,
  "sourceSystem": "FulfillmentPlatform",
  "correlationId": "c9a4f4b2-8f3a-4f0c-9de1-9ab2d7c81240"
}

That payload is small, but it gives consumers enough context to act, analyze, and trace.

Step 3: choose the right publisher

The new update makes this decision more interesting.

Use Eventstream when the signal starts as operational stream data.

Examples:

CDC rows from an operational database
IoT or device events
Kafka or Event Hubs messages
incoming application events
high-volume signals that need filtering or enrichment

Use Activator when the signal is detected from a condition.

Examples:

a Power BI report threshold
a KQL query result
a warehouse query condition
a real-time dashboard rule
a business condition that only exists after evaluation

Use Notebook or User Data Functions when the event requires custom logic.

Examples:

model scoring
enrichment
validation
business rule evaluation
more complex event generation logic

The key is to avoid treating all publishers the same. A publisher is not just a connection point. It defines where the event becomes meaningful.

Step 4: separate action from history

This is the part I like most in the update.

Business Events can trigger action through consumers like Activator, Power Automate, notebooks, Spark jobs, Dataflows Gen2, or custom logic. But they can also land in Eventhouse for historical analysis.

That separation is healthy.

Action answers: what should happen now?

History answers: what keeps happening, where, and why?

If you only build action, you get automation without learning.

If you only build history, you get dashboards without response.

The better design does both.

Step 5: put capacity in the design review

Capacity should not be a surprise after go-live.

For every Business Event, ask:

How many events per hour do we expect?
Which consumers will listen continuously?
Which capacity pays for publishing?
Which capacity pays for filtering, delivery, and listening?
Do we need every event, or only state changes that matter?
Is this event too noisy for a business-level contract?

This is especially important when teams convert raw streams into Business Events. The point is not to rename telemetry. The point is to publish meaningful moments.

A practical checklist before you ship

Before I would put a Fabric Business Event into production, I would check this:

The event has a clear business name.
The event has an owner.
The schema is defined before consumers are built.
The schema includes event time, source, and correlation ID.
Eventstream, Activator, Notebook, or UDF was chosen intentionally.
At least one consumer has a real business action.
Eventhouse history is useful, not just stored by default.
Real-Time Dashboard visuals answer operational questions.
Capacity ownership is documented.
No raw telemetry stream is being disguised as a business event.

That last point is the trap.

Business Events are valuable when they create shared business language. They become expensive noise when every technical signal gets promoted without a contract.

Where this fits in Fabric architecture

Fabric is slowly closing the gap between analytics and operational response.

Power BI reports can surface conditions.

Activator can detect and act.

Eventstream can shape operational signals.

Real-Time Hub can organize event discovery.

Eventhouse can preserve and query event history.

Real-Time Dashboards can show live operational state.

The architecture question is no longer only “can Fabric send an alert?”

The better question is: which business events deserve to become reusable contracts across the data platform?

That is where this feature becomes useful.

Not because alerts got prettier.

Because Fabric is giving teams a way to model business moments as governed, discoverable, queryable events.

Used carefully, that can reduce the distance between data, action, and learning.

Used casually, it becomes another stream of noise.

The difference is the contract.

Sources

Shai Karmani

Let’s connect on LinkedIn

Build Power BI Columns That Adapt to Each User

Shai Karmani — Thu, 28 May 2026 22:35:27 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-28-user-aware-calculated-columns-power-bi.html.

Power BI calculated columns are getting a new design option that is easy to underestimate.

The setting is called Expression Context.

The option is User Context.

The result is a calculated column that can be evaluated at query time, under the security context of the user who is running the report.

That opens a useful set of patterns for semantic model authors:

values that change by user culture
row-level calculations that do not need to be stored as physical columns
sensitive values that can stay visible to admins and blank for restricted users
Direct Lake and Import models that need cleaner control over calculated column materialization

The feature is still preview territory, so I would not treat it as a casual modeling shortcut. But it is already worth understanding because it changes how we think about calculated columns in Power BI.

Source: SQLBI: Introducing user-aware calculated columns in Power BI

What changes with User Context

A standard calculated column is evaluated when the table is processed.

In Import mode, the result is stored in the semantic model. Once it is processed, the value is the same for every user who queries the model.

A user-aware calculated column changes that behavior.

When Expression Context is set to User Context, the expression is evaluated at query time. It runs under the active user security context, and it can use user-aware DAX functions such as:

USERCULTURE()
USERPRINCIPALNAME()
USEROBJECTID()
USERNAME()
CUSTOMDATA()

That means the column can still behave like a column in the model, but the value can depend on who is asking the question.

I would think about it as a semantic model design tool, not only as a localization feature.

Pattern 1: build reports that speak the user language

The cleanest first use case is localization.

A Date table can expose month names or day names that change based on the user's culture. For example:

Month =
FORMAT (
    DATE ( 2020, 'Date'[Month Number], 1 ),
    "mmmm",
    USERCULTURE()
)

If the user culture is English, the report can show January.

If the user culture is French, the same column can show janvier.

The model does not need separate month-name columns for every language. The expression can return the correct value at query time.

This is where the feature becomes practical. Many organizations serve the same report to users in different regions. The metadata translation story already exists for names of tables, columns, and measures. User-aware calculated columns add another piece: values inside the model can adapt too.

The slicer detail that matters

Localization creates a subtle modeling problem.

If a slicer stores the selected value as translated text, that selection may not survive when the same report is viewed in another culture.

For example, a slicer selection of Sunday does not match dimanche.

The better design is to let the user see the translated label but keep the selection anchored to a stable key, such as Day of Week Number.

That is where Sort by Column and Group By Columns matter.

SQLBI shows the TMDL version clearly:

The principle is simple:

display the user-aware text column
sort it by a numeric column
group it by the stable numeric identifier
avoid storing report selections as translated strings

That is the difference between a nice demo and a report that behaves correctly across languages.

Pattern 2: create virtual columns for row-level calculations

The second pattern is less obvious and probably more important for model design.

A user-aware calculated column is not materialized in Import mode. It exists in the model, but its values are not stored as a physical column in memory.

That can be useful for simple row-level expressions.

A common example is line amount:

Line Amount = Sales[Quantity] * Sales[Net Price]

As a standard calculated column, that expression creates another stored column. If the table is large and the value has high cardinality, the column can add memory and processing cost.

As a User Context column, the same expression can behave more like a virtual column. It remains available to visuals, filters, slicers, and measures, but it does not need to be stored in the model.

This is useful when the expression is simple enough for the engine to compute efficiently during query execution.

Good candidates:

arithmetic on columns from the same table
simple classifications with stable input columns
labels or helper columns that are useful to report authors
logic that benefits from being a field, not only a measure

Poor candidates:

complex row-by-row DAX
expressions that call expensive table functions
logic that triggers formula engine callbacks at scale
anything that has not been tested with realistic data volume

The practical takeaway: User Context can reduce stored model bloat, but it moves work to query time. That tradeoff needs measurement.

Pattern 3: keep one report layout while hiding sensitive values

The third pattern is security-aware modeling.

Object-level security can hide a column completely. That is sometimes the right answer, but it can break report visuals that reference the hidden column.

User-aware calculated columns give another option for some scenarios: keep the column available in the report, but return blank values for restricted users.

SQLBI demonstrates this with income bracket data.

The supporting table stores the sensitive value. RLS blocks that table for restricted users. A user-aware calculated column uses LOOKUPVALUE() to bring the value into the visible table.

The key design choice is that the sensitive lookup table stays disconnected from the main customer table.

That matters because the RLS filter should block the lookup result. It should not propagate through relationships and remove the customer rows or sales rows from the report.

For an admin user, the report can show the income bracket values:

For a restricted user, the same report still renders, but the sensitive values become blank:

This is not a replacement for every object-level security scenario. Restricted users can still see that the column exists. But for reports where the layout must keep working while sensitive values are redacted, it is a useful pattern to test.

How I would evaluate this in a real model

I would not start by asking, "Can this replace my calculated columns?"

I would start with these questions:

1. Does the value need to change by user?

If the expression depends on culture, identity, role, or security context, User Context may be the right design.

If every user should see the same value, be more careful. The only benefit may be avoiding materialization, and that creates a query-time cost tradeoff.

2. Is this a value users need as a field?

Measures are great for aggregations.

Columns are useful when report authors need a field for slicers, filters, grouping, or visual axes.

User-aware calculated columns can fill a gap where the logic needs to live as a field, but the model author does not want to store another physical column.

3. Can the expression run cheaply at query time?

Simple arithmetic is a better candidate than complex DAX.

A virtual column that saves memory but slows every report page is not a win.

4. Have you tested role behavior?

For security-aware patterns, test with View as role before trusting the design.

Check that restricted users see blanks where expected, and that the rest of the report still returns the correct rows.

5. Are selections stable across languages?

If the value is localized, do not let the visible label become the identity of the selection.

Use stable keys for grouping and sorting.

Where this fits with the May 2026 Power BI update

The May 2026 Power BI update includes several modeling and reporting changes around Copilot, visual calculations, custom totals, report summaries, and locale behavior.

One line in the Microsoft update is especially relevant here: default format string locale affects visual display, while USERCULTURE() and metadata translations still use the viewer's browser locale.

That distinction matters.

Power BI is giving model authors more control over where logic lives:

visual layer logic with visual calculations
semantic model logic with DAX, TMDL, and PBIP
AI readiness metadata with Prep data for AI
user-aware values with Expression Context and User Context

The direction is clear: the semantic model is becoming more programmable, more reviewable, and more sensitive to the context of the person consuming the report.

Source: Microsoft Learn: May 2026 Power BI Update

A practical checklist before using it

Before I would ship a user-aware calculated column, I would check this:

Is the feature supported in the target Power BI Desktop and service environment?
Is the table storage mode compatible with the intended behavior?
Does the expression use user-aware DAX functions intentionally?
Is the expression simple enough to evaluate at query time?
Are translated labels grouped by stable keys?
Are RLS and View as role tests clean?
Are report visuals still valid for restricted users?
Is the behavior documented in the model repository or TMDL?

If the answer is yes, User Context becomes a powerful tool.

Not because it makes calculated columns more clever.

Because it lets the semantic model respond to the user, while keeping the logic in one place.

That is a useful direction for serious Power BI models.

Sources

Written by Shai Karmani

Copy Job CDC with SQL estate is now GA in Microsoft Fabric

Shai Karmani — Tue, 26 May 2026 23:00:53 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-26-copy-job-cdc-sql-estate-ga.html.

Copy Job CDC with SQL estate is now generally available in Microsoft Fabric Data Factory.

That sounds like a data movement update.

It is more useful than that.

For many BI and data engineering teams, the hard part is not copying data once. The hard part is keeping analytical data aligned with operational systems after the business changes.

A customer address is updated.

An order status changes.

A subscription is canceled.

Inventory moves.

A record is deleted in the source system, but the reporting layer still needs to explain what happened.

Those are not edge cases. They are normal business behavior. If the analytical platform cannot handle them clearly, trust starts to leak out of the reporting layer.

That is why CDC matters.

What became generally available

Microsoft announced that Change Data Capture support for SQL estate in Copy Job is now generally available.

The generally available SQL estate sources include:

SQL Server
Azure SQL Database
Azure SQL Managed Instance
SAP Datasphere

The generally available destinations include:

SQL Server
Azure SQL Database
Azure SQL Managed Instance
Fabric SQL
Snowflake

Microsoft is also moving more CDC connectors through preview, including Fabric Lakehouse table, Google BigQuery, Snowflake, Oracle, SQL database in Fabric, and Fabric Data Warehouse scenarios.

The important part is not the connector list by itself. The important part is that CDC is becoming a normal Data Factory pattern inside Fabric, not a side script that each team has to invent again.

Source: Microsoft Fabric Updates Blog: Simplify your data movement with Copy job: CDC with SQL estate

What you can actually do with it

1. Stop rebuilding full loads when only changes matter

Full refresh is simple until it is not.

It works when the tables are small, the source systems can handle the load, and nobody cares about latency. That changes quickly with operational SQL systems.

CDC lets the pipeline focus on what changed. That can reduce load on the source system, reduce movement volume, and make analytical updates closer to operational reality.

This is especially useful for tables such as orders, customers, products, subscriptions, transactions, inventory, service tickets, and account status history.

2. Bring SQL estate replication closer to Fabric Data Factory

A lot of organizations already have replication logic around their SQL estate. Some of it is mature. Some of it is a set of custom jobs nobody wants to touch.

Copy Job CDC gives Fabric teams a cleaner option for the right workloads.

Instead of maintaining another custom replication layer, a team can move more of the pattern into Fabric Data Factory, where the data movement is visible as part of the platform.

That does not mean every existing pipeline should be replaced tomorrow. It does mean new Fabric architecture decisions should consider CDC as a first-class option.

3. Preserve history with SCD Type 2

For reporting, the latest value is often not enough.

If a customer changed region last month, some reports need the current region. Other reports need the region that was true when the order happened.

That is where slowly changing dimension Type 2 patterns matter.

Microsoft also highlighted extended SCD Type 2 support for Fabric Warehouse and Synapse SQL Pool. With native SCD Type 2 in Copy Job, teams can preserve historical versions of records with effective dating and soft delete handling.

That is not just a data warehouse modeling detail. It is the difference between a report that shows the current answer and a report that can explain the historical answer.

4. Treat deletes as audit events, not disappearing rows

Deletes are dangerous in analytics.

If a source record disappears and the destination simply removes it, the reporting layer may lose the ability to explain prior results.

Soft delete handling is useful because the destination can mark a record as inactive instead of physically deleting it. That keeps the history visible for audit, reconciliation, and operational reporting.

For finance, subscriptions, customer lifecycle, compliance, and operational analytics, that distinction matters.

The architecture conversation gets better

The real value is not that Fabric can copy data from A to B.

Teams have had ways to copy data for years.

The value is that Fabric is making change capture, history, deletes, latency, and ownership easier to discuss as platform concerns.

That changes the conversation from:

How do we move the data?

To:

How do we trust the data after it changes?

That is a better architecture question.

Where I would use this first

I would look for workloads with these signals:

Operational SQL source systems
Tables that change frequently
Reports that need fresher data than a nightly full load
Business processes where historical state matters
Deletes that need traceability
Custom replication jobs that are becoming hard to maintain
Fabric adoption where Data Factory is already part of the platform

Good candidates are customer dimension sync, order status tracking, subscription lifecycle reporting, inventory movement, financial transaction replication, and support or case management analytics.

Where I would still be careful

GA does not remove design responsibility.

Before moving a production workload, I would still define:

Source ownership
Expected latency
Initial load strategy
Change tracking assumptions
Delete behavior
SCD Type 2 rules
Failure handling
Reconciliation checks
Security and access model
Monitoring and support ownership

CDC makes the movement pattern easier. It does not automatically make the architecture clean.

My takeaway

Copy Job CDC with SQL estate becoming GA is a practical Fabric milestone.

It gives BI and data engineering teams a stronger native option for moving operational SQL changes into analytical systems, while preserving history and making deletes more traceable.

The best use of this feature is not to treat it as another ETL checkbox.

Use it to make change history, auditability, and trust explicit in the Fabric architecture.

That is where the feature starts to matter.

Shai Karmani

Let’s connect on LinkedIn

Fabric AI Functions Turn GenAI Into a Data Pipeline Step

Shai Karmani — Tue, 26 May 2026 00:33:12 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-24-fabric-ai-functions-data-workflows.html

Most enterprise GenAI demos start in the wrong place.

They start with a chat window.

The more useful place is usually earlier: inside the data workflow, before the dashboard, before the semantic model, before the analyst has to clean the same messy text for the tenth time.

That is why Fabric AI Functions are worth paying attention to.

They let data teams use GenAI directly inside pandas and Spark workflows in Microsoft Fabric. Not as a separate app. Not as a one-off script sitting outside the platform. As a transformation step inside the work data teams already do.

That changes the shape of the use cases.

Instead of asking “how do we add a chatbot?”, the better question becomes:

Where is language, document mess, or unstructured content slowing down our data pipeline?

What you can actually do with it

Fabric AI Functions expose common GenAI operations as DataFrame-friendly functions.

You can use them to:

classify support tickets, survey responses, incidents, or customer feedback
summarize notes, long text fields, operational logs, and service records
extract fields from documents or semi-structured text
translate records as part of a data preparation flow
fix grammar or normalize messy text before reporting
create embeddings for search, RAG, and semantic retrieval
compare similarity between text values
generate structured responses from instructions
enrich rows in pandas or Spark without moving the workflow outside Fabric

That sounds simple, but it is a useful shift.

For years, a lot of GenAI work around data platforms has looked like this:

Export data from the platform.
Send it to a separate script or service.
Call an AI model.
Stitch the result back into the data estate.
Hope the process is governed enough to survive production.

Fabric AI Functions make a cleaner pattern possible.

The AI step can live closer to the lakehouse, notebook, Spark job, data science workflow, Power BI preparation layer, and downstream semantic model.

That is a much better starting point for teams that want AI to improve real data work, not just demo well.

The big changes that make this interesting

There are a few parts that matter more than the feature list.

1. GenAI becomes part of the pipeline

The most important change is architectural.

AI enrichment can become a normal transformation step.

A notebook can read raw records, apply an AI function, store the output as another column or table, and send that enriched dataset into the next layer of the platform.

That means AI output can be reviewed, versioned, refreshed, tested, governed, and consumed like other data assets.

That is very different from treating GenAI as a sidecar experiment.

2. Multimodal input makes the use cases much better

Text classification is useful, but many business workflows are not clean text.

They are PDFs.

Screenshots.

Images.

CSV files.

JSON files.

Markdown notes.

Operational documents that never quite made it into a table.

Microsoft documents AI Functions support for image files such as JPG, PNG, GIF, and WebP, documents such as PDF, and common text formats such as MD, TXT, CSV, JSON, and XML.

That opens better Fabric workflows.

A team can bring files into the lakehouse, use AI to extract or summarize what matters, and store the result in structured tables for review and reporting.

That is the kind of AI use case that can save real operational time.

3. Embeddings can be created where the content already lives

ai.embed is one of the more important functions because it connects Fabric directly to search and RAG preparation.

A team can take product documentation, policy files, support resolutions, internal wiki pages, field notes, or knowledge base articles and create embeddings as part of the data workflow.

That creates a cleaner path from raw business content to retrieval-ready datasets.

The useful part is not just the embedding itself. It is that the data team can decide what content is approved, what should be excluded, how often embeddings refresh, and what downstream applications are allowed to use.

4. The model/provider configuration is becoming more serious

The documentation now covers configuration details around providers and models, including the default model behavior.

That matters because production teams eventually need answers to basic governance questions:

Which model is being used?
Who approved it?
Which data can be sent to it?
Which capacity pays for it?
Which workloads are allowed to use it?
What happens when the output is wrong?

This is where Fabric AI Functions become more than a notebook convenience. They become part of the data platform operating model.

5. The best output is not “AI magic”. It is a reviewable data asset.

The mistake is to take AI output and treat it as automatically trusted.

The better pattern is to produce reviewable enrichment.

Keep the original value.

Add the AI-generated label, summary, extracted field, or embedding.

Add review flags where needed.

Store the result in a table with ownership and downstream rules.

Then decide what is safe enough for reporting, automation, search, or user-facing apps.

That is how this becomes useful without becoming sloppy.

Three practical things I would build first

1. Support ticket enrichment

Most support datasets contain useful signal, but the text is messy.

A Fabric notebook can add AI-generated columns for:

topic classification
urgency
sentiment
short summary
product area
likely ownership team

The key is not to pretend the model is perfect. The key is to create a reviewable enrichment layer that helps analysts and operations teams move faster.

A good output table might include the original text, AI-generated labels, confidence or review flags where available, and a human-reviewed status column.

That gives Power BI a better dataset without hiding the uncertainty.

2. Document extraction into structured tables

A lot of business data is trapped in semi-structured documents.

Invoices, forms, reports, agreements, field notes, inspection PDFs, and vendor files often contain fields that teams later retype manually.

With AI Functions, the useful pattern is:

Store the files in the lakehouse.
List file paths as input.
Use extraction or generation instructions to pull out the fields.
Store the result as a structured table.
Review exceptions before the data becomes trusted.

That does not replace proper document processing for every scenario. It does make small and medium internal automation projects much easier to test inside Fabric.

3. Embeddings for search and RAG preparation

A team can take approved internal content and create embeddings as part of the Fabric workflow.

That content might include:

product documentation
policy files
support resolutions
internal wiki pages
knowledge base articles
implementation notes

The output can become a governed retrieval layer instead of a random pile of files passed into an AI app.

That matters because RAG quality starts before the chat interface. It starts with content selection, metadata, refresh rules, ownership, and preparation.

Where I would be careful

Positive does not mean careless.

AI Functions make enrichment easier, but the usual production questions still matter:

Which data is allowed to be sent to the model?
Is the Fabric tenant setting for Copilot and Azure OpenAI enabled intentionally?
Does the workload require cross-geo processing approval?
Which Fabric capacity will pay for the work?
Which model/provider is configured?
How will output quality be reviewed?
Which outputs are allowed to flow into reports or user-facing apps?
How will failures, blanks, and hallucinated values be handled?

Microsoft notes that Fabric AI Functions require a paid Fabric capacity, F2 or higher, or any P capacity. The documentation also states that AI Functions are supported in Fabric Runtime 1.3 and later, and that the default model is gpt-4.1-mini unless a different model is configured.

Those details matter. They turn this from a cool notebook feature into a platform decision.

My take

Fabric AI Functions are useful because they move GenAI into the unglamorous part of AI work.

The pipeline.

The notebook.

The enrichment step.

The document cleanup.

The semantic preparation layer.

That is where a lot of business value actually sits.

Not every AI feature needs to become a chat window. Some of the most valuable AI work will happen quietly inside pipelines, quality checks, enrichment jobs, and retrieval preparation steps.

The practical opportunity is simple:

Take the data you already manage in Fabric. Add AI where language, documents, and meaning slow the team down. Store the result as a governed data asset. Review it before it reaches users.

That is a much better direction than treating AI as a separate island next to the data platform.

When did this become available?

The official Microsoft Learn page for Fabric AI Functions currently has a documentation date of November 13, 2025 and an updated timestamp of May 7, 2026.

The GitHub history for the Fabric documentation shows the AI Functions overview page existed by February 28, 2025. A later documentation commit on November 24, 2025 is titled “Update AI Functions documentation for GA release with enhancements.” Recent documentation updates in February, March, and May 2026 added more coverage around multimodal input, schema extraction, configuration, providers, and file workflows.

So the short version is:

The documentation trail starts in early 2025.
The GA documentation update appears in November 2025.
The more interesting expansion for practical teams is the 2026 work around multimodal inputs, broader model/provider configuration, schema extraction, and file workflows.

Sources

Shai Karmani

Let’s connect on LinkedIn

Put Copilot Metadata Where Your Team Can Review It

Shai Karmani — Wed, 20 May 2026 23:46:48 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-20-copilot-metadata-source-control.html

Copilot in Power BI is moving the semantic model into a new role.

It is no longer only the layer that stores measures, relationships, tables, and security rules.

It is also becoming the place where teams define how AI should understand the business.

That changes the engineering standard.

If Copilot uses metadata to answer business questions, that metadata should not live as invisible configuration edited by one report author on a good day.

It should be reviewed.

It should be versioned.

It should be tested.

And in serious Power BI environments, it belongs in source control.

The feature is not the point

The easy version of this story is:

Power BI now has tools to prepare semantic models for AI.

That is true, but it is not the useful lesson.

The more important shift is that Copilot readiness is becoming part of the semantic model lifecycle.

Power BI now gives model owners tools such as:

AI instructions
AI data schema context
verified answers
trigger phrases
Copilot testing workflows
an approved-for-Copilot model setting
PBIP storage for Copilot metadata

This is not report polish.

This is semantic engineering.

The metadata now lives with the model

The detail that matters most for engineering teams is simple:

When a Power BI project is saved as PBIP, Copilot metadata is stored in a Copilot/ folder inside the semantic model project.

The structure looks roughly like this:

PBIP/
├── Model.SemanticModel/
│   ├── definition/
│   ├── Copilot/
│   │   ├── Instructions/
│   │   │   ├── instructions.md
│   │   │   ├── version.json
│   │   ├── VerifiedAnswers/
│   │   │   ├── definitions/
│   │   │   ├── version.json
│   │   ├── schema.json
│   │   ├── examplePrompts.json
│   │   ├── settings.json
│   │   └── version.json
│   └── definition.pbism

That means Copilot behavior can become part of the same workflow as model changes.

A pull request can now include:

a measure change
a relationship change
a description update
a verified answer definition
an instruction change
a Copilot schema update

Those changes should be reviewed together because users experience them together.

Why this matters

Most Power BI teams already know that bad semantic models create bad reports.

Copilot adds another layer:

Bad semantic metadata creates bad AI answers.

A vague measure name is no longer just annoying for developers.

A weak description is no longer just documentation debt.

A poorly governed synonym or verified answer can steer users toward the wrong interpretation of the business.

This is especially important for models used across multiple reports or apps. When the model becomes approved for Copilot, the risk is not isolated to one page. It can affect every experience that depends on that semantic model.

What should go through review

If a team is using PBIP and Git, Copilot metadata should not be treated as noise in the repo.

At minimum, I would review these changes before promotion:

Instructions

Do the instructions reflect how the business actually talks about the data?

If finance calls it “net revenue” and sales calls it “bookings”, the model needs to make that distinction clear.

Verified answers

A verified answer should be tied to a known, trusted interpretation.

It should not become a workaround for a weak model.

Trigger phrases

The phrasing should match real user language, not developer language.

“Show customer churn by cohort” and “why did retention drop last month?” are not the same question.

Schema changes

Copilot schema updates should be reviewed with table, column, relationship, and measure changes.

Otherwise the AI context can drift away from the model.

Promotion requirements

Some tooling changes require a model refresh after deployment before they sync into the service.

That should be part of the deployment checklist, not something discovered after users start asking questions.

The migration from Q&A is a governance moment

There is another detail teams should not ignore.

Power BI can migrate older Q&A tooling metadata into the newer Copilot tooling format, but this is not a harmless cosmetic migration.

After the upgrade, Q&A features are permanently disabled for the model and connected reports. Some Q&A metadata migrates, such as synonyms and suggested questions. Other metadata does not.

That means the migration should be planned like a model change.

Not like a dialog box someone clicks through.

Before upgrading a production model, I would check:

which reports still use Q&A visuals
whether linguistic metadata is valid
which synonyms and suggested questions are worth keeping
whether business users depend on Q&A today
how Copilot answers will be tested after migration
whether the team can roll back through version history or backups if needed

A practical workflow

The best pattern is not complicated.

For production semantic models, treat AI readiness as a normal engineering workflow:

Clean up the model
Add descriptions, synonyms, instructions, and verified answers
Save the project as PBIP
Review the Copilot/ folder in Git
Test with Copilot in Desktop or the service
Check how Copilot arrived at the answer
Promote through the deployment path
Refresh the model if the deployment requires it
Monitor feedback from real users

This gives the team a simple standard:

If the change can affect what Copilot tells a user, it deserves the same discipline as a DAX or model change.

What I would add to a PR checklist

For a Power BI team using Copilot, I would add these checks to the semantic model review process:

Did any files under Copilot/ change?
Did any measure, table, or column descriptions change?
Did the change affect a verified answer?
Are trigger phrases business-readable?
Did someone test the answer in the Copilot pane?
Did someone check how Copilot arrived at the answer?
Does the model need a refresh after deployment?
Are there reports or apps that inherit the approved-for-Copilot status?
Is any Q&A migration involved?
Is the change safe for every audience that can access the model?

The real shift

The real shift is not that Power BI added more AI buttons.

The real shift is that AI behavior is becoming part of the analytics system.

That means BI teams need to stop treating Copilot readiness as a last-mile report setting.

It belongs with the semantic model.

It belongs in Git.

It belongs in code review.

And it belongs in the same quality process as every other change that can affect business interpretation.

That is how Power BI teams move from “we turned Copilot on” to “we can trust what Copilot is allowed to say.”

The Power BI Setting That Makes Semantic Models Safer

Shai Karmani — Wed, 20 May 2026 13:00:53 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-19-outbound-access-protection-semantic-models.html.

Most Power BI security conversations stop at the report.

Who can open it?

Which workspace is it in?

Which RLS role applies?

Can users export data?

Those questions still matter. But they are no longer enough.

Microsoft's preview of Outbound Access Protection for semantic models is important because it treats the semantic model as something more than a reporting artifact. It treats it as part of the data movement boundary.

That is the right mental model.

A semantic model can connect to multiple sources. It can use Import. It can use DirectQuery. It can combine tables. It can pass filter context into source queries. It can reach across workspaces and external endpoints.

So the governance question is not only:

Who can consume this model?

It is also:

Where is this model allowed to connect?

The risk is not theoretical

The uncomfortable part is that the semantic layer can become a path between sources.

Imagine a composite model with data from Source A and Source B. A user selects a value that comes from Source A. A visual or relationship pushes that value into a query against Source B.

The result does not have to be useful.

The problem is that a sensitive value may now appear in the wrong place, such as a query sent to another endpoint or a log outside the intended boundary.

That is the kind of risk many BI teams do not model explicitly.

They think about permissions on the report. They think about who can see the data. They think about gateway configuration.

But they do not always think about outbound movement from the workspace itself.

What Outbound Access Protection changes

Outbound Access Protection is a workspace-level control in Microsoft Fabric.

When it is enabled, outbound public access is blocked by default. The workspace can only connect to destinations that have been explicitly allowed.

For semantic models, the important detail is where enforcement happens. According to Microsoft's announcement, enforcement happens on the model's bound data connection. That means Power Query transformations, M expressions, and model parameters should not be able to route around the policy because the connection itself is evaluated before data moves.

That is a much stronger control than hoping every model author makes the right choice manually.

It also changes the review process.

Before this kind of control, a workspace review might ask:

Which reports are published here?
Who has build permission?
Which gateway is used?
Which semantic models are certified?

Now the review also needs to ask:

Which outbound destinations are allowed?
Who approved each exception?
Does the model really need that endpoint?
Is the destination inside or outside the expected data boundary?
What happens when a new source is added?

That is a better conversation.

Where the setting lives

The setting is under the workspace network security configuration.

The relevant path is:

Workspace settings > Network security > Outbound access protection > Block outbound public access

The toggle is simple. The operating model behind it is not.

Turning it on without planning can break legitimate model refreshes or DirectQuery paths. Leaving it off in sensitive workspaces means the model can still be bound to destinations you may not want it to reach.

This is why I would not treat Outbound Access Protection as an admin checkbox.

I would treat it as a workspace design decision.

The local workspace still needs to be allowed

One detail from the announcement is easy to miss.

The default configuration can block connections that are perceived as cross-workspace, including sources accessed through SQL, ADLS Gen2, and other non-Fabric connection kinds.

That can include data that feels local to the workspace.

For example, a semantic model may connect to a lakehouse in the same workspace through the SQL analytics endpoint or through the OneLake ADLS Gen2 path. From the policy point of view, those connection kinds may still need explicit exceptions.

That matters because a team can easily say:

This model only connects to our own lakehouse.

But the implementation detail still matters.

For Import or DirectQuery, you may need the SQL endpoint fully qualified domain name. For Direct Lake style paths, you may need the ADLS Gen2 or OneLake URL pattern.

The governance takeaway is simple:

Do not only document the business source. Document the actual connection path.

A practical rollout checklist

If I were enabling this for a real Fabric workspace, I would not start with the toggle.

I would start with an inventory.

The basic checklist:

Confirm the tenant setting is available and enabled.
Confirm the workspace is on the right capacity and contains supported items.
Inventory every semantic model connection.
Separate internal expected paths from external destinations.
Add explicit exceptions for required SQL, ADLS Gen2, cloud, or gateway connections.
Turn on Block outbound public access.
Wait for propagation.
Validate Import refreshes and DirectQuery queries.
Document the owner and reason for each exception.
Re-review the policy whenever a new source is added.

The important part is the review discipline.

A new source should not be a casual model change. If it changes where the workspace can send outbound traffic, it should trigger an access review.

What BI teams should take from this

This preview is not only a security feature.

It is a sign that semantic model governance is getting more serious.

For years, many organizations treated semantic models as a trusted middle layer because they were built by BI teams and consumed through reports.

That assumption is weaker now.

Semantic models sit in the middle of more workflows:

Power BI reports
Excel connections
DirectQuery chains
composite models
Fabric workspaces
Copilot and AI experiences
automation and API-driven scenarios

As the semantic model becomes more central, it also becomes more important to control what it can reach.

That is the part I like about Outbound Access Protection.

It forces a better architecture question:

Should this workspace be allowed to send data or queries to that destination?

If the answer is yes, make it explicit.

If the answer is no, the platform should block it.

That is how semantic models move from useful BI assets to governed platform components.

Sources

Shai Karmani

Let’s connect on LinkedIn

Before You Put a Fabric AI Agent in Production, Steal This Checklist

Shai Karmani — Tue, 19 May 2026 12:09:34 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-17-fabric-ai-agent-production-checklist.html.

A Fabric AI Agent demo can become useful faster than most teams expect.

Connect it to a semantic model. Ask a few business questions. Add context from Eventhouse, a Lakehouse, or a Warehouse. Suddenly the demo feels close to something people could use.

That is exactly where teams need to slow down for one hour.

Not to block the idea. To stop the first working demo from becoming a messy production workload.

This is the checklist I would use before moving a Fabric AI Agent past pilot stage.

1. Give the agent its own identity

A demo can run under a human account. Production should not.

If an agent depends on one person’s access, the operating model is fragile. Permissions change when that person changes role. Ownership becomes unclear. Offboarding becomes risky. Troubleshooting becomes personal instead of operational.

For a production agent, the better pattern is workload identity.

That means the agent has a dedicated service principal, with access that can be granted, reviewed, rotated, and removed without depending on someone’s user account.

This is the first line I would draw between a pilot and something ready for business users.

2. Start with one narrow use case

The easiest way to make an AI agent hard to govern is to connect it to everything.

Start smaller.

A useful production candidate sounds like this:

Explain sales variance from a governed semantic model
Summarize operational events from Eventhouse
Answer inventory questions for a specific operations team
Help finance users understand reconciliation status
Query a curated warehouse table for one business workflow

A weak production candidate sounds like this:

“Let it answer questions about our data.”

That is too broad. It gives the agent no clear boundary and gives the team no clean way to review access.

3. Map the data sources before adding them

For every data source the agent can reach, write down why it needs it.

Not in a 20-page governance document. A short access inventory is enough:

Workspace
Semantic model, Eventhouse, Lakehouse, or Warehouse
Read-only or operational access
Business owner
Approval date
Review date

The point is simple: someone should be able to look at the agent and understand its blast radius.

If nobody can explain what the agent can reach, the agent is not ready.

4. Separate dev, test, and production

Most demos start in one workspace, with one identity, and one person who understands the setup.

That is normal.

Leaving it that way is the problem.

Before production, I would want a clean path across environments:

Development for experimentation
Test for validation
Production for the restricted, supported version

The identities and permissions do not always need to be complicated. They do need to be deliberate.

If dev and production use the same broad access, every experiment becomes a production risk.

5. Confirm the audit path

If the agent gives a bad answer, uses the wrong source, or becomes part of a business process it was not designed for, you need evidence.

Before launch, answer these questions:

Which identity did the agent use?
Which data source was involved?
Who can review activity?
Who investigates issues?
How do we separate an agent issue from a model issue?

This is where a lot of AI work gets uncomfortable. The demo focuses on the answer. Production needs the trail behind the answer.

6. Treat new data sources as a change request

The first agent will not stay still.

Someone will ask to add finance data. Then operations data. Then a shortcut. Then an Eventhouse function. Then a warehouse table.

Some of those requests will be valid.

They should still trigger a review.

Every new data source changes the agent’s scope. That means the identity, permissions, audit path, and owner should be checked again.

The short version

Before a Fabric AI Agent goes live, I would want these six checks done:

Dedicated service principal
Narrow use case
Known data sources
Separated environments
Least-privilege permissions
Clear audit path and owner

If those answers are vague, the agent is still a pilot.

That is not a failure. It just means the platform work is not finished.

The goal is not to slow down AI agents. The goal is to make them safe enough to use with real business data.

Shai Karmani

Let’s connect on LinkedIn

Your Microsoft Fabric Bill Has a OneLake Problem

Shai Karmani — Tue, 19 May 2026 11:37:28 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-13-microsoft-fabric-bill-onelake-problem.html.

Most Fabric cost conversations start too late.

The bill shows up. Someone opens the Capacity Metrics app. A few workspaces look suspicious. Then the team starts asking the questions they should have asked months earlier:

Why is this data still here?

Who owns it?

Is anyone using it?

Can we move it to a cheaper tier?

Can we delete it safely?

That is not a storage problem. That is an architecture problem.

OneLake storage tiers and lifecycle management are interesting because they push Fabric teams toward a more mature operating model. Not “how much data can we land in the lake?” but “what should happen to this data after it stops being hot?”

OneLake changes the storage conversation

OneLake is designed as the single logical data lake for a Fabric tenant. Microsoft describes it as the OneDrive for data: one place for analytics data across the organization, built on top of ADLS Gen2, used by Fabric experiences like lakehouses and warehouses.

That simplicity is useful. It also creates a trap.

When storage feels central and easy, teams can treat it like an infinite landing zone.

Raw files stay forever. Staging tables become permanent. Old extracts sit next to active analytical data. Development leftovers survive because nobody wants to break something. Warehouses and lakehouses grow quietly until cost becomes visible enough to hurt.

OneLake storage is billed by data stored, per GB. It does not consume Fabric CUs, but it is still a real cost line. And OneLake transactions consume existing Fabric capacity.

So the design question is not only “can Fabric store this?”

It is “what is the lifecycle of this data?”

Data has temperature

A lot of BI teams already understand this concept informally.

Some data is hot:

used in daily dashboards
queried by semantic models
refreshed often
tied to executive reporting
needed for operational decisions

Some data is warm:

used for monthly or quarterly analysis
relevant for trend comparison
still valuable, but not constantly queried

Some data is cold:

retained for audit
rarely queried
needed for compliance or reconstruction
expensive to keep in the wrong place forever

And some data should not be stored at all anymore.

The mistake is treating all of these as the same class of data because they happen to live in the same lake.

Storage tiers force a better conversation. Lifecycle management makes that conversation operational.

The value is not only cheaper storage. The value is that someone has to define rules.

Who owns this dataset?

How long does it need to stay hot?

What is the retrieval expectation after it cools down?

What regulation or business process requires retention?

What is the cleanup rule when nobody owns it anymore?

Those are governance questions, not just admin settings.

This is where Fabric FinOps becomes real

FinOps in analytics is often treated as capacity tuning.

Pause this. Scale that. Optimize a query. Move workloads away from peak hours.

All of that matters.

But storage lifecycle is a different layer of cost discipline. It is less about fixing an expensive day and more about preventing an expensive architecture.

A Fabric team should be able to answer a few basic questions for each important workspace:

What data is actively serving reports or models?
What data is kept only for history?
What data is duplicated because a pipeline was easier to build that way?
What data is retained because of policy?
What data has no owner and no clear use?

If the team cannot answer those questions, adding lifecycle rules later will be risky. You cannot safely automate movement or deletion when nobody understands what the data is doing.

That is why I would not start with “turn on tiering everywhere.”

I would start with classification.

A simple workspace review can expose most of the issue:

active analytical data
temporary processing data
historical data
compliance-retained data
orphaned or unknown data

Only after that does tiering become useful.

The practical operating model

For a Fabric-heavy organization, I would handle OneLake lifecycle as an operating model, not a one-time cleanup.

Start with these rules:

Every important dataset needs an owner.

If nobody owns it, nobody can approve tiering, retention, or deletion.

Every workspace needs a storage review rhythm.

Monthly for active production workspaces. Quarterly for slower domains. No review means no cost control.

Temporary data needs an expiry rule.

Staging and intermediate outputs are useful. They should not become permanent by accident.

Historical data needs a retrieval expectation.

If the business expects instant access, that is one decision. If slower access is acceptable, that is another. Cost follows that decision.

Retention needs to be explicit.

“Keep everything forever” is not a retention policy. It is usually a sign that nobody wants to make the decision.

Storage metrics need to be reviewed next to business context.

The Capacity Metrics app can show where storage is growing. It cannot tell you whether that growth is justified. That part still belongs to the team.

What I would not do

I would not treat storage tiers as a magic cost button.

Moving data colder can reduce cost, but it can also create support problems if the team does not understand access patterns. Deleting data can be correct, but only when ownership and retention are clear. Automating lifecycle rules too early can turn a messy lake into a risky lake.

The better sequence is:

Measure first.

Classify second.

Apply lifecycle policies third.

Review continuously.

That is slower than a cleanup script, but it is much safer.

And for most organizations, the expensive part is not the storage itself. It is the lack of decisions around storage.

The main takeaway

OneLake storage tiers are not just a cost feature.

They are a forcing function.

They force Fabric teams to define data temperature, ownership, retention, and cleanup rules. They turn storage from an invisible side effect into an architectural decision.

That is a good thing.

Because Fabric makes it very easy to centralize data.

The next maturity step is making sure the data does not stay hot, expensive, and ownerless forever.

Sources

Shai Karmani

Let’s connect on LinkedIn

Repository Intelligence: The Real Shift Behind Microsoft Fabric + Git

Shai Karmani — Tue, 19 May 2026 11:37:26 +0000

Originally published at https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-10-repository-intelligence-fabric-git.html.

Repository Intelligence turns the Fabric repository into a reasoning surface for AI-assisted analytics engineering.

Most teams still treat Microsoft Fabric + Git integration as a source control feature.

That is understandable. The obvious benefits are versioning, pull requests, rollback, branch-based development, and CI/CD. Those are useful. I want them. Any serious analytics engineering team should want them.

But I do not think that is the real shift.

The bigger change is what happens when a Fabric workspace stops being a collection of things inside a UI and starts becoming a machine-readable representation of the analytics platform.

That is a different category of value.

Once the workspace is represented as a repository, the repo is no longer just a backup of the workspace. It becomes a context layer. And once that context layer exists, AI can work against it in a much more useful way.

Not as a chatbot floating above the platform.
Not as a natural language interface on top of one semantic model.
Not as a one-time parser for a PBIX file.

As a set of repository-aware engineering Skills that understand the structure, relationships, naming conventions, business logic, and drift inside the analytics estate.

That is what I mean by Repository Intelligence.

The mistake: stopping at source control

Fabric Git integration already gives teams a very practical foundation. Microsoft describes it as workspace-level integration with Git, where Fabric items are represented in a repository and the workspace structure, including folders, can be preserved. Supported items include semantic models, reports, notebooks, pipelines, lakehouses, warehouses, KQL assets, data agents, and more.

That matters because the repo is not just random exported files. Fabric items have a source format. For example, reports can include files like definition.pbir and report.json. Semantic models can include definition.pbism and a definition folder with TMDL files. Each item folder also includes system metadata such as .platform, with fields like type, display name, description, and logical ID.

That gives us something important: an analyzable surface.

Most teams use that surface for the normal ALM story:

commit changes
review diffs
merge to main
deploy through environments
roll back when needed

Again, all good.

But if that is where the architecture stops, the team has only moved the workspace into Git. It has not made the workspace intelligent.

The more interesting question is this:

What can reason over the repository now that the repository contains enough structure to describe the analytics platform?

The repository becomes the workspace's memory

The useful unit is not one file. It is the connected graph across the workspace.

A Fabric workspace has many kinds of knowledge hiding inside it:

semantic model tables, columns, measures, relationships, roles, and perspectives
report pages, visuals, filters, bookmarks, and dependencies
pipelines, activities, parameters, connections, and schedules
notebooks, Spark logic, lakehouse paths, and transformation patterns
warehouse objects, views, procedures, and SQL logic
data agents, instructions, examples, and configured sources
naming conventions and folder structures
business terms expressed across measures, reports, descriptions, and documentation

In the UI, those things feel separate.

In a repository, they can become connected.

A measure is not just a line of DAX. It belongs to a table. It uses columns. It may repeat business logic from another measure. It may feed visuals across several reports. Those reports may be used by a finance team. The same concept may also appear in a notebook, a pipeline name, a warehouse view, and a glossary entry.

That is the point.

The intelligence does not come from one file. It comes from the graph across files.

A single PBIX parser can tell you what is inside one report. Repository Intelligence should tell you what a change means across the workspace.

That is the difference between file inspection and platform understanding.

What I mean by AI Skills

A Skill is a controlled workflow over repository context, not a generic chatbot.

I am using the word Skill very deliberately here.

A Skill is not a generic chatbot prompt. It is a structured, reusable agent workflow designed to perform a specific engineering task against repository context.

In practical terms, I would expect a Skill to live close to the repo, often as a SKILL.md file or similar definition, with clear instructions, required inputs, safety rules, expected outputs, and examples.

A simple repository Skill might define:

Name: DAX Complexity Reviewer
Purpose: Identify measures that are too complex, duplicated, or risky to maintain.
Inputs: TMDL files, measure definitions, relationships, report dependencies.
Output: Markdown review with risk score, affected reports, and refactoring suggestions.
Allowed actions: Read files, write report, optionally open pull request.
Not allowed: Change business logic without human approval.

This is a different mental model than "ask my data a question."

Microsoft Fabric data agents are very useful for conversational Q&A over governed data sources like lakehouses, warehouses, semantic models, KQL databases, ontologies, and Microsoft Graph. They can generate SQL, DAX, or KQL under the user's permissions.

Repository-aware Skills solve a different problem.

They help engineers understand and improve the analytics platform itself.

The data agent answers business questions.
The repository Skill reviews the system that produces the answers.

Both matter. They are not the same thing.

What Repository Intelligence can actually do

Here are examples that become much more realistic once the Fabric workspace is represented as code.

1. Trace lineage across the workspace

A Skill can inspect semantic models, reports, pipelines, notebooks, lakehouse paths, and warehouse objects to build lineage that is closer to how the platform is actually maintained.

Not just "this table feeds this report."

2. Detect duplicated business logic

Every mature BI estate eventually collects duplicate definitions.

Revenue appears in five measures.
Active customer logic appears in a notebook, a SQL view, and a DAX measure.
A margin calculation changes in one report and not another.

A repository-aware Skill can search across TMDL, SQL, notebooks, pipeline expressions, and documentation to find similar logic and flag drift.

The best version is not just text similarity. It should understand semantic similarity.

Two measures can look different and still mean the same business thing.
Two measures can look similar and mean something different.

That is exactly the kind of review where an AI workflow can help, as long as it has the right context and a human keeps final judgment.

3. Score DAX and model complexity

Complexity is not automatically bad. Some measures are complex because the business is complex.

But teams still need a way to see where maintenance risk is building up.

A DAX complexity Skill could score measures based on signals such as:

length and nesting depth
repeated patterns
iterator usage
dependency chain depth
number of downstream visuals
use of ambiguous naming
duplicated logic across models
missing descriptions

The output should not be "bad measure, rewrite it."

A better output is:

Measure: Net Revenue YoY %
Risk: High
Why: deep dependency chain, repeated filter logic, used by 14 visuals across 3 reports.
Suggested next step: extract base revenue logic into a reusable measure and add a description.

That is actionable.

4. Identify governance drift

Governance problems usually show up slowly.

A workspace starts with clean naming. Then a few urgent reports get built. A pipeline is copied. A measure is created without a description. RLS roles drift. Sensitivity labels are not consistent. A notebook writes to a path nobody recognizes.

By the time someone notices, the workspace already feels messy.

A governance drift Skill can compare the repo against standards:

naming conventions
folder structure
required descriptions
semantic model role patterns
report certification rules
deployment rules
forbidden shortcuts or connection patterns
expected owner metadata

The Skill does not need to be dramatic. It just needs to be consistent.

Every pull request can get a small governance review before the mess becomes normal.

5. Regenerate useful documentation

Most documentation fails because it is detached from the system.

Someone writes it once. The model changes. The pipeline changes. The documentation becomes a museum.

The repository gives us a better option.

Documentation can be generated from the same files engineers are already changing.

A documentation Skill could maintain:

README files for each workspace or domain
semantic model dictionaries
measure catalogs
report inventories
pipeline summaries
data product ownership notes
change summaries for business stakeholders

The important part is not generating pretty prose.

The important part is keeping the documentation close to the source of truth and refreshing it when the source changes.

6. Translate business glossary into implementation

This is where things get interesting.

Most organizations have business terms that live somewhere outside the model. Sometimes in SharePoint. Sometimes in Excel. Sometimes only in someone's head.

A Skill can compare glossary terms against the repository and ask practical questions:

Is this term implemented as a measure?
Is the definition consistent across models?
Are the report labels aligned with the glossary?
Is there a measure description users can trust?
Does the DAX logic match the business definition closely enough to review?

It should not auto-create business logic and pretend it is correct.

But it can scaffold the work:

proposed measure names
draft descriptions
candidate DAX patterns
impacted reports
questions for the business owner

That makes the human review sharper.

7. Open pull requests with context

The natural end state is not just analysis. It is controlled action.

A repository-aware Skill should be able to open a pull request that includes:

the proposed file changes
the reason for the change
the affected Fabric items
the lineage impact
the test or validation notes
the governance checks it performed
questions that still require a human decision

This is where the repo becomes the operating surface for AI-assisted analytics engineering.

Not autonomous chaos.

Controlled, reviewable, auditable changes.

A practical starter architecture

The practical path is small: sync, index, review, assist, then controlled action.

If I were starting this in a real Fabric environment, I would not try to build a giant agent first.

I would start small.

Step 1: Connect the workspace to Git

Get the basics right first. Use Fabric Git integration at the workspace level. Keep folder structure intentional. Make sure the supported items that matter to your team are actually syncing.

Do not skip naming. AI depends heavily on names, descriptions, and structure. Bad naming is not just a human problem anymore. It becomes machine context debt.

Step 2: Build a repository index

Create a lightweight index of the repo:

item folders
item types
logical IDs
display names
semantic model files
report files
pipeline definitions
notebook files
dependency references
descriptions and labels

This does not need to be perfect on day one.

The first version can be a simple JSON index generated on every commit.

Step 3: Create three Skills, not thirty

I would start with three Skills that create obvious value:

Workspace Documentation Skill
Regenerates README files, inventories, and semantic model summaries.
Semantic Model Review Skill
Reviews measures, relationships, descriptions, naming, and obvious DAX risks.
Lineage Impact Skill
Answers "what breaks or changes if this asset changes?" for pull requests.

These are boring in the best way. They help every team.

Step 4: Run Skills in pull requests

Do not start by giving the agent write access to everything.

Start with read-only reviews in pull requests.

Let the Skill comment with findings. Let humans decide. Measure which findings are useful. Tune the Skill instructions. Add examples from real reviews.

Only after that should you allow limited write actions, like regenerating documentation or adding missing descriptions.

Step 5: Keep the human in the loop

Repository Intelligence should reduce blind spots, not remove accountability.

If a Skill suggests a DAX refactor, a person still owns the business meaning.
If a Skill flags governance drift, a person still decides priority.
If a Skill opens a PR, a person still reviews and merges.

That boundary is not a weakness. It is the safety model.

The real asset is context

Models will improve. APIs will change. Copilot features will keep moving. Fabric data agents will get better. The tooling around AI-assisted engineering will keep changing too.

But the durable asset is the context layer.

A clean, machine-readable repository that describes the analytics platform is valuable no matter which model or agent framework sits on top of it.

That is the part teams should pay attention to.

Not because Git is new.

Because Git turns the Fabric workspace into something AI can reason about.

Semantic models. Reports. Pipelines. Notebooks. KPIs. RLS roles. Naming conventions. Business logic. Documentation. All of it becomes part of the same graph.

That graph is where Repository Intelligence starts.

And I think that is the real shift behind Fabric + Git.

Useful Skills to build first

A starter catalog of repository-aware Skills for Fabric teams.

If you want a practical starting backlog, I would build these in this order:

Repo Inventory Skill
Creates a structured map of all Fabric items in the repository.
Lineage Impact Skill
Explains downstream impact for changed tables, columns, measures, notebooks, and pipelines.
DAX Complexity Skill
Scores risky measures and points reviewers to the right places.
Documentation Refresh Skill
Updates READMEs, model dictionaries, and report inventories from the repo.
Governance Drift Skill
Checks naming, descriptions, RLS patterns, owners, and folder standards.
Glossary Alignment Skill
Compares business terms against measures, labels, and descriptions.
Pull Request Context Skill
Summarizes what changed, why it matters, and what reviewers should check.

That is the path I would trust.

Small Skills. Clear boundaries. Real repository context. Human review.

That is how AI-native analytics engineering starts to become practical.

Sources and notes

Microsoft Fabric Git integration overview: https://learn.microsoft.com/en-us/fabric/cicd/git-integration/intro-to-git-integration
Microsoft Fabric Git source code format: https://learn.microsoft.com/en-us/fabric/cicd/git-integration/source-code-format
Microsoft Fabric data agents: https://learn.microsoft.com/en-us/fabric/data-science/concept-data-agent

Shai Karmani

Let’s connect on LinkedIn