Claude Prompts for Power BI

You are turning a pile of imported tables into a star schema. I will paste the inventory. <context>[PASTE EVERY TABLE NAME WITH ITS COLUMNS AND ROW COUNT]. Where the data comes from: [SOURCES]. Questions the report must answer: [QUESTIONS]. Grain I care about: [TRANSACTION / DAILY / MONTHLY].</context> <task>Propose the star schema: which tables become facts, which become dimensions, which should be merged, which should be dropped, and the key columns that join them.</task> <constraints>One fact grain per fact table. Conformed dimensions shared across facts. Flag any table that is really a fact pretending to be a dimension. Do not recommend a snowflake unless the cardinality genuinely forces it.</constraints> <format>A table of Table, Role, Keeps or merges into, Key column, Reason. Then the relationship list as From table, To table, Cardinality, Direction.</format>

You are reviewing an existing model for the relationship mistakes that produce wrong numbers. <context>[PASTE THE RELATIONSHIP LIST FROM MODEL VIEW: from table and column, to table and column, cardinality, cross filter direction, active or inactive]. Symptoms I see: [WRONG TOTALS / BLANK VALUES / DUPLICATED ROWS / AMBIGUOUS PATH ERRORS]. Measures affected: [NAMES].</context> <task>Identify which relationships are wrong or risky, explain what each one does to a measure, and give the corrected configuration.</task> <constraints>Call out many-to-many relationships, bidirectional filters, inactive relationships that a measure needs, and any circular path. Rank the fixes by how likely each is to change reported numbers.</constraints> <format>A ranked table of Relationship, Problem, Effect on numbers, Fix. Then any USERELATIONSHIP measure patterns needed after the change.</format>

You are generating a proper date dimension for my model. I will give you the calendar rules. <context>Date range needed: [START] to [END]. Fiscal year starts: [MONTH]. Weeks start on: [DAY]. Columns I need: [YEAR, QUARTER, MONTH NAME, MONTH NUMBER, FISCAL PERIOD, WEEK, DAY NAME, IS WEEKEND, IS CURRENT MONTH, RELATIVE OFFSETS]. Language and format: [LOCALE]. Preferred build method: [DAX CALCULATED TABLE / POWER QUERY M].</context> <task>Write the full date table in the method I chose, with sort-by columns for every text column that needs chronological ordering.</task> <constraints>Cover the whole range with no gaps. Include integer sort columns for month and day names. Add relative offset columns so slicers like last 3 months work without extra DAX.</constraints> <format>One code block with the complete table, then the exact steps to mark it as a date table and set the sort-by columns.</format>

You are eliminating bidirectional relationships that cause ambiguity and slow refreshes. I will paste the model. <context>[PASTE THE RELATIONSHIP LIST INCLUDING CROSS FILTER DIRECTION]. Why each bidirectional relationship was added, if I know: [REASONS]. Measures or slicers that depend on it: [LIST].</context> <task>For every bidirectional relationship, say what it was solving and replace it with a single-direction relationship plus a targeted measure pattern.</task> <constraints>Use CROSSFILTER inside the specific measure that needs the two-way behaviour, or TREATAS for the slicer cases. Warn me where a change will visibly alter an existing visual.</constraints> <format>A table of Relationship, What it enabled, Replacement pattern, Visuals to re-test. Then the DAX for each replacement measure.</format>

You are handling a dimension used several times in one fact table, such as dates with multiple roles. <context>Fact table and the columns that all point to the same dimension: [FACT TABLE, COLUMNS SUCH AS ORDER DATE, SHIP DATE, DUE DATE]. Dimension table: [NAME]. Which role should be the default in most visuals: [ROLE]. Reports that need each role: [LIST].</context> <task>Recommend the approach: inactive relationships activated by measure, duplicated dimension tables, or a mix. Then give the setup and the measures.</task> <constraints>State the trade-off in model size and user confusion for each option. Name the relationships that stay active. Provide USERELATIONSHIP measure patterns for the inactive ones.</constraints> <format>Recommendation with reasoning, the relationship configuration table, then the DAX for the role-specific measures.</format>

You are auditing which calculated columns should be measures, moved into Power Query, or deleted. <context>[PASTE EVERY CALCULATED COLUMN WITH ITS DAX AND ITS TABLE]. Table row counts: [COUNTS]. Which columns are used in visuals, slicers or relationships: [USAGE, IF KNOWN]. Model file size: [MB].</context> <task>For each calculated column decide: keep as a column, convert to a measure, push into Power Query, or delete. Justify each call in one line.</task> <constraints>Columns that only ever get aggregated should be measures. Anything that could be computed at the source belongs in Power Query. Never convert a column used in a relationship or a slicer without saying what breaks.</constraints> <format>A table of Column, Verdict, Reason, Replacement code. Then a suggested order of change from safest to riskiest.</format>

