Claude for Power BI: Measures, Dashboards, and Review

Claude can help you write and troubleshoot DAX measures, explain data model relationships, draft requirements for new dashboard pages, and review calculation logic before it reaches production. It cannot connect to Power BI directly or see your data—but given a clear brief about your tables, fields, and business rules, it can handle the analytical writing work faster than most documentation.

The quality of what Claude produces depends almost entirely on how well you describe your data structure and business logic. fenbs keeps approved metric definitions, unresolved questions, and review tasks outside the conversation, so each session starts from a known and agreed set of facts rather than rebuilding the context from scratch.

Start with a clear data model brief

Before asking Claude to write a DAX measure, describe the relevant parts of your data model. You do not need to paste the entire model—just the tables and columns that relate to the metric. For example: "FactSales has OrderDate, ProductID, CustomerID, and SalesAmount. DimProduct has ProductID, Category, and SubCategory. They join on ProductID." That level of detail is usually enough for Claude to write accurate DAX.

Include your business definitions for key terms. "Revenue" might mean different things in different companies: gross sales, net of returns, net of discounts, or some other combination. "Active customer" might mean purchased in the last 90 days or the last year. Claude will use whatever definition you give it. If you do not give one, it will assume, and that assumption may be wrong.

If you use a date table—which Power BI best practice recommends—tell Claude its name and the key columns, including the date key, year, quarter, month, and week fields. This lets Claude write time intelligence measures that reference your actual date table rather than a generic template.

Pasting a few sample rows into the conversation can also help. Claude cannot access your database, but three or four rows of realistic values help it understand the shape and format of your data. Knowing that SalesAmount is a decimal currency value and OrderDate is formatted as YYYY-MM-DD prevents Claude from suggesting DAX that would fail on a type mismatch. A small, realistic sample is usually enough; you do not need to share the full dataset.

Write and debug DAX measures

Give Claude the business question the measure needs to answer, the relevant tables and columns, and any filter context it should respect. A prompt like "Write a DAX measure for year-to-date revenue that resets on the fiscal year start of July 1, using the DateTable[DateKey] column" will produce a more accurate result than "write me a YTD measure."

When debugging, paste the failing measure, describe what it returns, and describe what you expect. Claude can identify common DAX errors: wrong filter context, mismatched key types, CALCULATE modifiers in the wrong order, or incorrect use of ALLEXCEPT versus REMOVEFILTERS. It cannot run the measure against your data, so it will sometimes produce a plausible-looking formula that has a subtle logic error. Always test in Power BI Desktop before publishing.

For complex measures, ask Claude to explain the logic step by step before you accept it. If the explanation does not match your intent, correct it and ask Claude to revise. Working through the logic in conversation is often faster than debugging a silent failure in the report.

Plan dashboard layouts and visual requirements

Claude can help draft a visual requirements document for a new dashboard page: which metrics appear, which dimensions filter them, what the default date range should be, and how the visuals relate to each other. Describing the business question the page answers—"the sales manager needs to see territory performance against target for the current quarter"—gives Claude enough context to propose a sensible layout.

Treat the output as a starting draft. Review it with the people who will use the dashboard before building anything. Claude does not know your organization's visual standards, preferred color palette, or the specific data literacy of your audience. Add those constraints to your original description for a closer first draft, or correct them after reviewing the output.

For the relationship between Power BI's own AI features and external assistants like Claude, the Power BI AI insights guide covers what is built into the product and where an external assistant adds value.

Validate Claude's outputs before publishing

Claude's DAX and logic suggestions are starting points, not finished deliverables. Test every measure in Power BI Desktop against known values before publishing. Cross-check DAX totals against a simple SUM or COUNT you can verify manually. If the numbers differ, check filter context first—most DAX errors come from unexpected filter propagation.

Keep a list of open questions as they arise: edge cases Claude flagged, filter behaviors it could not confirm, or business definitions that still need a sign-off from the data owner. Parking those questions in the conversation and forgetting them is how calculation errors make it to production.

Keep approved metric definitions and business rules

One of the most common Power BI problems is metric drift: different dashboards calculate the same figure differently because there is no single agreed definition. When you and Claude work out that "revenue" for this report means net of returns but not of discounts, record that decision. If someone later builds a second report and asks Claude the same question, they should get the same answer.

Keeping business rules in a shared record means every session—and every person on the team—starts from the same agreed facts. A definition that lives only in a conversation is invisible to the next person who needs it. Rules that persist between sessions catch the second person before they make a conflicting assumption, not after the numbers are already in front of the business.

The same principle applies to measures you have already built. If a measure named TotalRevenue already exists with a specific definition, mention it at the start of each session. If Claude writes a second measure with a different approach to the same calculation, the discrepancy can quietly multiply across the report. Starting from the known list of existing measures prevents duplicate logic from accumulating.

Record sign-off on metric definitions as a decision with the decider named and the date. If the definition changes later, the new decision supersedes the old one, and the reason for the change is visible. This is especially important for regulated industries where audit trails matter. The what is Claude AI guide covers more about how Claude handles context that persists across sessions.

What Claude cannot do with Power BI

Claude cannot connect to Power BI, see your actual data, or publish changes to a report. It works from descriptions you give it: table names, column names, sample rows if you paste them, and business rules you explain. If you ask it to "fix the report," it cannot—you have to describe the problem and apply the fix yourself.

Claude does not have access to the Microsoft Power BI documentation↗ (opens in a new tab) in real time. Its knowledge of Power BI features and DAX functions has a training cutoff. For features released recently, or for exact function syntax, verify against the DAX reference on Microsoft Learn↗ (opens in a new tab) rather than relying solely on Claude's output.

How to do this with fenbs

1. Create a free account and set up a project in fenbs for the Power BI work.
2. Add the approved metric definitions as Decisions and rules, with the data owner named as decider and the agreed wording recorded exactly.
3. Add open questions—edge cases, filter behaviors, or definitions pending sign-off—as tasks on the board with status "To Do" until a person closes them.
4. Connect Claude to fenbs from Integrations. At the start of each DAX session, ask Claude to read the project context, including Rules and open task list.
5. When a definition is approved or a question is resolved, update the fenbs record. The next session inherits the agreed state without re-explaining the history.

If the Power BI project involves a team, shared access to the fenbs board means every data analyst asks Claude from the same approved baseline. One analyst approving a metric definition in fenbs means the others do not have to track it down separately.