A business glossary gets used when it answers a question at the moment someone has it, which is usually while reading a report. Start with the terms on the few reports leadership reads each week, not the whole business. Write each definition in one plain sentence, name one owner who can change it, and show it on the report itself. A glossary kept in a separate portal can easily go unopened.
At a glance
- Glossaries rarely fail for lack of terms. They fail because they live somewhere readers never go.
- Start with the terms people already argue about on the reports they read every week.
- Every term needs a plain definition, one named owner and a place on the report where it is used.
Why most business glossaries go unused
Most teams think a glossary fails because it is incomplete. So they add more terms. That alone does not solve the problem.
The real problem is location. The glossary sits in a portal, a wiki or a spreadsheet on SharePoint. The questions come up somewhere else: in a Power BI report, in a meeting, in an email thread about why two numbers differ.
For example, a regional manager sees “active customer” on a dashboard and wonders whether it includes customers on a paused contract. The answer exists in the glossary. She does not know where the glossary is, so she asks the BI team, who answer from memory.
In practice, people look things up where they already are. A glossary that is not there is easy for them to miss.
Which terms should go in the glossary first?
Not every term. Start with the ones that cause friction.
- Terms on the reports leadership reads every week. These are the numbers decisions are made on.
- Terms that mean different things to different teams. “Revenue”, “customer”, “order date” and “headcount” are common examples.
- Terms that new colleagues ask about. If the same question reaches the BI team every month, it belongs in the glossary.
Leave technical field names and rarely used terms for later. A short glossary that is accurate and visible beats a long one that nobody trusts.
How to write a definition a business user understands
Write for the person reading the report, not the person who built it. A useful definition has the same few parts every time.
- Name: the term exactly as it appears on reports.
- Definition: one plain sentence. No DAX, no SQL, no abbreviations.
- How it is counted: what is included and excluded, in words. For example, “Includes paused contracts. Excludes trial accounts.”
- Owner: one named person who can change the definition.
- Where it is used: the reports and datasets that show this term.
If two teams cannot agree on one definition, do not hide it. Create two clearly named terms, such as “Revenue (invoiced)” and “Revenue (booked)”, and make sure each report says which one it shows.
Who should own business glossary terms?
Assign one person per term, from the business, not the data team. Choose someone with the seniority and authority to decide what the term means and who will answer questions about it. A team or committee can contribute, but naming only a group makes individual responsibility unclear.
The data team's job is to keep the glossary running: collecting questions, drafting definitions and chasing reviews. The business owns the meaning.
Where should the glossary live?
| Approach | Who finds it | Effort to keep current | Seen while reading a report |
|---|---|---|---|
| Spreadsheet or wiki page | People who know it exists | Low at first, high later | Not by default |
| Power BI measure descriptions | Report builders | Per model, by its author | Only if surfaced through a report element configured for readers |
| A separate catalog portal | Whoever opens the portal | Shared by data stewards | Not by default |
| Definitions shown on the report | Readers of the report | Aim to maintain one source and reuse it across reports; implementation and review are still needed | Yes, where integrated into the report experience |
The right answer can be a mix. The source of truth can sit in one place, as long as readers see the definition where they read. Maintaining a definition once and reusing it across reports is a design aim, not a guarantee of instant propagation.
How do you handle definitions in Dutch, French and German?
In Belgium, Luxembourg and many Dutch companies, the same report is read in more than one language. The usual mistake is to create a separate term per language. Over time, the Dutch and French definitions of “active customer” can quietly drift apart.
Treat each language as a version of one term, not a separate term. Keep one owner and one meaning. Pick a reference language for writing and agreeing the definition, then have a native speaker in the business check each translation. When the definition changes, review every language version at the same time.
A practical framework: Choose, Write, Own, Show
- Choose: start with the terms on weekly leadership reports and the ones teams argue about.
- Write: one plain sentence per term, with what is included and excluded.
- Own: one named business person per term who can change it.
- Show: put the definition on the report where the term appears.
Put definitions where the questions arise
A glossary is not successful simply because the terms are written. The goal is for people to read them without being told to. Start with the terms people argue about, give each one an owner, and put the definition where the question comes up: on the report.
Frequently asked questions
How do I set up a business glossary that business users actually use?
Start small, with the terms on reports leadership reads every week. Write each definition in one plain sentence, name one business owner per term, and show the definition on the report where the term appears.
Which business glossary tool supports Dutch, French and German definitions?
When comparing glossary and catalog tools, verify support for Dutch, French and German definitions. Check whether language versions stay linked to one term with one owner, whether readers can see the version in their own language, and whether a definition change triggers a review of every version.
Why do business glossaries fail?
Often because they live in a portal or spreadsheet that readers do not open while they work. Missing owners is another reason: without an accountable owner, definitions go stale and people stop trusting them.
Who should own the terms in a business glossary?
One named person per term, from the business side, who can decide what the term means. The data team runs the process, but the business owns the meaning.
How many terms should a business glossary start with?
As few as it takes to cover the disputed numbers on your most-read reports. Expand once those definitions are agreed, visible and used.