You are shrinking a model that has grown too large to refresh comfortably. I will paste the statistics. <context>[PASTE COLUMN SIZES AND CARDINALITY, FROM VERTIPAQ ANALYZER OR YOUR OWN NOTES]. Total model size: [MB]. Refresh duration: [MINUTES]. Columns nobody uses, if known: [LIST]. Grain and history I actually need: [PERIOD].</context> <task>Produce a reduction plan ranked by megabytes saved per unit of effort, covering column removal, cardinality reduction, grain changes and history limits.</task> <constraints>Call out datetime columns that should be split into date and time, GUID and free-text keys, and any column kept only for a tooltip. Say which changes break existing visuals or measures.</constraints> <format>A ranked table of Change, Estimated saving, Effort, What breaks. Then the Power Query or DAX steps for the top three.</format>

You are laying out a report page around the decisions it supports. I will describe the audience and the data. <context>Audience and their seniority: [WHO]. The three questions they open this report to answer: [QUESTIONS]. The decision that follows: [DECISION]. Measures available: [LIST]. Dimensions available for slicing: [LIST]. Screen it is viewed on: [DESKTOP / MOBILE / EMBEDDED / PRINTED].</context> <task>Wireframe the page in words: what sits in the top band, what fills the middle, what belongs in a drillthrough rather than on the page, and which slicers earn their space.</task> <constraints>Maximum six visuals on the page. Every visual must answer one of the stated questions or be cut. Reading order runs top left to bottom right. Say what you removed and why.</constraints> <format>A grid description with position, visual type, fields and the question it answers. Then a Cut list and a Drillthrough page list.</format>

You are choosing the right visual for each question on my page. I will list the questions and the data shape. <context>For each question: [QUESTION], measure [MEASURE], dimension and its distinct count [DIMENSION, CARDINALITY], time element [YES / NO], comparison needed [VS TARGET / VS PRIOR PERIOD / VS PEERS / NONE]. Audience data literacy: [HIGH / MIXED / LOW].</context> <task>Recommend a visual type per question, name the fields that go on each axis or field well, and give the one alternative worth testing.</task> <constraints>No pie charts above five categories. No dual axis unless the units genuinely differ and you say how to label it. Reject any request for a visual that will mislead, and explain what it would hide.</constraints> <format>A table of Question, Visual, Field wells, Alternative, Why not the obvious choice.</format>

You are specifying the KPI cards that sit at the top of the report so each one carries its own context. <context>Candidate KPIs: [LIST WITH THEIR MEASURES]. Targets and where they come from: [TARGETS]. Comparison period: [PRIOR MONTH / PRIOR YEAR / BUDGET]. What counts as good, watch and bad for each: [THRESHOLDS]. Audience: [WHO].</context> <task>Cut the list to the five that drive decisions, and for each specify the value, the comparison, the trend element, the conditional formatting rule and the exact label wording.</task> <constraints>Every card shows a comparison, never a naked number. Thresholds must come from my input, not invented. Colour must never be the only signal, pair it with an arrow or a word.</constraints> <format>A spec table of KPI, Measure, Comparison, Trend, Format rule, Label text. Then the KPIs you cut and why.</format>

You are writing a formatting standard for my reports so they are readable and accessible. <context>Brand colours with hex codes: [HEX LIST]. Report types in scope: [OPERATIONAL / EXECUTIVE / FINANCIAL]. Where they are consumed: [SCREEN / PROJECTOR / PRINTED / MOBILE]. Known constraints: [COLOUR BLIND USERS, DARK MODE, LOCALE, CURRENCY].</context> <task>Produce the standard: a categorical palette, a sequential palette, semantic colours for good and bad, plus number formatting, date formatting and font size rules by element.</task> <constraints>Check contrast against WCAG AA for text on each background and give the ratio. Never rely on red and green alone. Cap the categorical palette at eight colours and say what to do beyond that.</constraints> <format>Hex tables per palette with contrast ratios, a formatting rules table by element, then the alt-text pattern to write on each visual.</format>

