Products and variations
A product is what a customer recognises. A variation is what they actually buy: a size, a colour, a voltage, a length of cable.
Why the split matters
One product page shows one story — photographs, description, documents — and offers several things to buy. Without variations you either publish one page per variant (and repeat the description forty times) or you sell "a cable" without saying which one.
| Lives on the product | Lives on the variation |
|---|---|
| Name, description, photographs | SKU |
| Category and tags | Price and currency |
| Datasheets and manuals | Stock |
| Manufacturer | Weight and dimensions |
Attributes
An attribute is what makes one variation different from another: size, colour, voltage, length. You create it once and then choose its value on each variation.
An attribute is not a special kind of thing the platform keeps in a hidden list. It is two ordinary parts you already know:
- a register (a vocabulary) holding the possible values — S, M, L;
- a field on the variation types that use it, pointing at that register.
That is why the values are managed exactly like any other register, on the Values link beside the attribute, and why an attribute's values can be translated, reordered and nested like any other terms.
Where: Products → Attributes. Give it a name, tick the variation types that should carry it, create. Ticking the same attribute on a second type later attaches the same field — you never make "size" twice.
An attribute belongs to the firm that created it
The attribute and its values belong to the organization you have open in the toolbar, and no other firm sees them.
This is not tidiness. An attribute is how a catalogue is browsed, so a shared list of values is two firms' data on one page: your customer sees sizes that belong to somebody else's products, and either firm can edit or delete what the other one sells by.
Two firms may each have an attribute called Size, with entirely different values. The name is not the identity — the owner is.
Because of that, the create form asks for an open organization. With several firms in scope and none open, the form cannot know whose attribute it would be, so it says so instead of guessing — the toolbar is where that question is answered.
Removing an attribute from a variation type is refused while variations of that type carry values for it. Empty it first, or leave it: an attribute with no values on a type costs nothing.
SKU
The SKU is the identifier the rest of the business uses — stock, orders, invoices, the scanner.
One SKU field, one meaning
A SKU is unique across the whole catalogue within an organization, however many types carry one. Two records sharing a SKU means a stock movement that cannot say what it moved. The platform refuses the duplicate rather than accepting it and being wrong later.
The uniqueness is scoped to the organization, like everything else. Two firms
may each have a part called A-100; they are two different parts.
Addresses
A variation is addressable but not public: it has a real address a customer can be linked to, but it does not appear in public listings.
That is not a limitation, it is a decision. A listing of variations is exactly what would publish your cost prices and internal codes; a link to one variation is what a salesperson needs to send.
The address usually follows the product: the product's own path plus the variation's SKU.
Prices
A price belongs to a variation, in a currency. The platform is multi-currency throughout: prices, orders, invoices and reports all carry the currency they were made in, and exchange rates are a register you maintain rather than a constant somebody typed.
Stock
Stock is per variation and per location. See Inventory.
Publishing the catalogue
A product appears publicly when it is published and its type is public. A category page is a listing with a path filter on the category term, usually including children.
What the web shows of a variation
A variation carries the firm's bookkeeping next to the offer: the SKU, the invoice and bill policies, tracking, the cost and costing method, the VAT rate, the ordering weight and a payment gateway's price id. None of it is a shopper's business, so a variation type's display rows for these fields are born with visibility never — the public web and the app never carry them, in the rendered rows or in the raw payload — while the back office keeps showing every row. The price, the unit and the shipping weight stay public. The firm decides otherwise per field on Manage display (a row's visibility setting); an explicit rule, either way, always wins, and an installation older than the rule took it once without touching rules already set.
The product page draws a variation in the web view mode of its type. A firm that wants the page to show only the offer — the price, its note, a one-line description — shapes that mode on Manage display (a row's visibility) and every other place keeps reading the default rows: a pricing view, the back office. A mode without a rule of its own inherits the default row's rule, so a price kept for signed-in customers stays so in every mode until that mode says otherwise.