When you activate Microsoft Fabric, your tenant comes pre-configured with over 140 settings. Some are switched on by default. Others are off. Most administrators never review them systematically — and that gap quietly creates real risk: data accessible to the wrong people, sensitivity labels not propagating, guest users invited without governance, Copilot sending data outside your EU boundary.

This tool gives you a clear, structured view of every tenant setting, what it does by default, what best practice looks like, and how much it matters if you leave it unchanged.

How to use it

Use the search and filters to focus on what matters most. Start with Requires Adjustment: Yes and Impact: High — that’s your priority list. You can also download the full table as a formatted Excel file to share internally or use in a governance review.

The table covers all current Microsoft Fabric tenant settings across every category — from information protection and export controls to Git integration, Copilot, and OneLake. Each row shows:

• Default setting — what Microsoft configures out of the box
• Recommended setting — what a well-governed tenant should have
• Requires adjustment — whether the default needs to change
• Impact — how much risk you carry by leaving the default in place (High / Medium / Low)

The table is updated automatically whenever Microsoft changes the documentation, so you’re always working from a current baseline.

What this isn’t

This is a reference and starting point, not a one-size-fits-all prescription. The right configuration for your organisation depends on your industry, compliance requirements, licensing tier, and how mature your BI governance is. A manufacturing company with a single internal team has different needs from a healthcare group with external data sharing in scope.

If you work with Microsoft Power BI, you've almost certainly heard this question over the past year:

"Do we still use Power BI, or are we supposed to move to Microsoft Fabric now?"

The short answer is straightforward: Power BI didn't go away. Fabric didn't replace it. But the context Power BI operates in has changed — and that matters for architecture, governance, and capacity planning.

This article breaks down what actually changed, what's mostly marketing, and how Power BI professionals should think about Fabric in practice today.

Power BI vs Fabric: The Correct Mental Model

Before Fabric, Microsoft analytics was a collection of loosely connected services:

• Power BI
• Azure Data Factory
• Synapse
• Dataflows
• Separate storage layers

Fabric's goal is consolidation:

• One platform
• One storage layer
• One capacity model

Power BI is now one workload inside Fabric, not a separate product line.

What Actually Changed (And Matters)

1. OneLake Is Real — and It's the Biggest Shift

Fabric introduces OneLake, a single, tenant-wide data lake shared across Fabric workloads.

Why this matters in practice:

• Data no longer has to be copied between tools
• Multiple teams can access the same underlying data
• Storage and compute are more clearly separated

Best-practice implications for Power BI:

• Treat OneLake as a centralized data foundation, not a dumping ground
• Keep transformation ownership clear (engineering vs BI)
• Use Power BI semantic models to consume and shape data, not to store it redundantly

This reinforces a long-standing Power BI principle: centralize data, standardize logic, decentralize reporting.

2. Dataflows Didn't Disappear — They Evolved (Carefully)

Power BI Dataflows still exist. Fabric adds Dataflows Gen2, which:

• Write directly to OneLake
• Can be reused by non–Power BI workloads
• Still use Power Query under the hood

What didn't change:

• They're best suited for light to moderate transformations
• They're not a replacement for full-scale data engineering pipelines
• They require careful performance and dependency management

Practical guidance:

• Use Dataflows for reusable, business-owned transformations
• Avoid pushing heavy joins, large-scale fact processing, or complex orchestration into them
• Keep Gen1 dataflows if they're stable and meeting business needs

3. Capacity: Unified, but Less Forgiving

Fabric introduces unified capacity (F-SKUs) that power:

• Power BI
• Data Engineering
• Data Warehousing
• Real-Time Analytics

This replaces multiple disconnected pricing and capacity models.

What's better:

• One shared pool of compute
• Easier architectural alignment across teams
• Fewer platform silos

What's harder in reality:

• Power BI Pro licenses are still required for authors
• BI workloads now compete with engineering workloads
• Poorly designed pipelines can directly impact report performance
• Cost attribution across workloads is still evolving

