Skip to main content

• Intro
• Conversations
• Patterns
• Tips

Claude × Power BI

Five conversations that change how you work in Power BI

Most people use Claude like a search engine. Ask a question, get an answer, move on. That's the wrong model. Claude works best as a thinking partner — and once you learn to recognise which of five conversation types you need, everything gets faster.

Explain Build Debug Critique Strategize

Start here

Which conversation do you need right now?

Pick the scenario that matches where you are. We'll point you to the right conversation type — and jump you straight there.

"I keep seeing CALCULATE everywhere but I don't actually understand what it does."

→ Explain

"I need a rolling 13-week average that respects the slicer selection."

→ Build

"This measure worked in isolation but returns blank the moment I add a date filter."

→ Debug

"This report works, but my manager keeps saying it feels cluttered."

→ Critique

"My director wants a dashboard by Friday and I have no idea where to start."

→ Strategize

The framework

The Five Conversations

Every productive Claude interaction in Power BI fits one of these five types. Click each part of the example prompt to see why it's there.

Explain Build Debug Critique Strategize

Explain

When to use it

You're staring at a concept, a function, or a behaviour you don't fully understand. You want to get it — not just work around it.

You'll recognise this when you say

• "What does X actually do?"
• "I know it works, but I don't know why."
• "Can you explain filter context to me?"
• "What's the difference between CALCULATE and CALCULATETABLE?"

Prompt Workshop — click any underlined part Copy Explain what CALCULATE does in DAX, including how it modifies filter context . I'm comfortable with Excel SUMIF logic but new to DAX . Walk me through a concrete example using a Sales table with Date and Amount columns . End with a one-sentence rule of thumb I can remember. Goal: The specific concept you want explained. "Explain CALCULATE" beats "explain DAX" — narrow it down. Your context: Your knowledge level calibrates the vocabulary and analogies Claude uses. Always include it. Concrete example: Anchors the explanation in reality. Abstract explanations of DAX rarely stick. Output format: A rule of thumb, a one-liner, a mental model — asking for it improves retention. Goal Your context Concrete example Output format

Try these variants

Explain what CALCULATE does in DAX, including how it modifies filter context . I'm comfortable with Excel SUMIF logic but new to DAX . Walk me through a concrete example using a Sales table with Date and Amount columns . End with a one-sentence rule of thumb I can remember. '>CALCULATE Row vs Filter Context Relationships Star Schema

Build

When to use it

You need something written from scratch — a DAX measure, an M transformation, a calculated column, or a report layout. You know what it should do; you need the code.

You'll recognise this when you say

• "Write me a measure that..."
• "I need a Power Query step that..."
• "Give me the DAX for a 13-week rolling average."
• "How do I parameterise this M query?"

Prompt Workshop — click any underlined part Copy Write a DAX measure that calculates year-over-year revenue growth as a percentage . My fact table is 'Sales' with columns 'Revenue' (decimal) and 'OrderDate' (date). I have a Calendar table marked as the date table . Return BLANK when there is no prior year data — not zero . Add a short comment above each logical block explaining what it does. Goal: State exactly what the measure must calculate. "YoY revenue growth %" is specific. "A useful measure" is not. Table & column names: Claude will write syntactically valid DAX using invented names if you don't provide real ones. Always give exact names and data types. Edge cases: BLANK vs zero is one of the most common Power BI mistakes. Specify your expected behaviour upfront so Claude doesn't guess. Output format: Asking for inline comments turns the output into something you learn from — not just paste in and forget. Goal Table & column names Edge cases Output format

Try these variants

Write a DAX measure that calculates year-over-year revenue growth as a percentage . My fact table is 'Sales' with columns 'Revenue' (decimal) and 'OrderDate' (date). I have a Calendar table marked as the date table . Return BLANK when there is no prior year data — not zero . Add a short comment above each logical block explaining what it does. '>YoY Growth Rolling 13-Week M Function Scorecard Set

Debug

When to use it

You have code that is broken, or a visual that behaves unexpectedly. The quality of Claude's diagnosis depends entirely on how well you describe the problem — this is the most important conversation type to get right.

You'll recognise this when you say

• "This measure returns the wrong number."
• "Power Query throws an error I don't understand."
• "The visual shows X but I expect Y."
• "It works on some rows but not others."

