Business glossary process flowchart (proposal to published term)
Business glossary process template for proposing terms, drafting definitions, resolving duplicates, steward and owner approval, catalog publication, review, revision and retirement.
What the business glossary process flowchart (proposal to published term) process is
A business glossary becomes trustworthy when every definition has passed through the same visible decisions. This template begins with one proposed term and the context needed to understand why it matters. A metadata analyst searches the existing catalog before drafting, so likely duplicates are compared on meaning, usage and ownership instead of being published under a second spelling. Distinct terms receive a definition, aliases and exclusions; true duplicates are consolidated into one canonical proposal. The data steward then verifies the domain meaning, the data owner confirms accountability and business use, and the catalog administrator publishes the approved term with references and a change record. Feedback and a scheduled review complete the loop, giving the team explicit routes to retain, revise or retire the term rather than allowing stale definitions to remain authoritative by accident.
This is a term-governance workflow, not a project to inventory every field or rebuild a metadata platform. Technical schemas, lineage harvesting and access configuration can link to the published definition, but they remain separate operating processes. The data lifecycle at /templates/data-lifecycle-management-process uses classifications, owners and retention rules that a glossary can explain consistently; it does not replace the glossary's duplicate resolution or approval route. Likewise, /templates/ai-governance-process may consume approved terms for system purposes, outputs and affected groups, while keeping its own risk and review decisions. Draw those relationships as references rather than expanding this chart into an enterprise data model. Adapt the approval roles, review cadence and retirement rules to the domains and catalog practices your organization actually uses.
What this flowchart covers
In this template
- Five role lanes across six phases, from a requester's term proposal through metadata analysis, steward and owner approval, catalog publication, and scheduled maintenance
- An intake completeness gate and a catalog search before drafting, so examples, scope and source references travel with the request and existing language is considered first
- A meaningful duplicate-resolution branch that compares meaning, usage and ownership before choosing a distinct definition or one canonical merged term
- Separate steward endorsement and data-owner publication approval, with comments routed back into definition work instead of handled outside the visible process
- Publication with ownership and references, followed by feedback and a review decision that keeps, revises or retires the term while preserving its history
When to use this template
- Different teams use the same business word for different concepts, or different words for the same concept, and reports no longer agree
- A metadata catalog contains unowned draft definitions, duplicates or stale entries with no consistent route to publication or retirement
- Data stewards and owners need a clear division between checking domain meaning and accepting accountability for an approved term
- A catalog rollout or data-governance program needs a repeatable authoring workflow before inviting broad term submissions
How it works
Define the minimum proposal
List the context every requester must provide, such as the business question, examples, domain, source references and known synonyms. Keep the form short enough to use, but do not let a term reach drafting with only a name and no evidence of how people use it.
Set a duplicate-resolution rule
Agree how analysts compare candidate terms and who settles a disputed match. Include meaning, scope, usage, ownership and aliases; spelling similarity alone is not enough to decide whether two terms should merge.
Separate stewardship from ownership
Rename the lanes to your governance roles and state what each approval means. Steward endorsement should confirm a usable domain definition, while owner approval should confirm accountability, permitted use and readiness to publish.
Configure publication evidence
Choose which catalog fields are mandatory at publication: canonical name, definition, aliases, exclusions, owner, steward, linked data assets and effective date. Record revisions in the same place so users can see why a definition changed.
Choose review and retirement triggers
Set a cadence appropriate to each domain and add event triggers such as a source-system replacement, policy change or persistent user feedback. Define how deprecated terms redirect readers to a replacement without erasing historical references.
Frequently asked questions
What are the steps in a business glossary process?
A requester proposes one term with examples, scope and source context. A metadata analyst checks completeness and searches for related entries. Possible duplicates are compared by meaning, usage and ownership, then either kept distinct or merged into one canonical proposal. The definition, aliases and exclusions are drafted, a data steward verifies the domain meaning, and a data owner approves accountability and publication. A catalog administrator publishes the term with references and a change record. Feedback and scheduled review then lead to retention, revision or retirement.
Who should approve a business glossary definition?
Use roles that can answer different questions rather than adding ceremonial signatures. A data steward or subject-matter role should test whether the definition is accurate, distinct and usable within the domain. A data owner should confirm accountability and the business consequences of publishing it. A catalog administrator can then check metadata completeness and publish without becoming the authority on meaning. Smaller organizations may combine roles, but the two decisions should remain explicit.
How should duplicate glossary terms be handled?
First decide whether they describe the same concept. If they do, retain one canonical term, record the other wording as an alias, redirect references and preserve change history. If they differ in scope or meaning, keep both and write exclusions that make the boundary clear. Do not delete a duplicate before identifying reports, data products and policies that still use it, because an apparently clean catalog can leave those references unexplained.
How often should business glossary terms be reviewed?
There is no useful universal interval. Set a cadence based on how quickly the domain changes and supplement it with event-based reviews when systems, products, policies or reporting definitions change. High-use or disputed terms may need more frequent attention than stable reference concepts. Every published term should at least have an accountable owner, a next-review signal and a route for users to report ambiguity between scheduled reviews.