/querying-fabric

name: querying-fabric
description: >
  Query Microsoft Fabric and Power BI semantic models with DAX (and Fabric SQL endpoints with T-SQL) to feed a
  Claude Dashboard or any dashboard built from a Fabric connector or MCP server. Use this skill whenever you
  build, extend or debug a dashboard, KPI card, chart or table on top of a semantic model, call a tool like
  run_dax_query, get_model_schema or list_models, or the user asks for numbers "from Fabric", "from the model"
  or "from Power BI", even if they never say DAX. Covers reusing the model's measures instead of writing new
  ones, KPI design with a target and a trend, crossfiltering between visuals, DAX query syntax and time
  intelligence, and an execute-inspect-fix test loop.

Querying Fabric for Claude Dashboards

A dashboard is only as trustworthy as its queries. The semantic model already holds the business's agreed definitions of its metrics: the measures. A dashboard that reuses them shows the same numbers as every Power BI report on that model; a dashboard that recomputes them shows numbers that look right and quietly disagree. So the work here is mostly finding the right measures and slicing them well, not writing DAX formulas.

Three rules shape every dashboard this skill builds:

reuse measures:  every number comes from an existing model measure; no new measure logic in the queries
kpi contract:    every KPI shows its value, a target, and a trend
crossfiltering:  selecting a mark in one visual filters every other visual

Workflow

1. **Find the model.** `list_models` or `find_items` (type `SemanticModel`); `resolve_item` for a URL. Confirm the model with the user when several look alike (dev, test and prod copies are common). 2. **Read the schema before writing any query.** `get_model_schema` with part `Measures`, then `Columns` and `Relationships` for the tables you will slice by. Read measure descriptions, display folders, format strings and expressions. See [Reusing the model's measures](#reusing-the-models-measures). 3. **Answer one business question.** Pick the measures that answer it, the target each KPI is judged against, the date grain of its trend, and the dimensions the user will click to crossfilter. 4. **Write one query per visual grain.** One `EVALUATE` per visual; see [references/dax-query-patterns.md](./references/dax-query-patterns.md). 5. **Test every query** with `run_dax_query` before the dashboard uses it. See [Testing](#testing-and-iteration). 6. **Wire crossfiltering** through query parameters; see [references/crossfiltering.md](./references/crossfiltering.md). 7. **Check the numbers against a known total.** Compare one KPI against the same measure with no filters, or against a figure the user already trusts from a report. A dashboard that is wrong by a filter is worse than no dashboard.

Reusing the model's measures

Measures are the governed definitions. Use them by name, `[Measure]`, and let the dashboard decide only *how the measure is sliced*: which columns group it, which filters apply, which period it covers.

do:
  - reference model measures directly: "Turnover", [Turnover]
  - prefer an existing variant over deriving one: use [Turnover 1YP] or [Budget YTD] when the model has them
  - shift or filter an existing measure when no variant exists: CALCULATE([Turnover], DATEADD('Date'[Date], -1, YEAR))
  - keep the model's format strings (FormatString or FormatStringDefinition in the schema) for display
avoid:
  - re-aggregating raw columns when a measure exists: SUM('Sales'[Amount]) next to an existing [Total Sales]
  - DEFINE MEASURE blocks that re-implement business logic (margins, rates, OTD %, conversions)
  - ratios computed in the dashboard from two measures when the model has the ratio measure
  - averaging or summing a ratio measure client-side; ask the model for the ratio at the grain you need

Why this matters: a model's `[Turnover]` may add surcharges, subtract fees and convert currency; a `SUM('Invoices'[Net Value])` returns a plausible figure that matches no report. Users notice when two tools disagree, and they stop trusting both.

When the question needs a metric the model does not have:

1. Say so plainly, and name the closest existing measures. 2. Suggest adding the measure to the model, where the model owner can review it and every report can share it. 3. Only if the user wants it in the dashboard anyway, compute it from existing measures (never from raw columns when a measure covers them), and label it in the dashboard as a dashboard-only calculation.

Measures that need a selection

Many enterprise models have measures that return BLANK unless a slicer table has one value selected: a reporting currency, a value unit, a selected metric or period. Their expressions start with `HASONEVALUE`, `SELECTEDVALUE` or `IF.EAGER(HASONEVALUE(...))`, and good models say so in the description. A dashboard that ignores this shows empty cards. Worse, a measure that reads `MAX ( 'Exchange Rate'[Rate] )` or sums across a currency table returns a number with no selection, just the wrong one: several times too high, with nothing to say so.

• Read the expression and description of every measure you use, and look for disconnected tables (tables with

no relationships, often named like `Selected Unit`, `Exchange Rate`, `Selected Period`)

• Pass the selection as a filter, e.g. `TREATAS({"EUR"}, 'Exchange Rate'[Currency])`, and show that choice

in the dashboard (a currency switch, or a label stating the currency)

• Ask the user which default to use when the model does not document one

When expressions are hidden

`get_model_schema` returns empty expressions when the user may not read them. Rely on names, descriptions, display folders and format strings, and test the measure at a known grain before relying on it.

The KPI contract: value, target, trend

A number on its own does not tell anyone whether to act. Every KPI in th