When Fabric Capacity Makes Sense (And When It Doesn't)

Fabric capacity is a strong fit when:

• Multiple teams share the same data platform
• BI, engineering, and analytics workloads coexist
• You already struggle with Premium constraints
• Centralized governance is a priority

Traditional Power BI Premium still makes sense when:

• Power BI is the primary or only workload
• Fabric engineering features are out of scope
• Cost predictability matters more than flexibility
• The BI team owns most of the data lifecycle

Fabric is not mandatory — it's optional architecture.

What's Mostly Hype (For Now)

"You Must Move Everything to Fabric"

Not true.

• Existing Power BI workspaces continue to work
• Premium capacities still exist
• Microsoft supports gradual, selective adoption

There is no requirement to redesign a functioning Power BI estate just because Fabric exists.

"Power BI Is Just a Front-End Now"

Also not true.

Power BI semantic models still:

• Define business metrics
• Enforce governance and security
• Control performance at query time

Fabric adds upstream options — it does not replace the semantic layer. Business logic still belongs closest to consumption.

Fabric Readiness: An Honest Reality Check

Fabric is directionally strong, but not frictionless:

• Monitoring across workloads is still fragmented
• CI/CD for Fabric assets is evolving
• Cost visibility at workload level can be unclear
• Many organizations lack the engineering maturity Fabric assumes

For some teams, Fabric will feel empowering. For others, it will introduce operational complexity. Both outcomes are valid.

What This Means for Your Power BI Setup Today

If you already follow Power BI best practices, you're not behind.

Keep Doing:

• Star schema modeling
• Thin reports over shared semantic models
• Certified datasets
• Clear Dev/Test/Prod separation

Start Evaluating:

• Centralized data in OneLake
• Dataflows Gen2 where reuse is required
• Capacity planning that accounts for non-BI workloads

Avoid:

• Rebuilding solutions "because Fabric"
• Mixing heavy ETL logic into Power BI models
• Assuming capacity will compensate for poor design

The Bottom Line

Power BI wasn't replaced — it was repositioned.

Fabric is:

• An architectural unification
• A platform-level shift
• A stress test for existing BI practices

For Power BI professionals, the message is simple: Fabric is not a reason to redesign your Power BI estate. It's a reason to validate whether your existing design was sound to begin with.

If your foundation is solid, Fabric isn't something you need to rush into. It's something you can adopt — deliberately, incrementally, and on your terms.

A Power BI Centre of Excellence (CoE) is not a reporting factory, and it's not a governance police force. At its best, it's a small, focused capability that enables scale: trusted data, consistent standards, and empowered report creators.

This guide outlines a pragmatic, experience-based approach to building a Power BI CoE that works in real organisations — aligned with Microsoft Power BI best practices, without unnecessary theory.

Step 1: Define the Purpose and Operating Model

Before defining tools, roles, or standards, be clear about why the CoE exists.

Most successful Power BI CoEs focus on:

• Improving trust in data and metrics
• Reducing duplication and rework
• Enabling self-service analytics safely
• Allowing Power BI usage to scale without chaos

Just as important is clarity on what the CoE is not:

• Not the only team allowed to build reports
• Not a mandatory gate for every dashboard

Define how the CoE engages

Many CoEs struggle because their engagement model is never explicit. Decide early:

• When the CoE advises vs approves vs owns assets
• Whether shared datasets are owned centrally or by domains
• How decisions are escalated when standards are challenged

If you can't describe the CoE's purpose and operating model in two sentences, it isn't ready to launch.

Step 2: Secure Executive Sponsorship (With the Right Framing)

Active executive sponsorship is a strong predictor of CoE success. Without it, standards quickly become optional.

What typically resonates with leaders:

• Reduced risk (data security, compliance, auditability)
• Faster, more confident decision-making
• Lower long-term cost through reuse and standardisation

What rarely resonates:

• Dataset design patterns
• Workspace naming conventions

Be explicit about what you're asking for:

• Visible sponsorship, not just initial approval
• Clear decision rights for standards and exceptions
• Time allocation for CoE members

Step 3: Start Small With the Right Roles (Not a Big Team)

You don't need a large team to start a CoE. Most effective CoEs begin with 3–6 people, often part-time, covering these roles:

• CoE Lead / Product Owner — prioritisation, stakeholder alignment
• Power BI Architect — semantic models, performance, scalability
• Platform or Tenant Admin — tenant settings, security, deployments
• Enablement Lead — training, documentation, community building

These are roles, not job titles. Over-staffing early often leads to over-engineering. Scale the team only once demand is proven.

Step 4: Establish Governance People Will Actually Follow

Governance fails when it's either too abstract or too restrictive. Anchor it in everyday Power BI work and make expectations clear.

Workspace strategy

Define a small number of workspace types with clear intent, for example:

• Personal / Sandbox — experimentation and learning
• Team / Department — collaborative delivery
• Certified / Endorsed — trusted, reusable content

Tie permissions, review expectations, and support levels to each type.

Dataset and model standards

Keep standards practical and enforceable:

• Clear naming conventions for measures
• Required descriptions for shared or certified models
• Performance expectations for reusable datasets

A simple certification checklist often works better than long documentation. For example:

• Refresh succeeds consistently
• Measures are documented
• Query performance meets agreed thresholds
• Security has been reviewed
• A named business owner exists

Change and release management

Not every change requires heavy process:

• Use Dev/Test/Prod for shared datasets
• Apply lightweight peer review for certified assets
• Define rollback expectations

Equally important is change communication. Define how breaking changes are announced, how long deprecations last, and where consumers can see what changed. Technical controls alone don't protect trust.

Step 5: Configure the Power BI Tenant Intentionally

The Power BI Admin Portal is where governance becomes enforceable.

Align tenant settings with your organisation's maturity:

• Be cautious with external sharing and publish-to-web early
• Control who can use premium features and create shared assets
• Enable audit logs and usage metrics from day one

Always document why each tenant setting exists. This prevents policy drift and helps future admins make informed changes.

Step 6: Enable Self-Service Instead of Fighting It

Self-service analytics will happen whether you plan for it or not. The CoE's role is to make the right way the easy way.

Effective enablement typically includes:

• Shared, well-designed semantic models
• Report templates with branding and layout guidance
• Short, task-focused training sessions

Community scales better than ticket queues. Internal user groups, office hours, Teams channels, and showcase sessions often deliver more value than formal support processes.

Step 7: Measure, Prove Value, and Evolve

A CoE should be treated as a product, not a one-time project.

Track platform metrics such as:

• Active users and creators
• Reuse of shared and certified datasets
• Support requests and performance issues

Over time, link these to business outcomes:

• Fewer duplicate reports
• Faster delivery of new insights
• Reduced dependency on central teams for ad-hoc requests

As maturity increases, successful CoEs typically loosen controls, shifting from enforcement to enablement.

Common CoE Failure Modes

• Lack of clear ownership — No one knows who owns shared datasets, standards, or decisions, leading to slow progress and conflict.
• Over-governance too early — Heavy approval processes and restrictive tenant settings drive users to work around the platform.
• CoE as a delivery factory — The CoE becomes the default report-building team, creating bottlenecks and burnout.
• Ignoring change management — Breaking changes land without warning, eroding trust in shared datasets.
• No success metrics — Without measurable outcomes, the CoE is eventually seen as overhead rather than value.

Final Thought

The most durable Power BI Centres of Excellence succeed because people want to follow the standards — not because they're forced to.

Start small, stay pragmatic, and optimise for trust over control. Perfect governance is rarely achievable; consistent, trusted insight at scale is.

If you've worked with Microsoft Power BI long enough, you know this pattern well: the model starts clean, measures are simple — and six months later, no one wants to open the measure pane.

This usually isn't because the business logic is hard. It's because the wrong DAX patterns were allowed to spread.

The five functions below aren't advanced tricks. They are foundational tools that, when used consistently, keep models understandable, performant, and safe for teams to evolve over time.

1. CALCULATE — The Engine Behind Context

CALCULATE is the most important function in DAX because it changes filter context. Almost every meaningful business measure relies on it, directly or indirectly.

Why it matters

• Enables time intelligence and conditional logic
• Allows measures to define their own business rules
• Keeps logic centralized instead of scattered across visuals

Example

CopySales – Online :=
CALCULATE (
    [Total Sales],
    'Sales'[Channel] = "Online"
)

This measure is explicit: the logic lives in DAX, not in report-level filters.

2. VAR — Readability First, Performance Second

VAR lets you store intermediate results inside a measure and reuse them cleanly.

Why it matters

• Makes measures easier to read and review
• Simplifies debugging and testing
• Can improve performance by avoiding repeated evaluation

Example

CopyProfit Margin :=
VAR Revenue = [Total Sales]
VAR Cost = [Total Cost]
RETURN
DIVIDE ( Revenue - Cost, Revenue )

This pattern is easier to reason about than a single dense expression — especially in team environments.

3. DIVIDE — Defensive DAX That Behaves Well in Reports

Division errors are a common cause of broken visuals and confused users. DIVIDE handles divide-by-zero scenarios safely and intentionally.

Why it matters

• Prevents errors without verbose logic
• Returns BLANK() by default, which behaves better in visuals
• Keeps measures concise and readable

Example

CopyProfit Margin :=
DIVIDE ( [Profit], [Total Sales] )

BLANK() values suppress misleading percentages in matrices and charts, instead of showing zeros that imply meaning.

4. SELECTEDVALUE — Safe Context Awareness

Interactive reports require measures to react to user selections. SELECTEDVALUE retrieves a single value only when exactly one exists, otherwise returning a defined fallback.

Why it matters

• Cleaner than VALUES + HASONEVALUE
• Prevents ambiguous or broken results
• Ideal for slicer-driven logic and dynamic labels

Example

CopySelected Year :=
SELECTEDVALUE ( 'Date'[Year], "Multiple Years" )

5. ALL and REMOVEFILTERS — Intentional Control of Filters

Some calculations must ignore parts of the filter context — totals, benchmarks, or contribution percentages. That's where filter-removal functions belong.

Why it matters

• Enables percent-of-total and share calculations
• Supports baselines and comparisons
• Keeps logic consistent across reports

Example

CopyTotal Sales (All Products) :=
CALCULATE (
    [Total Sales],
    REMOVEFILTERS ( 'Product' )
)

What Not to Do (Common Team Pitfalls)

Avoid these patterns — they're responsible for most fragile models:

• Embedding business logic in visuals instead of measures
• Nesting multiple CALCULATE calls without documenting intent
• Using / instead of DIVIDE in production measures
• Overusing SELECTEDVALUE where row context already exists
• Removing filters broadly (ALL(Table)) when only a column needs to be ignored
• Writing clever one-line measures that no one else can maintain

If a measure needs explaining in a meeting, it probably needs refactoring.

Final Thought: DAX Is a Team Discipline

These functions don't make a model "advanced" on their own. What matters is how consistently they're applied.

Strong BI teams:

• Centralize logic in measures
• Prefer clarity over cleverness
• Agree on filter-handling patterns
• Write DAX that explains itself

When your measures are readable, predictable, and performant, you reduce defects, speed up onboarding, and turn your semantic model into something the business can actually rely on.

This article is about how to write Power BI best practices that professionals will actually follow — grounded in Microsoft Power BI guidance, but shaped by real-world delivery in enterprise and shared-reporting environments.

Why Most Power BI Best Practices Fail

Most best practices don't fail because they're wrong. They fail because they're unusable.

Common problems include:

• Rules that are too abstract ("Use good naming conventions")
• Documents that are too long to reference while working
• Generic guidance copied directly from documentation
• Assumptions of ideal, greenfield projects that don't exist in reality

Power BI professionals work under time pressure, with evolving requirements and imperfect data. If a rule doesn't help them make a decision while building, it gets ignored.

Effective best practices are:

• Specific
• Actionable
• Easy to check in under a minute

Start From How Power BI Is Actually Used

Microsoft's Power BI guidance assumes a few realities that are worth embracing:

• Models grow over time
• Multiple developers touch the same dataset
• Performance problems often appear after adoption
• Business users rarely read documentation

Best practices should be written for living models, not theoretical ones. That means accounting for refactoring, handovers, and long-term support — not just first delivery.

Structure Best Practices Around Real Decisions

Developers don't think in categories like Modeling or Visualization. They think in questions:

• "Should this be a calculated column or a measure?"
• "Do I need a new table, or can I reuse an existing one?"
• "Is this DAX readable enough for someone else to maintain?"

Best practices should be structured to answer those questions directly.

Avoid this

Keep DAX simple.

Prefer this

If a measure contains multiple business rules, use variables and helper measures to improve readability, testing, and long-term maintenance.

The intent is the same — but the second version is something a developer can act on immediately.

Focus on the 20% That Causes 80% of Problems

Microsoft documentation is comprehensive. Your internal best practices shouldn't be.

Prioritize guidance that consistently causes issues in real projects:

• Poor data modeling
• Hard-to-maintain DAX
• Inconsistent naming and formatting
• Performance degradation at scale
• Loss of trust in reported numbers

For most Power BI teams, that usually means emphasizing:

• Star schema modeling
• Measure-driven calculations
• Avoiding unnecessary calculated columns
• Consistent naming and formatting conventions
• Careful use of bi-directional relationships

Be Precise About Measures vs Calculated Columns

A common source of confusion is when to use calculated columns versus measures.

A practical guideline looks like this:

• Prefer measures for aggregations and calculations evaluated at query time
• Avoid calculated columns on large fact tables where possible, as they increase model size and refresh cost
• Use calculated columns when values must be evaluated at refresh time, used in relationships, or exposed as slicers

This avoids dogma while aligning with how Power BI's engine actually works.

Make Performance Guidance Concrete — and Contextual

Performance advice is often ignored because it's vague or applied too early.

Instead of

Optimize your model for performance.

Be explicit and situational

• Disable Auto Date/Time in shared or enterprise datasets
• Reduce column cardinality where possible
• Hide unused columns from the report view
• Avoid bi-directional relationships unless there is a clear requirement
• Validate performance using Performance Analyzer before publishing

Treat Naming and Formatting as First-Class Practices

"Be consistent" isn't enough.

Good best practices provide examples, even if the exact standard varies by team.

For example:

• Use business-friendly names with spaces (not underscores)
• Avoid abbreviations unless they are widely understood by the business
• Keep measure names free of table prefixes
• Apply consistent number formatting at the model level

Clarity here improves usability, reduces confusion, and builds trust with report consumers.

Write for the Author, Not the Auditor

Best practices are rarely enforced by formal reviews. They're followed — or ignored — while someone is building a model.

That means they should be:

• Skimmable
• Short
• Written in plain language
• Easy to reference during development

If a developer can't quickly confirm a rule while writing DAX or modeling data, the rule won't be used.

Accept Constraints and Trade-Offs

Not every best practice can be applied in every situation.

Legacy data sources, organizational constraints, tight deadlines, and governance rules all force compromises. Good guidelines acknowledge this instead of pretending it doesn't happen.

The goal isn't theoretical perfection. It's consistency, transparency, and maintainability.

Keep Best Practices Alive

Power BI evolves constantly. So should your guidance.

To keep best practices relevant:

• Review them periodically
• Update them after major platform changes
• Adjust them based on real incidents and lessons learned

And make them easy to find:

• A short internal wiki page
• A README alongside shared datasets
• A pinned Teams or Slack post

The Real Goal

The purpose of Power BI best practices isn't to create flawless models.

It's to create predictable, understandable, and maintainable ones.

If your guidelines help someone make a better decision while building, they'll be followed.

If they can be checked quickly and explained easily, they'll last.

That's when best practices stop being rules — and start becoming shortcuts.

Three months ago I had never written a Python agent in my life. I knew DAX, data modelling, and governance — but agentic AI was completely new territory. I built this anyway, because I kept seeing a problem I wanted to solve. I’m calling it the Power BI DAX Agent, and I’ve made it free for anyone to use.

This article explains why I built it, who it is designed for, how it compares to other AI-powered approaches to Power BI development, and where it’s heading next.

Why I Built This

The problem I kept running into wasn’t with Power BI itself. It was with the context in which most companies use it.

In a mid-size company, there is usually one person who “does Power BI.” That person is not necessarily a dedicated BI developer. They are a finance manager who learned DAX from YouTube, or an ops analyst who built a dashboard that got promoted to the company’s main reporting tool, or an IT generalist who maintains a growing semantic model alongside everything else they do.

These people face a specific and under-discussed problem: they need to change things without breaking things.

They’re not looking for ways to build faster. They’re worried about what happens when they rename a column that fifteen measures depend on. They don’t know if the measure they’re about to create already exists under a slightly different name. They have no way of knowing the downstream impact of a change before they make it.

Existing AI tools for Power BI don’t really solve this problem. Most of them are designed to make senior developers faster — which is valuable, but it’s not the same thing.

So I built something designed around a different principle: confidence over speed. I built it with Claude Code, drawing on ideas from Kalina Ivanova and Kurt Buhler’s work in the Power BI agentic development space.

What the Agent Actually Does

The Power BI DAX Agent is a locally-running web application. You open it in your browser, point it at your Power BI model file, and describe the measure you need in plain English. The agent generates validated DAX using only your actual tables and columns, checks for duplicates, and asks for your approval before saving anything.

Here is the end-to-end flow:

1. Load your model with a sanitisation review

Before anything reaches the AI, the agent scans your model file and strips sensitive metadata — database connection strings, file paths, email addresses, SharePoint URLs, and similar content. You see exactly what was found and what was masked. Nothing proceeds until you explicitly approve the clean version. The idea for this gate came from Kalina Ivanova, who built a standalone PowerShell script to scrub sensitive metadata from TMDL files before sharing with AI tools. I took that concept and embedded it directly into the agent workflow. Kurt Buhler’s power-bi-agentic-development repository also shaped how I thought about safe agentic patterns for Power BI more broadly.

The sanitisation review screen — you see exactly what was found and masked before anything is loaded into the agent.

The expandable items list shows each masked value and what it was replaced with.

2. Explore your schema and understand dependencies

Once the model loads, a lineage graph is built automatically. You can select any table, column, or measure and see everything that depends on it. If you’re about to change a column, the agent tells you exactly which measures would be affected. You know the blast radius before you touch anything.

Impact Analysis — select any table, column, or measure to see everything that depends on it.

3. Generate DAX with a human approval gate

You describe what you need. The agent checks your measure library first — if a similar measure already exists, it surfaces it and asks if you want to use it instead. If nothing matches, it generates DAX, validates it structurally and semantically, and presents it for your review. You approve it or reject it. Only approved measures are saved.

The Generate a Measure tab — describe what you need in plain English, review the output, and approve or reject it.

The full interface — model settings and sanitisation options in the sidebar, the main workspace on the right.

4. Build an institutional measure library

Every approved measure is saved to a persistent library with the original request, the DAX, how many attempts it took to generate, and a timestamp. Over time this becomes a searchable record of every measure your team has generated, which also feeds back into the duplicate detection.

Who This Is For

The primary audience is anyone managing Power BI — particularly in EU markets where data governance and GDPR compliance are genuine daily concerns, not theoretical ones.

More specifically, it is designed for:

• The solo BI person who owns the Power BI environment and needs a reliable assistant that works within guardrails, not around them
• Freelance Power BI consultants who work across multiple client environments and want a consistent, governed workflow for measure development
• Small BI teams where junior analysts are generating measures but a senior developer wants oversight before anything reaches the production model
• Companies in regulated industries — healthcare, financial services, legal — where every change to a reporting environment needs to be traceable and auditable

That said, this is not limited to that audience. Any Power BI developer who values a governed workflow over an unconstrained one may find it useful — especially for client-facing or production environments where mistakes are expensive.

How This Compares to MCP + Copilot and VS Code + Copilot

This is the question I expect most from people who already use AI tools for Power BI development, so I want to address it directly.

Microsoft’s Power BI Modeling MCP Server

Microsoft recently released a Power BI Modeling MCP Server that lets AI assistants like GitHub Copilot or Claude talk directly to a running Power BI Desktop instance. You can ask it to create measures, rename tables, build relationships, and refactor your model through natural conversation in VS Code or Claude Code.

This is genuinely impressive technology and I use it myself for exploratory work. But it is designed for a developer workflow, and it makes some assumptions that are not safe in a business context:

• It writes changes directly to your open model. There is an undo function, but there is no approval gate, no audit trail, and no blast radius analysis before a change is made.
• It sends your full model schema to the AI — including connection strings, file paths, and RLS definitions — without a sanitisation step.
• It requires Power BI Desktop to be open and running. It cannot work from a model file alone.
• It has no persistent memory. Nothing is remembered between sessions. There is no measure library, no duplicate detection, no lineage graph.

For a senior developer working on their own environment who knows what they are doing: MCP is fast and powerful. For a business context where multiple people touch a model and changes need to be traceable: it is missing the safety layer.

VS Code + GitHub Copilot (without MCP)

This is the more general version of the developer assistant workflow — using Copilot in VS Code to help write DAX, Power Query M code, or TMDL. It is useful for developers who are already comfortable in a code editor and want AI assistance inline.

The same considerations apply. This is a tool that makes developers faster. It does not address governance, impact analysis, or the non-technical user.

Where the Power BI DAX Agent Sits

The DAX Agent is not trying to compete with MCP for the developer use case. It is solving a different problem for a different audience.

The Data Protection Question

One question I get asked immediately whenever AI and Power BI are mentioned together is: what data actually leaves my machine?

This is the right question to ask, and I want to answer it precisely.

When you load a model into the agent, the following happens on your machine only:

• The raw model file is read from your local disk
• The sanitisation scan runs locally — finding and masking connection strings, paths, emails, URLs, and any other sensitive metadata you have configured
• You review the sanitisation report in your browser (which is running at localhost — your machine talking to itself)
• You approve the clean version

The first and only time anything leaves your machine is when you type a measure request and click Generate. At that point, the sanitised schema (table names, column names, measure names, data types, relationships) and your plain English request are sent to the Anthropic API.

What never leaves your machine: actual data values, database connection strings, file paths, email addresses, RLS role definitions, and any other sensitive metadata the sanitiser has masked.

The agent runs locally. There is no cloud server receiving your files. If you are in a regulated industry or a GDPR-sensitive environment, the sanitisation gate is configurable — you can choose to also mask GUIDs and remove RLS definitions entirely before the model is reviewed.

What’s Still Being Built

This is a working prototype, not a finished product. I am sharing it now because real-world feedback is more valuable than months of building in isolation.

What is working today:

• Model loading with sanitisation review and approval gate
• DAX generation using your actual schema
• Two-layer validation with automatic retry
• Duplicate measure detection
• Human approval gate before saving
• Persistent measure library with search
• Lineage graph with impact analysis
• Model browser in the sidebar
• Support for any model.bim file

What is still being built:

• System A — a discovery and requirements agent that conducts a structured interview with business stakeholders and produces a semantic model design from scratch
• System C — a full amendment protection layer with regression testing, so changes to existing measures can be validated against known-good baselines before deployment
• Automatic deployment to Power BI via the REST API or XMLA endpoint
• Hosted version for clients who cannot run a local install
• Multi-user support with role-based access

Try It and Tell Me What’s Missing

The repository is public and free to use. You bring your own Anthropic API key — a month of typical usage costs a few euros.

View on GitHub →