Categories
Categories are the navigation tree in your shop. A product can sit in several.
A buyer looking for a screw fitting does not know your family codes. They open Hydraulics, then Fittings, then Screw fittings, and expect the right articles there. Whether they are there depends on two things this page covers: a tree built the way buyers think, and memberships that stay correct while the catalog changes underneath.
Categories are not families
Worth repeating, because conflating them is the most common structural mistake:
- A family is about which fields a product has. It is a data contract.
- A category is about where a buyer finds it. It is navigation.
They often look alike near the top of the tree and diverge quickly. "Screw fittings" is a category. "Hydraulic fitting" is a family. One product, one family, many categories.
Design the tree for buyers, not for your ERP
Your ERP's material group hierarchy was built for accounting and purchasing. It is rarely how a buyer looks for something, and importing it wholesale is a common and disappointing shortcut.
Three rules that hold up:
- Three levels is usually enough. Deeper trees get abandoned mid-way.
- Aim for 5 to 15 children per node. Two children is not a level; fifty is a wall of links.
- Name them the way a buyer would say it out loud. "Verbindungselemente Gruppe 3" is how the ERP says it.
Create a category
- Go to PIM › Categories.
- Select New category.
- Enter a Code (permanent) and the Name per language. The catalog reads by name; a language left blank falls back to the next one that is filled.
- Choose a Parent category, or leave it empty for a root category.
- Set Sort to control the order among siblings.
- Restrict Markets if the category should only exist in some of them.
- Save.
Assign products
Manually, from either side:
- From the product: open it, go to Categories, and select Add to category.
- From the category: open it, go to Products, and select Assign products.
For anything beyond a few hundred products, do it in the import instead, or use rules.
Rule-based categories
A rule-based category defines its members by a condition on attribute values rather than a manual list. It then fills, and re-fills, itself as products change.
Rules do more work per hour of setup than anything else in the catalog, and most catalogs never use them. Good candidates:
- "Stainless steel":
materialis one ofv2a,v4a,1.4571 - "RoHS compliant":
rohs_compliantis true - "Manufacturer X":
manufacturerreferences X - "Large diameter":
diameteris 19 or more
To create one, open the category, add conditions under Rules, and choose Match all conditions or Match any condition. While you type, the Cockpit shows how many products the rule currently matches, so you see a mistake before you save it.
| Rule detail | Behaviour |
|---|---|
| What a condition can address | The product's SKU, Kind, Enabled, Family and Parent model, or any attribute by its code |
| Operators | equals, not equals, greater / less than (and or equal), in a list, contains, starts with, ends with, is empty, is not empty |
| Which attribute values are read | The plain value only. An attribute that is Localizable or Scopable cannot be used in a rule. |
| How numbers compare | As numbers. diameter ≥ 19 matches a stored 19, not a stored "19" text, so type the attribute as a number, not as text. |
| Limits | 25 conditions per category |
| Disabled products | Included by default. The tenant setting Rules may select disabled products switches that off for every preview and recompute. |
| When memberships are computed | On Recompute rules (one category), Recompute all rules (the whole list) and a nightly run. Last recomputed on the category shows when. |
| Manual and rule memberships | Both are listed on the category's Products tab with a Source of Hand-picked or By rule. A recompute only ever adds and removes By rule rows. A hand-picked membership is never removed by a rule, and a product that is hand-picked never gets a second, rule-based row. |
Manual and rule-based membership can coexist: a category can carry a rule and still have products placed by hand.
Categories and the storefront
The tree you build here is what the storefront navigation renders, and it feeds the breadcrumb and the facet context on listing pages. Reordering a category here reorders it in the shop.
Two things to keep in mind:
- A category with no published products still renders unless the storefront is configured to hide empties.
- Changing a category Code breaks any URL or integration referencing it. Rename names freely; leave codes alone.
Next
- Reference entities — manufacturers and materials as real records.