Incorrect webshop catalogue data can become part of an enquiry, a quote and an order. Control before publishing therefore starts not with reviewing page copy, but with defining the sales item: which data is mandatory, who provides expert sign-off, which exceptions may pass, and how to withdraw an already published error. Database constraints are useful structural controls, but business rules require a separate decision.
A catalogue is an input to the sales process. Customers use it to compare items, submit an enquiry or form expectations from a quote. If it shows an incorrect unit of measure, an inconsistent variant, outdated compatibility or an unavailable attribute, sales may carry the same data forward.
The risk is not merely an incorrect publication. The problem begins when four questions have no clear answer:
Webshop catalogue data control must therefore connect the catalogue, expert accountability and the sales process. A system can prevent some formal errors, but it cannot independently decide whether a description fits the product's actual use or whether an exception is commercially acceptable.
Marketing copy explains purpose and benefit. For example, it may describe a product as a solution for a specific work task. This content should be clear, but it must not replace a specification.
A measurable specification is data that can be checked against an agreed source. It may include an item code, manufacturer identifier, unit of measure, dimension, material, technical range, compatibility, pack size or delivery condition - where the data matters to a sales decision.
For every field, define:
Not every field is mandatory for every item type. However, each category needs a predefined minimum set. Sales item completeness is not the same as a high number of populated fields. An item is complete when it contains the data needed for correct identification, comparison and a sales decision within its category.
The input data owner is accountable for timely delivery and maintenance of data from an approved source. Procurement may own a supplier identifier, production a composition, or a technical team a technical specification. The role does not have to enter the data into the catalogue, but accountability for its content must be explicit.
The expert sign-off owner is accountable for the decision on whether data may be published for a particular purpose. This role matters where a description or compatibility may affect item selection. A marketing editor may shape the copy, but should not independently approve a technical claim without an assigned expert owner.
A practical split may look like this:
One person may hold several roles in a smaller organisation, but the responsibilities and decisions still need to remain visible in the process.
Publication does not have to be the only possible item status. Clear statuses reduce reliance on verbal checks and make work easier for sales.
A useful flow may include:
Define blocking rules for publication as well. For example, an item in a technical category cannot move to "ready to publish" without an identifier, sales unit, category, specification source and recorded expert sign-off. The specific attributes should arise from your offer and sales model.
Data constraints can check uniqueness, mandatory fields and relationships between records. PostgreSQL documentation describes constraints including NOT NULL , UNIQUE , primary and foreign keys, and value checks: PostgreSQL Constraints .
These controls have clear value. They can prevent a duplicate code, an empty mandatory value or a link to a non-existent category. Yet database structure alone does not define a business decision. Without separately defined rules, the system cannot determine:
Document business rules outside the technical constraint, then connect them to statuses, roles and evidence of approval. Only then does it make sense to automate some rules.
Assume a new item has a code, name, price and marketing description, but no confirmed compatibility. The catalogue team should not populate the field by assumption or publish a broad claim that may lead a customer to choose the wrong item.
The decision depends on a predefined category rule:
This is a hypothetical scenario. Its purpose is to show the order of decision-making, not to prescribe a universal field set.
An error found after publication requires a fast but controlled procedure. Do not first change only visible copy and then look for the cause. Preserve a decision trail and check where the data has already been used.
The procedure may include these steps:
Withdrawal has a cost: it temporarily reduces item visibility and adds operational work. The alternative is leaving unverified data available to customers. The decision should follow the actual impact of the error, rather than an informal assessment by one individual.
Use this checklist before introducing or changing the process.
If the catalogue, ERP and sales flow currently use different definitions of an item, the first step is not necessarily new technology. Business process screening can help map sources, decisions, handoffs and points where inaccurate data reaches a quote. The resulting rules then have a clearer foundation for daily work.