Catalogue

Products and Variants

Products are held at two levels, and understanding the split is the key to the whole catalogue.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

Master product and variant

• The master product carries what is true of the thing in general: name, brand, category, type, images, videos, a parent SKU, and whether it is published.
• Each variant carries what differs: SKU, price, currency, weight, minimum and maximum order quantity, its own images and videos, and whether it is approved.

A shirt is one master product; small, medium and large blue are variants.

Get the split right first

The commonest catalogue mistake is putting variants at master level — a separate product for every size — which multiplies the listing, splits the reviews, and makes filtering useless.

The test: would a customer consider these the same thing in a different form? If yes, they are variants.

Option sets generate variants

Rather than creating each by hand. Define the option sets for a master product — size, colour, finish — and their values, and the variants can be generated from the combinations.

This is worth using even for a handful of variants, because it keeps the option values consistent. Hand-created variants drift into "Blue", "blue" and "Navy Blue" within a month.

Prices and weights live on the variant

Which is usually right — a large costs more and weighs more. It also means changing a price is a per-variant job, so a catalogue-wide price change is a bulk operation rather than a single edit.

Order limits are per variant too

Minimum and maximum order quantity. Useful for trade shops selling in cases, and for protecting limited stock from a single buyer clearing it.

Publication and approval are separate

A master product is published or not; a variant is approved or not. Both must be right for a customer to buy it, which is a feature rather than an inconvenience — it is what allows a vendor to prepare a listing that nobody can buy yet.

Descriptions are per language

Product detail — the name override, description and search metadata — is held per language against the product, and carries its own approval and revision. So a shop can be genuinely multilingual, and a translation can be reviewed before it appears.

Worked example

A clothing shop holds one master product per garment with colour and size option sets, generating variants from the combinations. Prices differ by size, weights differ by size, and the maximum order quantity is set on limited lines. Descriptions exist in English and Welsh, each approved separately.

Recommendations

• Decide master versus variant before loading anything.
• Generate variants from option sets to keep values consistent.
• Use publication and approval to stage a listing.
• Set maximum order quantity on limited stock.

Categories and Brands

Categories organise the catalogue; brands describe who made the thing. They are separate on purpose.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

Categories are a tree

Each category has a parent, so the catalogue nests as deeply as you need. A category also carries its own image and its own HTML above and below the listing, so a category page can be a piece of content rather than a bare grid.

Allow products only where they belong

A category can be marked as accepting products or not. Marking the branches as no and the leaves as yes prevents the mess where the same product appears at three levels of the tree and nobody knows which listing is canonical.

Design the tree for buyers

Not for your internal product hierarchy, and not for your supplier’s. The question is how a customer would look for the thing, which is often quite different from how you file it.

Three levels is usually plenty. Deeper trees hide products, and buyers give up before reaching the leaves.

Brands are richer than a label

A brand carries a name, tagline, description, logo, cover image, video, website and social links. That is enough to make a brand page worth visiting rather than a filter value.

Whether you use that depends on your business — a shop selling recognised brands benefits from it, a shop selling its own does not.

Brands can carry their own fields

Additional fields can be defined for brands, so you can hold whatever your business needs against them — a supplier reference, a margin band, a contact.

Preview before publishing

Both categories and brands have preview available directly from the row, so you can see the page as a customer would before it is live. Use it, particularly where you have written HTML above or below a listing.

Restructuring later is disruptive

Category URLs are what search engines have indexed and what customers have bookmarked. Moving the tree around after launch loses both, so it is worth more thought before launch than it feels like it deserves.

Worked example

A shop uses three levels, with only leaf categories accepting products and short introductory HTML on each second-level page. Brands carry logos and descriptions, and each has a page. Both were previewed before publication, which caught a category image that was the wrong shape on mobile.

Recommendations

• Structure for buyers, not for your internal filing.
• Only leaf categories accept products.
• Three levels is usually enough.
• Preview before publishing, especially with custom HTML.

Filters

Filters are how a buyer narrows a listing from hundreds to the handful they might buy.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

A filter is scoped to a branch

Each filter names the highest category it applies to, so it appears within that branch and nowhere else. "Shoe size" belongs on footwear, not on the whole shop.

This is what stops the filter panel becoming a list of thirty options, twenty-eight of which are irrelevant to what the buyer is looking at.

The settings

• Type — how the filter is presented.
• Show — whether it appears to buyers at all.
• Required — whether a value must be set on every product in scope.
• Sorting — whether it offers a sort as well as a filter.
• Position and order — where it appears.
• Description — help for the buyer.
• Grouping — which information group it belongs to.

Options for each filter are managed as a row action on the filter itself.

Hidden filters are still useful

A filter that is not shown still holds structured data against products, which can drive sorting or grouping without cluttering the panel. Not everything a filter records has to be something a buyer clicks.