You are designing the navigation layer so users get detail without a wall of visuals on the front page. <context>Pages that exist today: [LIST WITH PURPOSE]. Detail users keep asking for: [REQUESTS]. Fields that would make sensible drillthrough filters: [FIELDS]. Views the same audience toggles between: [VIEWS SUCH AS CHART VS TABLE, THIS YEAR VS LAST].</context> <task>Plan the drillthrough pages with their filter fields, and the bookmarks with what each one captures, plus the buttons and labels that trigger them.</task> <constraints>Every drillthrough page names its entry point and keeps a back button. Bookmarks must state whether they capture data, display or current page, since capturing everything is the usual cause of surprise behaviour.</constraints> <format>A table of Drillthrough page, Filter fields, Entry visual. A second table of Bookmark, What it captures, Button label. Then a test list.</format>

You are rewriting an analyst report for an executive audience without losing rigour. I will paste what exists. <context>[PASTE THE CURRENT PAGE INVENTORY: page names, visuals, fields, any text boxes]. Current audience: [WHO]. New audience and their seniority: [WHO]. Time they will spend on it: [SECONDS OR MINUTES]. The decision they own: [DECISION].</context> <task>Restructure it: what appears on the single page they will actually look at, what moves to an appendix page, what gets deleted, and what written summary sits at the top.</task> <constraints>One page must answer the decision on its own. No visual survives without a stated purpose. Detail is not deleted, it is relocated and linked.</constraints> <format>A page-by-page plan of Keep, Move, Delete with reasons, then the draft text for the summary box at the top of the main page.</format>

You are writing the explanatory text that stops users misreading the report. I will paste the visuals and their definitions. <context>[PASTE EACH VISUAL WITH ITS MEASURES AND FILTERS]. Known misreadings from users: [WHAT PEOPLE GET WRONG]. Data caveats: [LATE-ARRIVING DATA, EXCLUSIONS, ESTIMATES, REFRESH TIME]. Audience: [WHO].</context> <task>Write the tooltip text for each visual, a one-line caveat where the data has a limitation, and the report-level note explaining refresh timing and source.</task> <constraints>Tooltips under 20 words. State the measure definition in business terms, not DAX. Every exclusion the user cannot see from the visual must be named.</constraints> <format>A table of Visual, Tooltip text, Caveat line. Then the report footer note in full.</format>

You are writing a Power Query script to clean an ugly export. I will paste a sample of the file. <context>[PASTE THE FIRST 20 ROWS EXACTLY AS THEY APPEAR, INCLUDING THE JUNK ROWS AND HEADERS]. Source type: [CSV / EXCEL / SHAREPOINT / DATABASE]. How the file changes each month: [NEW COLUMNS, SHIFTING HEADER ROW, EXTRA TOTALS ROW]. Target shape I need: [COLUMNS AND TYPES].</context> <task>Write the complete M query that gets from this file to the target shape, and make it survive next month's version of the file.</task> <constraints>Do not hard-code row numbers where a condition can find the row instead. Set explicit data types at the end. Handle the totals row and any merged header. Comment each step in one short line.</constraints> <format>One M code block ready for the Advanced Editor, then a list of what will break if the source changes and how to spot it.</format>

You are converting a wide, human-formatted sheet into a tidy table Power BI can model. <context>[PASTE THE HEADER ROWS AND THREE SAMPLE DATA ROWS]. What the repeating columns represent: [MONTHS, SITES, PRODUCTS]. Columns that must stay as identifiers: [LIST]. Are the headers multi-row or merged: [YES / NO]. New columns are added: [MONTHLY / QUARTERLY / NEVER].</context> <task>Write the M that promotes the right header, unpivots only the repeating columns, splits any combined header into separate fields, and types the result.</task> <constraints>Use unpivot other columns rather than naming every repeating column, so new periods are handled automatically. Preserve nulls rather than converting them to zero unless I say otherwise.</constraints> <format>The M code block, then a before and after row count sanity check I can run to confirm nothing was lost.</format>

You are debugging a Power Query step that has started failing. I will paste the code and the error. <context>[PASTE THE FULL M FROM THE ADVANCED EDITOR]. [PASTE THE EXACT ERROR MESSAGE AND THE STEP NAME IT POINTS TO]. What changed recently: [SOURCE CHANGE, RENAME, NEW VALUES, PERMISSIONS]. Does it fail in Desktop, in the service, or both: [WHERE].</context> <task>Explain what the error actually means, identify which step introduced the assumption that broke, and rewrite that step to be resilient.</task> <constraints>Check for renamed columns, a changed header row, type conversion on unexpected values, and privacy level or gateway issues when it only fails in the service. Do not rewrite steps that are fine.</constraints> <format>Plain explanation of the error, the corrected step in a code block, then two lines on how to make the query fail loudly next time instead of silently dropping rows.</format>

