The Power BI Data Dictionary: Agreeing What Your Numbers Mean

Two people open the same report. One says revenue is up, the other says it is flat. They are looking at the same number on the same page and they still disagree, because one of them means revenue before refunds and the other means after. Nobody is wrong. Nobody agreed what the word meant in the first place.

I get this all the time. Is it revenue or sales, gross or net. What counts as an active customer, someone who logged in this month or someone who has ever paid. These are not technical questions, they are business questions, and until they are answered the same way by everyone, your reports will keep producing arguments instead of decisions. A data dictionary is where you settle them. Here is the thing though, a data dictionary is not a DAX trick or a tooling exercise. It is an agreement!

A note on scope before we go further. This blog is about why that agreement matters and how to get to it, not a deep tutorial on any one tool. The tooling is the easier part in my opinion, and I will come to the options near the end, but they are worth very little until the agreement underneath them exists.

Summary

A Power BI data dictionary is the agreed, documented meaning of every measure and calculation in your semantic model, written down so the whole organisation reads the same field the same way. It matters less as a piece of tooling and more as a governance act: without agreed definitions, the same measure gets read two ways, whether that is two analysts building different numbers from the same model or two directors disputing the figures in a meeting. The real work is agreeing what each measure means and giving it an owner, not generating a table of fields. Get that agreement first, then choose whichever capture method fits, from a simple spreadsheet up to an enterprise catalogue.

Key takeaways

• A data dictionary is an agreement on what your numbers mean, not a list of fields or a DAX technique.
• The definitions that matter sit at the model and measure level. Source-system documentation does not tell anyone how your measures are calculated.
• Without documented definitions, self-service users read the same measure differently and produce different numbers from the same model.
• Get definitions out of people early, in requirements and in workshops and give every important one (or collection) a named owner.
• Copilot makes this non-negotiable. If you cannot define your own measures, Copilot cannot either, and AI does not fix a vague model, it amplifies the consequences.

What a data dictionary actually is

When people hear "data dictionary" they often picture a long table listing every column in every table, with its data type and source. That kind of catalogue has its uses, but it is not the part that protects you. The dictionary that matters describes the agreed meaning of every measure and calculation: what "Net Revenue" includes and excludes, how "Active Customer" is defined, what rule sits behind "On-Time Delivery". Think what will help the business!

That distinction matters because the definitions live at the model level. Your source systems may carry their own documentation, and that is useful for understanding raw fields, but it will not tell you how your team chose to calculate a measure in the semantic model. That logic is yours, it is where the business meaning is created and it is exactly the part that tends to be undocumented. If you want the wider context on why the model is the centre of gravity, I cover it in Power BI Semantic Model and Why It Matters More in the Age of AI and Data Modelling in Power BI.

Definitions are where governance starts

Let me be clear about why this is a governance issue and not just good housekeeping. The moment you let people connect to a shared semantic model and build their own reports, you have handed them your measures. If those measures are not defined anywhere, every person fills the gap with their own assumption. One reads "Revenue" as gross, another as net, a third quietly builds their own version because they were not sure. Same model, same field, three different numbers in three different meetings. That is how trust in the platform erodes and it starts with a missing sentence, not a broken calculation.

This is also why a dictionary belongs before self-service, not after. If you are opening a model up to a wider group, the agreed definitions need to exist and be accessible to everyone first, so people are building on a shared understanding rather than guessing. It is the same sequencing point I made about the self-service deployment approaches: the foundation goes in before the flexibility, never the other way round.

Get the definitions out of people early

The hard part is not storing definitions. It is extracting them from the people who hold them, often without realising they disagree. This work belongs in requirements, right at the start, and it belongs in your workshops.

In workshops I run, the most valuable thing I do is slow people down. Someone asks for a report showing active customers, and the natural instinct is to nod and start building. The better move is to stop and ask, what do you actually mean by active. You will frequently find two people in the same room who have never noticed they define it differently. Five minutes of that conversation saves a fortnight of reconciliation later. It is not glamorous, and it is not quick, but it is where the dictionary is genuinely created, in the talking, before a single measure is written.

Give every definition an owner