Some filters shape the product

A filter can force a product grouping, and can affect automatic SKU generation. Those are structural rather than cosmetic — they change how variants are formed, so they are worth setting up before loading products rather than after.

Required means every product

Marking a filter required is a commitment: every product in that branch needs a value, and one without will filter out of results the buyer expected it in. That is the mechanism behind "we have that product but nobody can find it".

Fewer, better filters

Buyers use two or three. A panel of twelve is a panel nobody reads. Pick the attributes people actually shop by — size, price, colour, availability — and leave the rest as product detail.

Check what buyers actually select

Shop Insights reports the most-selected filters. A filter nobody touches is clutter; one used constantly might deserve a better position.

Worked example

A footwear shop has three filters on that branch — size, colour and width — with size required and offering sorting. Insights showed width was selected by under two per cent of buyers, so it was hidden while still holding the data for internal reporting.

Recommendations

• Scope each filter to the right branch.
• Two or three shown filters per branch.
• Set structural filters before loading products.
• Use Insights to retire filters nobody selects.

Bundles and Linked Products

Two different ways of relating products: bundles sell them together, links suggest them alongside.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

Bundles

A bundle has a name, a category, and lines. Each line is a slot in the bundle with its own type and order, and each line holds the products that can fill it.

That structure supports both a fixed bundle — these three items — and a configurable one, where the buyer chooses which product fills each slot.

Bundle detail is per language

Name, description and search metadata are held per language, the same as products. A bundle is a thing a customer browses and search engines index, so it deserves its own description rather than a list of its contents.

When a bundle earns its place

• A starter kit where the combination is the product.
• A configurable set — choose a frame, choose a lens, choose a case.
• A price that only makes sense together.

Not simply to suggest a second item. That is what links are for.

Linked products

A simple relation from one product to another, used for accessories, alternatives and "goes with this". Cheap to maintain and effective, and it does not change what the customer is buying.

Link deliberately, not exhaustively

Three good links beat twenty. Linking everything to everything produces suggestions that are obviously automatic, which buyers learn to ignore.

The best links are the ones a salesperson would mention: the thing you need with it, and the thing to buy instead if this one is too expensive.

Watch the stock implications

A bundle is only sellable if every slot can be filled. If one component is out of stock, the bundle is unavailable — which surprises people who set bundles up and then wonder why they vanished from the shop.

Review links when products retire

A link to a discontinued product is a dead end in the middle of a purchase. When retiring a product, check what links to it.

Worked example

A camera shop sells a starter bundle with three slots — body, lens and case — where each slot offers a choice. Individual products carry three or four links each: the matching accessory, the next model up, and the consumable. Links are checked whenever a product is retired.

Recommendations

• Bundles for products sold together, links for suggestions.
• Give bundles their own description.
• Three good links beat twenty automatic ones.
• Check links when retiring a product.

Custom Product Fields

Products can carry fields of your own, defined the same way as any other field in the platform.

Where to find it

Architect Panel → Commercial:

• Carts — the cart itself and its options

Architect Panel → Data:

• Datastores — then View Data on the cart table, and look for the row actions

What a field carries

A name, a friendly name, a description, a type, a default, validation, whether it is required, its order, whether it is encrypted, whether it is visible to the public, its scope, and which information group it belongs to.

Public visibility is the important one

Some product fields are for buyers — material, dimensions, certification. Others are for you — supplier reference, cost, margin band, a note about a difficult line.

The public flag is what separates them, and getting it wrong publishes your cost price. Check it explicitly on every field you add rather than trusting the default.

Information groups make the page readable

Fields are grouped, and each group has a name, an order and a placement. That turns a product page from a flat list of twenty attributes into "Specifications", "Materials and care" and "Delivery" — which is the difference between information a buyer reads and information they scroll past.

Scope

A field can apply to part of the catalogue rather than all of it. Dimensions matter for furniture and not for software; scoping keeps each product’s field set relevant.

Required fields are a loading obligation

Marking a field required means nobody can add a product without it. That is often right — a shop where half the products lack dimensions is a shop with a filter that does not work — but it is a commitment for whoever loads the catalogue.

They feed filters

Structured product data is what makes filtering possible. A field held as free text cannot be filtered on usefully, so choose a constrained type where the values are known.

Add fields sparingly

Each one has to be populated for every product, forever, including every product a vendor adds. A field that is empty on most products is worse than no field, because the page shows a gap.

Worked example

A furniture shop holds dimensions, material and assembly time as public fields grouped under "Specifications", and supplier reference and cost band as private fields. Dimensions are required and scoped to furniture categories only. A review before launch caught one field flagged public that held a cost.

Recommendations

• Check public visibility on every field individually.
• Group fields so the page reads as sections.
• Constrained types where you want to filter.
• Scope fields rather than applying them catalogue-wide.