You reduce manual work on a glossary by not starting from a blank page. Most of what a first draft needs already exists in your metadata: table and column names, measure descriptions in Power BI, the logic behind each measure, and which reports people actually open. A tool can turn that into suggested terms and draft definitions. Your experts then review and approve, instead of writing every entry from scratch.
Why glossary projects stall
The usual assumption is that a glossary has to be written by hand, term by term, before it's useful. That's the reason most of them never get finished.
For example: a data team runs a kickoff workshop and leaves with a spreadsheet of candidate terms, one tab per department. Each term gets an owner and a deadline. Three months later the Finance tab is half done, Sales hasn't started, and the definitions that were written already describe last year's reports.
In practice, the people who know what a term means are the busiest people in the business. Asking them to write from scratch puts the glossary at the bottom of their list.
What you can draft from the metadata you already have
Your data platform and your reports already describe themselves. They just do it in technical language. That's raw material for a first draft.
- Names. Table, column and measure names give you the candidate terms. "Net Revenue" and "Order Count" are already a list.
- Existing descriptions. Measure descriptions in Power BI semantic models and comments on database tables are often partly filled in. Reuse them before writing anything new.
- Logic. The DAX behind a measure, or the SQL behind a view, shows how a number is calculated. It can be translated into a plain-language draft. Power BI Desktop now includes a Copilot option that drafts measure descriptions from the DAX.
- Lineage. Knowing which source and which transformation a field comes from helps you spot that two reports use different versions of "revenue".
- Usage. Which reports and fields people open most tells you where to start. A term nobody reads can wait.
Put together, these give a reviewer a draft entry with a suggested definition, a source and a list of reports where the term appears. Reviewing that takes far less effort than writing it.
What still needs a person
Metadata tells you how a number is calculated. It doesn't tell you what the business agreed it means. That's the part that needs people.
- Agreeing the meaning. When Finance and Sales use "revenue" differently, someone has to decide which is the official definition, or name both clearly.
- Naming an owner. One person per term who can approve a change. A tool can suggest who uses a term most, but it can't appoint anyone.
- Checking the draft. A plain-language explanation of DAX can be accurate and still miss the point, for example by describing a filter without saying why it's there.
- Saying what's out of scope. Exceptions, known gaps and "don't use this for" notes come from experience, not from metadata.
Do you need a semantic layer before you build a glossary?
No. A glossary is usually one of the first steps towards one.
A semantic layer isn't code. It's a business layer that links your concepts together: which KPI depends on which term, which reports and datasets use it, and who owns it. Think of it as the business brain behind your data.
A glossary gives that brain its first building blocks. Each agreed term is a concept. Once terms exist, you can link them to each other and to the reports and datasets where they appear. That's how a glossary grows into a semantic layer, step by step, without a separate project.
If you're on Power BI, the measures in your semantic models are a natural starting list for those first terms.
Three ways to build a glossary, compared
| Approach | Where the first draft comes from | Who does the work | When it starts helping readers | Stays current when data changes |
|---|---|---|---|---|
| Write it from scratch | Workshops and interviews | Experts write every term | Once enough terms are written | Only if someone updates it by hand |
| Map every concept and link up front | Long workshops that design the whole model at once | Experts and data architects together | Once the whole model is agreed | Only if someone maintains the links by hand |
| Start from crawled metadata with suggestions | Names, descriptions, logic and usage already in your tools | Experts review and approve drafts | From the first approved terms | New and changed items surface on each crawl |
None of these routes skips the semantic layer. In the third, each approved term and each confirmed link is already a step towards it.
A practical framework: Crawl, Suggest, Prioritise, Review, Refresh
- Crawl: connect the sources and reports you already have, so names, descriptions, logic and usage come in automatically.
- Suggest: turn that metadata into candidate terms and draft definitions, flagged as unapproved.
- Prioritise: start with the terms on your most-used reports, not the full list.
- Review: the named owner corrects and approves each draft, instead of writing it.
- Refresh: when a measure or field changes, its term comes back for review.
Where dScribe fits
dScribe starts building the glossary from the moment it crawls your metadata, and it reads metadata only, so your data stays where it is. Its smart suggestions help you define terms and KPIs, link them to the reports and datasets they appear in, spot duplicates and trace lineage. Your experts review and approve instead of writing from scratch. Defining KPIs still takes some judgement, but the suggestions take away much of the manual work. Those links are what turn a glossary into a semantic layer over time. When something changes in your sources or reports, the related terms come back for review, so the glossary stays fresh without a full rewrite.
In short
Nobody likes writing documentation, and a glossary that depends on it won't get finished. Start from what your metadata already says. Let people do the part only they can do: agree the meaning, name the owner and approve the draft. A glossary built that way gets used because it actually exists.
Frequently asked questions
Can AI write a business glossary for me?
It can write a first draft from your metadata, and that saves most of the typing. It can't decide what the business agreed a term means. Treat AI output as a suggestion that an owner approves.
What should a business glossary entry contain?
A term, a one-sentence definition in plain language, a named owner, and the reports or datasets where it's used. Synonyms and "don't confuse with" notes help when departments use different words for the same thing.
Which terms should a glossary start with?
The ones on the reports people open most, especially board and management reports. Usage data from your BI tool shows you which those are. Add the rest when someone asks.
What's the difference between a business glossary and a semantic layer?
A glossary defines your business terms one by one, in plain language. A semantic layer links those concepts together: which KPI uses which term, which reports and datasets rely on it, and who owns it. A glossary is often the first step towards a semantic layer, not an alternative to it.
How do I keep a glossary up to date without a full-time steward?
Tie each term to the data it describes, so a change in a measure or field sends the term back to its owner. Review on a fixed rhythm, for example every quarter, rather than in one big clean-up.