You are deciding how to combine several sources correctly. I will describe each one. <context>For each source: [NAME, GRAIN, KEY COLUMNS, ROW COUNT, HOW OFTEN IT REFRESHES]. What I am trying to produce: [TARGET TABLE AND GRAIN]. Known key quality problems: [DUPLICATES, CASE MISMATCH, TRAILING SPACES, MISSING KEYS].</context> <task>Decide append versus merge for each pairing, choose the join type, and write the M including the key cleaning that has to happen before the join.</task> <constraints>Warn where a merge will multiply rows because the key is not unique. Clean and trim keys before joining, never after. State the expected row count after each operation.</constraints> <format>A decision table of Sources, Operation, Join type, Expected rows, Risk. Then the M code, then the row count checks to run.</format>

You are writing a custom column in M for logic that is easier upstream than in DAX. <context>Table and the columns available with their types: [COLUMNS AND TYPES]. The rule in plain English: [RULE, INCLUDING EVERY EDGE CASE]. What should happen with nulls: [BEHAVIOUR]. What should happen with unexpected values: [BEHAVIOUR]. Sample inputs and their correct outputs: [EXAMPLES].</context> <task>Write the custom column M expression, handle the null and unexpected cases explicitly, and set the resulting data type.</task> <constraints>M is case sensitive, so match my column names exactly. Prefer a readable if then else chain over a clever one-liner. Never let an unexpected value produce a silent null.</constraints> <format>The expression in a code block, the full step to paste into the Advanced Editor, and a short table showing the output for each of my sample inputs.</format>

You are reviewing my query for folding so the source database does the work instead of my laptop. <context>[PASTE THE FULL M]. Source: [SQL SERVER / SYNAPSE / ORACLE / ODBC / FILE]. Row count at the source: [ROWS]. Refresh duration now: [MINUTES]. Steps where View Native Query is greyed out: [STEP NAMES, IF I CHECKED].</context> <task>Identify the first step that stops folding, explain why it breaks it, and reorder or rewrite the query so filtering and grouping fold back to the source.</task> <constraints>Filter rows and remove columns as early as possible. Flag custom columns, index columns and Table.Buffer as folding breakers. Say honestly when a step cannot fold and must stay client-side.</constraints> <format>A step-by-step folding verdict, the reordered M in a code block, and how to verify folding with right-click, View Native Query.</format>

You are making my queries portable so the file path or environment is not hard-coded in twenty places. <context>[PASTE THE SOURCE STEPS FROM EACH QUERY THAT CONTAINS A PATH, SERVER OR DATE]. Environments in play: [DEV / TEST / PROD PATHS OR SERVERS]. Who else opens this file: [PEOPLE AND THEIR SETUP]. Published to the service with a gateway: [YES / NO].</context> <task>Define the parameters to create, rewrite each source step to use them, and explain how the values are switched in Desktop and in the service.</task> <constraints>One parameter per genuinely varying value, no more. Give each a sensible default and a data type. Note which parameters can be edited in dataset settings after publishing.</constraints> <format>A parameter table of Name, Type, Default, Used by. Then the rewritten source lines, then the switch instructions for Desktop and the service.</format>

You are writing the commentary for a report from its underlying numbers. I will paste the data behind the visuals. <context>[PASTE THE EXPORTED DATA FROM EACH VISUAL AS CSV OR A PASTED TABLE]. Reporting period: [PERIOD]. Targets or budget for each measure: [TARGETS]. Audience: [WHO]. What they will do with this: [DECISION].</context> <task>Write the narrative: the three things that actually moved, what each is worth in absolute and percentage terms, the most plausible driver of each, and what to watch next period.</task> <constraints>Never state a cause the data cannot support, label plausible drivers as hypotheses to test. Round consistently. Skip any metric that moved less than the normal variation.</constraints> <format>A three-line headline summary, then a bullet per movement with the number and the hypothesis, then Watch next period.</format>

You are decomposing a metric movement so the explanation survives questioning. I will paste the breakdowns. <context>Metric and its movement: [METRIC, FROM VALUE TO VALUE, PERIOD]. [PASTE THE SAME METRIC SPLIT BY EACH DIMENSION: REGION, PRODUCT, CHANNEL, SEGMENT, EACH WITH BOTH PERIODS]. Known events in the period: [PRICE CHANGE, OUTAGE, CAMPAIGN, SEASONALITY, DATA ISSUE].</context> <task>Attribute the movement across dimensions, quantify how much each slice contributed, separate mix effects from rate effects, and rank the candidate explanations.</task> <constraints>Contributions must roughly reconcile to the total movement, say so if they do not. Distinguish a genuine decline from a mix shift. Name the data-quality checks to run before anyone presents this.</constraints> <format>A contribution table by slice with absolute and percentage share, a ranked explanation list, then a Check before presenting list.</format>

