Catalogue version control is the system that ensures buyers, sales teams, websites and partners receive current, approved product information. It connects product master data, change decisions, document releases, distribution and retirement. File names such as final-final-new cannot provide that control.
This guide owns catalogue governance beneath GPTWala’s digital product catalogue strategy. It applies whether the business uses a PIM, ERP, shared drive, website, portal or carefully governed spreadsheet.
- Separate the records being controlled
- Name one source and functional owners
- Use a version and release-identification scheme
- Create a documented change-request path
- Run an impact assessment before approval
- Approve facts, then approve the release
- Publish one approved release and retire the old one
- Reconcile product data across channels
- Handle incorrect releases as an information incident
- Measure catalogue-control health
- Frequently asked questions
- Sources and further reading
Separate the records being controlled
A product record, asset, technical document, price list and catalogue release can change independently. Define each object and its source. A catalogue version should not create a new product revision merely because page order changed. A material product change may require updates to several outputs.
| Controlled object | Example change | Primary owner |
|---|---|---|
| Product master | Variant, dimension or lifecycle | Product data |
| Technical document | Specification or method | Engineering or quality |
| Commercial record | Price, MOQ or terms | Sales or finance |
| Digital asset | Image, drawing or rights | Marketing with product owner |
| Catalogue release | Selection, layout and approved content | Catalogue owner |
Map all outputs to the underlying item identity. GS1’s architecture treats master data as descriptive information associated with identifiers, which supports consistent downstream use.
Name one source and functional owners
Choose the canonical system for each field. If price comes from one system and technical data from another, document the ownership and synchronisation. The catalogue file is usually an output, not the authority for every fact.
Assign a catalogue owner who coordinates release but cannot unilaterally approve technical or commercial changes. Use a responsibility matrix that distinguishes request, evidence, approval, implementation and release.
| Field or action | Source or owner | Release responsibility |
|---|---|---|
| Identity and variant | Product master-data owner | Confirm mapped correctly |
| Specification or claim | Technical or quality owner | Confirm approved source |
| Price and terms | Commercial owner | Confirm audience and validity |
| Image and rights | Asset owner | Confirm current permission |
| File and web release | Catalogue or digital owner | Publish and retire versions |
Align customer-facing descriptions with the controlled product-copy workflow.
Use a version and release-identification scheme
Choose a readable release ID such as a sequential number or approved major-minor scheme. Define what increments it. Pair the ID with status, owner, approved point, market or audience, and change summary. Do not rely on the file’s modified timestamp.
Major and minor need local definitions
A major release might change product scope, commercial policy or buyer workflow. A minor release might correct approved text without changing buyer decisions. The labels are useful only when the business defines them.
| Release field | Purpose | Example value type |
|---|---|---|
| Catalogue ID | Identify the document family | B2B-CAT-CORE |
| Version | Identify the controlled release | Sequential or major-minor |
| Status | Prevent draft use | Draft, approved, retired |
| Audience | Limit distribution | Public, dealer or internal |
| Change summary | Explain material difference | Products, prices or correction |
| Owner | Route questions | Named role |
Create a documented change-request path
Every change should state affected product or section, current value, proposed value, reason, source evidence, urgency, channels and request owner. Classify the change as identity, technical, commercial, legal, asset, copy, layout or correction. This determines reviewers and impact.
| Change type | Required evidence | Impact check |
|---|---|---|
| Identity or variant | Approved product record | SKU, GTIN and channel mapping |
| Technical | Specification or controlled source | Claims, data sheets and quotations |
| Commercial | Approved price or policy | Audience, currency and effective point |
| Asset | Current file and rights | Crops, channels and old downloads |
| Correction | Verified error and cause | Where wrong value was distributed |
Use the fact-safe AI content method for wording changes. AI suggestions remain change proposals, not evidence.
Run an impact assessment before approval
Search every place the information appears: web product page, catalogue, line sheet, price list, quotation template, marketplace feed, sales presentation, chat catalogue, distributor portal, printed stock and partner file. Record whether the change is immediate, effective later or limited to new production.
| Channel | Impact question | Evidence after change |
|---|---|---|
| Website | Which pages and structured data use the field? | Live-page reconciliation |
| Feed or marketplace | Will validation or identifier mapping change? | Diagnostics pass |
| Sales documents | Which active files contain the value? | Reissued controlled link |
| CRM or quotation | Do templates or open opportunities need action? | Owner review |
| Partners and print | Who received the old version? | Notification or withdrawal record |
Follow the product-page SEO guide when URL or page ownership is affected. Do not change stable URLs merely to mirror catalogue version numbers.
Approve facts, then approve the release
Functional owners approve their information before the catalogue owner approves assembly and distribution. Use a pre-release comparison against the current approved version and the product master. Confirm tables, units, links, price basis, image mapping and buyer actions.
| Gate | Reviewer | Pass evidence |
|---|---|---|
| Data completeness | Product-data owner | Required fields and mappings valid |
| Technical accuracy | Technical or quality owner | Claims match approved source |
| Commercial accuracy | Sales or finance | Terms, price and audience current |
| Brand and accessibility | Marketing and digital owner | Readable, truthful and usable |
| Release integrity | Catalogue owner | Correct version, links and archive plan |
ISO’s public guidance on documented information highlights control of information maintained for operations and retained as evidence. Apply that principle proportionately rather than creating signatures with no meaningful review.
Publish one approved release and retire the old one
Use one canonical link or portal where possible. Replace the file behind a controlled route only when buyers can still identify the new version and older references remain understandable. Otherwise issue a new controlled link and redirect users from the old location with a clear retired notice.
Remove edit access from general users, restrict public folders and search for copies in shared locations. Watermarks can help distinguish draft from approved, but they do not replace access control. Microsoft describes version history as a way to view, compare and restore earlier file versions; use platform history as support, not as the release decision itself.
| Distribution control | Action | Evidence |
|---|---|---|
| Canonical link | Point users to approved version | Current release opens |
| Shared folders | Remove draft and duplicate links | Search passes |
| Email and chat | Send link, not attachment where possible | Recipients reach current file |
| Print stock | Withdraw or mark retired copies | Field confirmation |
| Partner portals | Replace and notify material changes | Partner acknowledgement where needed |
Reconcile product data across channels
After release, sample identities, variants, specifications, price, availability, images and documents across the catalogue, website and feeds. Google Merchant Center notes that incorrect or conflicting product data can create display and eligibility problems. Treat channel diagnostics and customer corrections as data-governance signals.
Keep the WhatsApp catalogue synchronised at the level it supports, but link technical buyers to controlled detail. Use automated feeds only when ownership, monitoring and rollback exist.
| Reconciliation field | Compare | Failure response |
|---|---|---|
| Identity | Master, catalogue, web and feed | Stop duplicate or mismatched listing |
| Variant | Allowed combinations and labels | Correct mapping |
| Price and availability | Commercial source and visible offer | Update or temporarily suppress |
| Image | Correct product and rights | Replace affected assets |
| Document | Current approved file | Retire stale download |
Handle incorrect releases as an information incident
If a released catalogue contains a material error, stop distribution, identify affected products and channels, assess customer or safety impact, publish a corrected controlled release and notify recipients proportionately. Preserve the erroneous version and cause record rather than deleting evidence.
| Incident step | Question | Owner |
|---|---|---|
| Contain | Where can the wrong value still be used? | Catalogue and channel owners |
| Assess | What decision or transaction may be affected? | Functional owner |
| Correct | What is the verified value and release? | Data and approvers |
| Notify | Who needs an explicit correction? | Sales or service owner |
| Prevent | Why did the control fail? | Process owner |
Do not silently edit a technical or commercial value after buyers may have relied on it. Link affected enquiries and quotations to the B2B sales workflow.
Measure catalogue-control health
Track time from approved change to channel completion, stale-copy findings, correction requests, failed mappings, unauthorised edits, broken links and version adoption. Separate copy changes from material product and commercial changes so teams can prioritise appropriately.
| Metric | What it reveals | Target behaviour |
|---|---|---|
| Change completion time | Release process friction | Risk-based, owned completion |
| Stale version findings | Distribution weakness | Declining and corrected quickly |
| Cross-channel mismatch | Integration or ownership gap | Reconciled to master |
| Correction recurrence | Root cause not fixed | Process improvement |
| Partner acknowledgement | Material change reached users | Traceable where needed |
Review the control after system migrations, catalogue redesigns, supplier changes, channel additions and incidents. Keep the system simple enough that sales uses it, but strict enough that the approved information remains dependable. Use the brand system to maintain consistent presentation without turning visual edits into uncontrolled product changes.
Frequently asked questions
What is catalogue version control?
It is the controlled process for requesting, approving, identifying, publishing, distributing, reconciling and retiring catalogue information and releases.
How do you number catalogue versions?
Use a defined sequential or major-minor scheme with a catalogue ID, status, audience, owner and change summary. Define exactly what each increment means.
Who should approve catalogue changes?
Product data, technical or quality, commercial, asset and digital owners approve fields within their authority, while one catalogue owner controls release.
How do you stop sales teams using an old catalogue?
Provide one canonical approved link, restrict edits, retire duplicates and attachments, withdraw print copies, notify material changes and verify active sales locations.
Should product prices be version controlled?
Yes. Control the price source, currency, unit, audience, effective point and validity, then reconcile every channel where it appears.
What is the difference between a catalogue version and product revision?
A catalogue version identifies a released sales document. A product revision represents a controlled change to the product or its technical definition. One may change without the other.