A product family helps people browse, while a stock identifier identifies something that can be counted or ordered. Treating both as one record can create ambiguous inventory and difficult integrations. Model the distinction before uploading a catalog.
Related service: CRM, ERP and web application development- 01Define shared product information.
- 02Choose the variant dimensions.
- 03Assign stable item identifiers.
- 04Map external codes without replacing identity.
- 05Test orders and stock against actual variants.
SECTION 01
Choose which differences create a separate item
Size and color may create sellable variants, while marketing copy may be shared. Other differences, such as packaging, can affect units or separate item identity depending on how the business buys and sells. List the actual operational distinctions rather than copying every product attribute into a variant matrix.
Use stable internal references even when supplier codes or display names change. Database constraints can prevent invalid links and duplicate keys. Microsoft's relationship guidance provides examples of parent and related records, but the model should fit your product operation rather than a named platform. Avoid deleting an old variant merely because it is no longer offered; historical orders still need an intelligible reference.
SECTION 02
Illustrative example: one family with limited combinations
Imagine a workwear range with three sizes and two colors, but the largest size is available in only one color. Generating every possible combination would create a nonexistent item. This is a hypothetical product-modeling scenario.
The catalog keeps shared care instructions at family level and permits only real sellable combinations. Each valid variant has its own stock identity and supplier mapping. If a supplier changes its code, existing stock movements retain their item reference. A channel listing can change without rewriting the identity used by the purchasing and fulfillment records.
SECTION 03
Reconcile one product family end to end
Start with a representative family containing at least one exception. Existing product-information or inventory tools may already support the required structure. Build a custom master only where ownership, validation or cross-system mapping cannot be maintained through the current tools.
Ask the agency to demonstrate an invalid combination, renamed item, retired variant, changed supplier code and a repeated catalog import. Follow one order from the displayed choice to the actual stock item. Exports should include explicit identifiers and units, not only readable names. Agree which team owns descriptions, item setup and availability so a content update cannot accidentally create or remove inventory.
SECTION 04
Frequently asked questions
Is every attribute a variant dimension?
No. Use variant dimensions for differences that identify a distinct sellable or countable item. Shared descriptive information can remain on the family.
Can SKU be changed later?
Plan changes carefully and preserve stable internal identity and external mappings. Historical orders and integrations may still refer to earlier codes.
Should inactive variants be deleted?
Usually preserve their historical references while preventing new use. Define retirement separately from destructive deletion.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Database constraintsPostgreSQL
- Table relationships and their behaviorMicrosoft Learn
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy