Categories are how the storefront is organised. A buyer browses by category, so a store with everything in one list gets harder to use with every product you add. Set them up under Categories.
What a category holds
| Field | What it does |
|---|---|
| Name | The heading buyers see. |
| Parent | Nests this category inside another, for stores large enough to need two levels. |
| Slug | The category in a web address. Leave it alone unless you have a reason. |
| Description | Optional. Useful where a category needs a rule explaining it — "ordered quarterly", "artwork required". |
| Notification users and emails | Who is told when anything in this category is ordered. |
Category notifications
This is the part people miss. Notifications set on a category apply to everything filed in it, so you can route a whole area of the catalogue to the team that handles it without setting recipients product by product.
Uniform orders go to the uniform supplier, signage to the production team, event tickets to whoever runs events. Add a new product to the category and it is routed correctly with no extra step.
Structuring a catalogue
- Name categories the way a buyer would ask for the thing, not the way your org chart is arranged. "Signage" beats "Production Dept".
- A product can sit in more than one category, so do not force a single home for something that genuinely belongs in two.
- Only nest when a top-level list gets long. Two levels is plenty; three is a sign the catalogue needs pruning rather than more structure.
- Create categories before products, so each product is filed as you create it.
Reporting
Categories are also a reporting axis: sales and receivables can both be filtered by category. If you want to know what merchandise costs the network compared with software, that comparison is only as good as your categories are.