A definition with no owner is a definition nobody will defend when it is questioned and it will be questioned. Now, before you panic, a model can carry hundreds of measures, and I am not suggesting hundreds of owners. Most of those measures are variants of a much smaller set of definitions, Revenue YTD and Revenue Growth are still just "Revenue", and ownership works best against a category or domain as I said earlier in the blog. Finance owns the revenue definitions, operations owns the delivery ones. What matters is that for every definition that gets argued over, there is a named person accountable for what it means and whether it is still right. Definitions are not set once and frozen, the business changes, and someone needs to own that. Ownership is what turns a list of agreed meanings into something that stays true over time.

Why Copilot makes this non-negotiable

Everything above was already true before AI. Copilot has simply raised the cost of skipping it. When you point Copilot or any LLM-driven experience at your semantic model, it answers using whatever your measures and metadata tell it. If a measure is well defined, Copilot can use it correctly. If it is ambiguous, Copilot does not pause to check, it answers confidently from an ambiguous model, and a confident wrong answer is far more dangerous than an obvious gap.

So the blunt version is this: if you cannot define your own measures, Copilot cannot either. AI does not fix a vague model, it amplifies the consequences of one. A clear, well-documented set of definitions is one of the foundations that decides whether Copilot is an asset or a liability. Getting a Copilot-ready data model in place is a lot of what makes the difference, and I have written more on the wider setup in Is Your Power BI Copilot Setup Business Ready.

How to actually capture it

Once the agreement exists, you need somewhere to keep it. There are several ways, and the right one depends on your size and maturity. Think of these as a progression in durability rather than a competition, because the value is created in the agreement, not the tool that holds it.

Start with a simple spreadsheet: a short, deliberate list of the definitions that actually matter or get argued over, each with its agreed meaning, the rule or logic behind it, and an owner. This is not a row for every field, it is the contested and important measures only. It needs no licence, no DAX and no Fabric, and it is the best place to begin because it forces the conversation without any tooling getting in the way. Plenty of organisations would be in far better shape if they simply did this and kept it current.

Move the definitions into the model: add descriptions to your measures and columns directly in the semantic model, so the definition lives with the thing it describes and surfaces as a tooltip. From there you can use a tool such as DAX Studio to query the model's metadata through its DMVs and pull those descriptions out into a document. This keeps the dictionary close to the model rather than off in a separate file.

Build a living dictionary page: the newer INFO.VIEW DAX functions read your model's metadata, including those descriptions, so you can build a documentation page that updates as the model changes. Microsoft Learn documents the functions in INFO functions (DAX).

Step up to an enterprise glossary: for larger estates, Microsoft Purview offers a business glossary and catalogue across the whole tenant. It is the heaviest of the options and a bigger commitment to run, so it tends to suit organisations that already have the governance maturity to maintain it. It is worth knowing as the enterprise route, even if most teams do not start there.

Whichever you choose, the point is the same. The spreadsheet is where the governance happens. Everything after it is just moving that agreement somewhere more durable and more connected.

How Metis BI helps

Agreeing definitions is fiddly, and most teams stall on it, not because it is technically hard, but because it means getting people in a room to commit to what a number means. That is a large part of what we do on a governance engagement. We run the conversations, pin down the definitions that matter, assign ownership, and set up a way to capture and maintain them that fits how you work. It helps two kinds of organisation in particular: those about to open up self-service who want the definitions agreed before people start building, and those who already have reports that disagree and need to find out why. If that sounds like you, our Power BI and Microsoft Fabric governance assessment is a good place to start.

A data dictionary is not a document you produce to tick a box. It is the organisation agreeing to speak the same language about its own numbers. Get that agreement, write it down, give it an owner, and your reports start ending arguments instead of starting them. Skip it, and no amount of clever tooling, Copilot included, will save you from three answers to the same question.

This blog is one of a series I have built from my Leeds Power BI User Group talk on Power BI governance. For the wider argument, start with Power BI Governance: The Foundations Matter More Than Ever, the overview of the talk, and it sits alongside the previous blog in the series, Designing a Power BI and Microsoft Fabric Framework: Workspaces, Apps and Audiences That Scale.