Prompt Workshop — click any underlined part Copy This DAX measure returns total revenue for all time, ignoring my date slicer . Code: Revenue = CALCULATE(SUM(Sales[Revenue]), Sales[Channel]="Online") . I have a Calendar table marked as the date table, with a slicer on Calendar[Year]. The channel filter works but the year slicer is ignored . I expect it to show Online revenue for the selected year only . Explain why this is happening before you give me the fix. Symptom: Describe what you observe — not your theory. "Ignoring the slicer" is a symptom. "Wrong filter context" is already an interpretation; let Claude make that call. Code + model context: Paste the actual code every time. Also describe your relationships and table setup — DAX bugs are almost always model bugs in disguise. Expected vs actual: Claude needs both sides to diagnose correctly. "Wrong results" is not enough. Explain before fix: Asking for the explanation first means you learn something — and it helps you catch a wrong diagnosis before you act on it. Symptom Code + model Expected vs actual Explain before fix

Try these variants

This DAX measure returns total revenue for all time, ignoring my date slicer . Code: Revenue = CALCULATE(SUM(Sales[Revenue]), Sales[Channel]="Online") . I have a Calendar table marked as the date table, with a slicer on Calendar[Year]. The channel filter works but the year slicer is ignored . I expect it to show Online revenue for the selected year only . Explain why this is happening before you give me the fix. '>Slicer ignored Power Query error Wrong grand total Circular dependency

Critique

When to use it

Something is working — but you're not sure it's working well. You want a second opinion on the logic, performance, readability, or design. Nothing is broken; you just want better.

You'll recognise this when you say

• "This works — is there a better way?"
• "My measures are getting long and hard to read."
• "Does this report make sense for the audience?"
• "Is there a performance risk with this approach?"

Prompt Workshop — click any underlined part Copy Critique this DAX measure for readability and performance . Code: Net Margin % = DIVIDE(SUM(Sales[Revenue])-SUM(Sales[COGS]),SUM(Sales[Revenue]),0) . Used in a matrix with ~500K rows today, scaling to 5M . Be specific — show me the rewritten version, not just advice . Rate the current version 1–10 for each dimension before and after your changes. Critique dimension: Name what you want critiqued — readability, performance, business logic, or design. "General feedback" produces vague output. Scale & usage: A measure in a 10-row summary has different requirements than one in a 5M-row matrix. Always give Claude the scale context. Show, don't tell: "Show me the rewritten version" is more useful than "tell me what to change." Concrete output is always better. Before/after rating: Asking for a score forces specificity — and gives you a benchmark you can reason about. Critique dimension Scale & usage Show rewritten version Before/after rating

Try these variants

Critique this DAX measure for readability and performance . Code: Net Margin % = DIVIDE(SUM(Sales[Revenue])-SUM(Sales[COGS]),SUM(Sales[Revenue]),0) . Used in a matrix with ~500K rows today, scaling to 5M . Be specific — show me the rewritten version, not just advice . Rate the current version 1–10 for each dimension before and after your changes. '>Measure quality Report layout Model structure Calc cols vs measures

Strategize

When to use it

You have a goal but no clear path. A stakeholder request, a vague brief, or a dataset you don't know what to do with. The Strategize conversation helps you decide what to build before you build it — and saves you from rebuilding it three times.

You'll recognise this when you say

• "I have a dataset — where do I even start?"
• "My stakeholder wants 'a dashboard'. What does that mean?"
• "What measures should I build for this use case?"
• "Is this the right approach before I go further?"

Prompt Workshop — click any underlined part Copy Help me plan a Power BI report for regional sales managers to identify underperforming reps before monthly review . My data includes: Sales (rep name, region, product, date, revenue, units), Targets (rep name, month, revenue target), and HR (rep name, hire date, manager) . Managers are non-technical — they'll look at this for 5 minutes before a meeting . Give me: (1) the 4–5 key measures to build, (2) the recommended visuals and layout, (3) any model work I should tackle first. Business outcome: "Identify underperforming reps" is the business goal. "Build a sales dashboard" is a delivery format. Claude reasons much better from the former. Tables & columns: Claude cannot advise on what to build without knowing what data you have. A one-line table inventory is enough to unlock real recommendations. Audience & usage: Non-technical users, time pressure, meeting context — these change every recommendation. Include them every time. Structured plan: Ask for a checklist: measures, visuals, model work. Claude will default to narrative if you don't specify structure. Business outcome Tables & columns Audience & usage Structured plan

