Docs navigation
Home / Docs / PIM classes & templates

PIM classes & templates

Product classes and templates define what "complete" means for each kind of product you sell — required fields, custom attributes, and channel mappings.

A brake rotor and a t-shirt are both products, but they’re complete in different ways. The rotor needs a diameter and a bolt pattern; the shirt needs a size and a fabric. Product classes and templates let you say that once, then hold every product of that kind to its own standard.

This layer is separate from categories. Categories are how customers browse; classes are how you model. A “Brake Rotors” category and a “Brake Rotors” class often coexist and serve different jobs.

The three pieces

Product Class  ──has one──▶  Template  ──composes──▶  Custom fields
   (the kind)                 (the schema)              (the attributes)
  • Product class — the kind of thing: “Brake Rotor”, “Apparel”, “Turbocharger”. Products are assigned to one.
  • Template — the schema that class expects: which standard fields are mandatory, which custom fields apply, how they map to channels.
  • Custom fields — the individual attributes, drawn from your org’s field library.

Each class has at most one template. The split exists so a template can be shared across classes without duplicating its field list.

What a template defines

Required standard fields

A list of built-in Product and Variant fields that must be populated — brand, weight, mpn, and so on. This is how you enforce that every apparel item has a brand without demanding it of raw materials.

Custom fields

Which definitions from your library apply, and for each one:

  • Required — must be filled for the product to be complete
  • Position — display order on the edit form
  • Default value — pre-filled when the class is applied

Defaults are underrated. If 90% of your rotors are vented, defaulting vented to true means the exception is the only thing anyone types.

Channel mappings

How this template’s fields translate to each channel’s own attribute names. Your thread_pitch may need to arrive as Thread Pitch on one platform and attr_142 on another. Mapping lives on the template so it’s defined once per product kind rather than per product.

Per-channel overrides handle the case where one platform needs a different mapping than the rest.

Why bother

Without this layer you get catalogs where completeness is a matter of whoever typed it. The concrete wins:

  • Consistent data — every rotor has a diameter, because the template says so
  • Faster entry — the form shows the fields that matter for this kind of product, not all 200 in your library
  • Cleaner channel pushes — mapping is defined once, not rediscovered per listing
  • Findable products — structured attributes make filters and facets possible

Setting one up

  1. Build the field library first. Define the custom fields you need in custom fields. Templates compose existing definitions rather than creating them.
  2. Create the template. Name it, mark the required standard fields, attach custom fields with their required flags, positions, and defaults.
  3. Create the class and point it at the template.
  4. Assign products to the class. They immediately inherit its expectations.
  5. Add channel mappings as you connect channels.

Start narrower than feels right. A template with eight well-chosen fields gets filled in; one with forty gets abandoned, and half-filled structure is worse than none.

Assigning products

A product belongs to at most one class. Assigning one doesn’t retroactively populate values — it declares what should be there, and surfaces the gaps.

Changing a product’s class keeps existing custom field values. Values whose fields aren’t in the new template stop being displayed but are not deleted, so reassigning back restores them.

Modeling notes

Class or category? If you’re deciding how it’s browsed, that’s a category. If you’re deciding what fields it needs, that’s a class. A product has both.

Class or brand? Brand is who made it. Class is what kind of thing it is. “Brembo” is a brand; “Brake Rotor” is a class.

How granular? One class per genuinely different field set. If “Brake Rotors” and “Brake Pads” need meaningfully different attributes, split them. If they differ only by one field, one class with an optional field is simpler.

Product-level or variant-level? Templates can require both. Put an attribute on the variant when it differs between sellable SKUs — size, color, length. Put it on the product when it’s true of the whole family. See custom fields for why this is the modeling decision people most often get wrong.