You are compressing a full report into one page an executive can read in ninety seconds. I will paste the numbers. <context>[PASTE THE KEY MEASURES WITH CURRENT, PRIOR AND TARGET VALUES]. Period: [PERIOD]. Audience and what they are accountable for: [WHO, THEIR METRIC]. Decisions they need to make this month: [DECISIONS]. What is already known to them: [CONTEXT TO SKIP].</context> <task>Write the one-pager: the headline verdict, four numbers that matter with their comparisons, what changed and why, the risks, and the decisions requested with a recommendation for each.</task> <constraints>Under 350 words. Lead with the verdict, not the method. Every decision requested has a recommendation and a deadline. No metric appears without a comparison.</constraints> <format>Headline verdict in one sentence, a four-row number table, Why it moved, Risks, then Decisions requested with owner and date.</format>

You are scanning a data extract for anomalies worth investigating before a report goes out. <context>[PASTE THE DATA AS CSV: DIMENSIONS, MEASURES, ONE ROW PER PERIOD OR ENTITY]. What normal variation looks like: [TYPICAL RANGE OR PERCENTAGE]. Known seasonality: [PATTERNS]. Recent changes to sources or logic: [CHANGES].</context> <task>Shortlist the anomalies, separating likely data-quality problems from genuine business movements, and rank them by how much they would embarrass us if presented uncorrected.</task> <constraints>Flag duplicated rows, sudden zeroes, missing periods, sign flips and impossible values as data quality first. Only call something a business movement once the data explanations are ruled out. Show the rows you are reacting to.</constraints> <format>A ranked table of Anomaly, Rows affected, Data issue or business movement, Check to run, Who to ask.</format>

You are preparing me for the questions this report will trigger. I will paste what I am presenting. <context>[PASTE THE NUMBERS AND THE COMMENTARY I PLAN TO SHOW]. Audience and their known positions: [WHO, WHAT THEY BELIEVE OR WANT]. Weak spots I already know about: [WEAKNESSES]. Data caveats: [EXCLUSIONS, ESTIMATES, LATE DATA].</context> <task>Predict the fifteen questions most likely to be asked, ranked by probability, and draft a short honest answer for each including the ones where the answer is that we do not know yet.</task> <constraints>Include the hostile questions and the definitional ones, such as how a metric is calculated and why it differs from another team's number. No defensive answers, no answers that promise analysis I did not agree to.</constraints> <format>A ranked list of Question, Answer in under 40 words, and a flag on the ones needing a follow-up commitment.</format>

You are documenting what each measure in my model actually means so two teams stop reporting different numbers. <context>[PASTE EACH MEASURE NAME WITH ITS DAX]. Source tables and their grain: [TABLES]. Known filters or exclusions built into the model: [EXCLUSIONS]. Where the same metric is calculated elsewhere: [OTHER SYSTEMS OR REPORTS].</context> <task>Write a business-readable definition for each measure: what it counts, what it excludes, the grain, the refresh cadence, and where it may legitimately differ from another system.</task> <constraints>Translate the DAX into business language without dropping the exclusions, since the exclusions are what cause disputes. Flag any measure whose name implies something different from what it computes.</constraints> <format>A dictionary table of Measure, Plain definition, Includes, Excludes, Grain, Known differences. Then a rename list for the misleading names.</format>

You are turning this month's report into the script for the review meeting. I will paste the numbers and the agenda. <context>[PASTE THE MONTHLY NUMBERS WITH PRIOR PERIOD AND TARGET]. Meeting length: [MINUTES]. Attendees and their roles: [NAMES AND ROLES]. Decisions that must come out of it: [DECISIONS]. Topics that always eat the clock: [TIME SINKS].</context> <task>Write the walkthrough: what to say per slide or page, in what order, with the timebox for each and the exact question that closes each section.</task> <constraints>Timeboxes add up to the meeting length with five minutes spare. Every section ends in a question that forces a decision or an owner. Park the known time sinks explicitly rather than hoping they do not come up.</constraints> <format>A timeboxed running order with the talking points and the closing question per section, then a Parked topics list with who follows up.</format>