The description field on your measure: four sentences that make your number explainable

Ilse manages customer service at a manufacturer of kitchen appliances and built the delivery dashboard herself. Just before a meeting, her account manager asks whether the 94.2 percent delivery reliability figure also counts the orders that are still in transit. She opens her own formula and does not find the answer there, even though she can read that formula just fine. Power BI fills in everything about a measure except its meaning, and there is exactly one place in the model where that meaning can live.

What a measure carries, and what it does not

A measure is more than the formula inside it. Power BI fills in three things automatically the moment you create one: a name that shows up in every visual, a formula that does the calculation, and a formatting rule that decides how the result displays. Every measure also gets a description field, and that field is the one of the four that Power BI leaves empty until someone types into it. What you put there travels with your model: a colleague sees it in the Data pane, and it sits in TMDL, the readable text format a PBIP folder stores your tables and measures in. As long as that field stays empty, the agreement behind a number is recorded nowhere, and anyone who wants that number explained has to track down whoever built it.

Ilse’s measure

Her model reads Delivery reliability % = DIVIDE ( [Orders on time], [Delivered orders] ), the function that returns BLANK instead of an error when the denominator is empty. Those two names in brackets are themselves counts inside the model. Over the quarter the denominator sits at 1,842 delivered orders and the numerator at 1,735, so the report shows 94.2 percent. The formula tells you exactly what it says: a share of delivered orders. What it stays silent on is which orders count as on time, and in Ilse’s count the 63 orders still in transit count as on time too. That agreement appears nowhere in the code.

When the counting date shifts

Change one thing: let [Orders on time] count against the date an order was actually delivered, instead of the date it was expected. The 63 orders still in transit drop out, leaving 1,672, and the same formula now shows 90.8 percent. The line of code has not changed, because it points at [Orders on time] and not at the agreement underneath it: does an order count the moment it is in transit, or only once it has actually arrived? Two outcomes, both defensible, and the entire difference sits in an agreement made outside the code.

What you write down tomorrow

The question that matters is not whether your formula is correct, but whether someone else could pull what your number counts out of this model in six months, without calling you. The description field records which of the two agreements applies in this model; which agreement is the right one stays a conversation between customer service and operations. Tomorrow, take the number your customer holds you accountable for and write down four things on that measure: what counts, which date counts, what the exception is, and who decides. Those four sentences still hold when a colleague runs into the number again in six months, and they travel along to a Data Agent that queries your model too, since it pulls field descriptions in as grounding for its answer.

Want to walk those four sentences through with your team for a report where this has already come up? I am happy to think it through with you, check trainerbjorn.nl.