Try these variants

Help me plan a Power BI report for regional sales managers to identify underperforming reps before monthly review . My data includes: Sales (rep name, region, product, date, revenue, units), Targets (rep name, month, revenue target), and HR (rep name, hire date, manager) . Managers are non-technical — they'll look at this for 5 minutes before a meeting . Give me: (1) the 4–5 key measures to build, (2) the recommended visuals and layout, (3) any model work I should tackle first. '>Sales report New dataset Performance triage Excel migration

Ready to use

Prompt Patterns Library

Copy and adapt. Replace the italicised parts with your specifics.

Explain Copy

Explain [concept] in DAX/Power Query. I have experience with [your background]. Use a concrete example with a [table name] table. End with one rule of thumb I can remember.

Build — DAX Copy

Write a DAX measure that [what it calculates]. My fact table is '[TableName]' with columns '[Col1]' and '[Col2]'. Return BLANK (not zero) when [edge case]. Add comments explaining the logic.

Build — M Copy

Write a Power Query M transformation that [what it does]. My source table has these columns: [describe]. The output should [describe result]. Show me the M code and explain each step.

Debug Copy

This DAX/M code isn't working: [paste code]. I expected [expected result] but I'm getting [actual result]. My model: [brief description]. Explain what's causing this before you give me the fix.

Critique Copy

Critique this [measure/model/report] for [readability / performance / logic / design]: [paste or describe]. Show me the improved version — not just advice. Rate it 1–10 before and after.

Strategize Copy

I need a Power BI report for [audience] to help them [business goal]. My data: [list tables and key columns]. Audience is [technical level], using this [usage context]. Give me: key measures to build, recommended visuals, and model work to tackle first.

Getting more from Claude

Pro Tips

Common mistakes — and how to sidestep them.

Always paste the actual code — never describe it +

"I have a CALCULATE measure that uses a filter" tells Claude almost nothing. The actual measure tells it everything. Paste the full code every time — Claude reads it faster than you think you're saving time by summarising it.

This matters most for Debug and Critique conversations. If you describe the code instead of sharing it, Claude will guess at the problem rather than diagnose it.

Name your tables and columns — every time +

Claude will write syntactically valid DAX using invented table names if you don't provide real ones. The measure will look correct but won't load into your model. Always give the exact table name, exact column name, and data type when it's relevant.

A one-line model summary — My fact table is 'Orders' with: OrderDate (date), Revenue (decimal), CustomerID (int) — takes 20 seconds to write and saves 10 minutes of debugging.

Ask Claude to explain its reasoning — not just deliver the answer +

Adding "explain what this does line by line" or "tell me why you chose this approach over alternatives" turns every Build and Debug response into a learning opportunity. It also helps you catch mistakes — if the explanation doesn't match what you need, the code is probably wrong.

Use Add a comment above each logical block for DAX, or Explain why each step is needed for Power Query. This costs Claude approximately zero extra effort.

Tell Claude what you've already tried +

Claude will often suggest the exact thing you've already tried if you don't tell it. Adding "I've already tried REMOVEFILTERS and it didn't work" skips that suggestion and moves straight to alternative approaches.

In longer debug sessions, maintain a running list of what you've tried and paste it at the start of each new prompt. This keeps Claude from circling back to failed approaches.

One conversation type per session +

Mixing conversation types in a single session produces muddled responses. "Help me understand CALCULATE, then write me a measure, and also check my model" is three conversations. Separate them.

Start a new conversation for each type. Claude has no memory between sessions, so there's no accumulated context to lose — only accumulated noise to avoid.

Claude can reason about your model without seeing the .pbix +

Claude cannot open your .pbix file, but it can reason about your model if you describe it systematically. List your tables, their key columns, and the relationships between them — direction, cardinality, active or inactive. This often fits in a single paragraph.

Once Claude has this context, it can reason about filter propagation, flag model design issues, and identify potential ambiguities — without any file access.

An Interactive Scroll, by En Dash

Ready to work differently in Power BI?

The five conversations are a starting point. When you're ready to go deeper — on your specific model, your team's workflow, or your data strategy — we're here.

Use Claude to Build an Interactive Dashboard View full toolkit