product-modeling

Product type design, attribute selection, and variant planning for Saleor. Use whenever user mentions products, variants, SKUs, attributes, catalogs, or product types. Not for YAML syntax (use configurator-schema) or CLI commands (use configurator-cli).

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "product-modeling" with this command: npx skills add saleor/configurator/saleor-configurator-product-modeling

Saleor Domain Modeling

Overview

This skill helps you design your product catalog structure in Saleor -- choosing the right product types, attributes, variants, categories, and collections. The key decisions are what makes a product vs. a variant, and which attribute type to use for each field.

When to Use

  • "How do I model my products?"
  • "What attributes should I use?"
  • "Product vs variant attributes?"
  • "When to use DROPDOWN vs MULTISELECT?"
  • "How to structure my product types?"
  • "Categories vs Collections?"
  • "When to use Models (Pages) vs Attributes?"
  • When NOT looking for YAML syntax -- use configurator-schema instead
  • When NOT looking for CLI commands -- use configurator-cli instead

The Core Flow

This is the most important relationship to understand:

1. ATTRIBUTES (define fields)
   └── Reusable typed fields: Size (DROPDOWN), Color (SWATCH), Brand (DROPDOWN)

2. PRODUCT TYPES (define structure)
   └── Assign attributes:
       ├── productAttributes: Brand, Material (same for all variants)
       └── variantAttributes: Size, Color (create SKU combinations)

3. PRODUCTS (create items)
   └── Instance of a ProductType:
       ├── Set values: Brand="Nike", Material="Cotton"
       └── Define variants with SKU combinations

4. VARIANTS (purchasable SKUs)
   └── Each combination = 1 variant:
       ├── SKU: "TSHIRT-BLK-M" -> Size="M", Color="Black", Price=$29.99
       └── SKU: "TSHIRT-WHT-L" -> Size="L", Color="White", Price=$29.99

Key insight: Attributes are building blocks. ProductTypes assemble them into templates. Products are instances. Variants are what customers buy.

Decision Framework: Product vs Variant Attributes

This is the most critical modeling decision.

Use Product-Level When:

QuestionIf YES, use Product Level
Same value for all sizes/colors?Brand, Material, Manufacturer
Descriptive information?Care Instructions, Specs
For filtering/categorization only?Style, Gender, Season

Use Variant-Level When:

QuestionIf YES, use Variant Level
Creates a separate purchasable item?Size, Color, Storage
Affects price?Size (XL costs more), quality tier
Needs separate inventory tracking?Each size needs its own stock
Customer selects this at checkout?Color picker, size selector

Quick Decision Matrix

AttributeProductVariantWhy
BrandxSame for all variants
SizexCreates separate SKUs
ColorxCreates separate SKUs
MaterialxUsually same for product
Storage (64GB/128GB)xDifferent prices
Care InstructionsxSame for all variants
WeightxMay differ per size

Attribute Type Selection

Saleor supports 12 attribute input types. Use this decision tree:

Is it a CHOICE from predefined options?
├── YES: Can user select MULTIPLE?
│   ├── YES -> MULTISELECT
│   └── NO: Is it a COLOR/PATTERN?
│       ├── YES -> SWATCH
│       └── NO: Is it YES/NO?
│           ├── YES -> BOOLEAN
│           └── NO -> DROPDOWN
└── NO: Is it a NUMBER with units?
    ├── YES -> NUMERIC
    └── NO: Is it a DATE?
        ├── YES -> DATE (or DATE_TIME if time needed)
        └── NO: Is it long formatted text?
            ├── YES -> RICH_TEXT
            └── NO: Is it a file/document?
                ├── YES -> FILE
                └── NO: Link to another entity?
                    ├── YES -> REFERENCE
                    └── NO -> PLAIN_TEXT

For the complete attribute type reference, see references/attribute-types-deep-dive.md.

Variant Matrix Planning

Before creating variants, calculate the SKU explosion:

SKU Count = Value1 x Value2 x Value3 x ...

Example: T-Shirt
- Sizes: XS, S, M, L, XL, XXL (6)
- Colors: Black, White, Navy, Gray, Red (5)
- SKUs: 6 x 5 = 30 variants per product
SKU CountAssessmentRecommendation
1-10ManageableGood for most products
11-50ModerateFine for fashion, needs inventory planning
51-100HighConsider splitting into multiple products
100+Too manySimplify -- move some attributes to product level

Tips for high counts: Split by product line, reduce dimensions, move non-purchasable attributes to product level.

Industry Patterns

Quick reference for common store types:

PatternProduct-Level AttrsVariant-Level AttrsTypical SKUs
ApparelBrand, Material, CareSize, Color30/product
ElectronicsBrand, Screen, Processor, FeaturesStorage, Color20/product
FurnitureBrand, Style, Capacity, DimensionsFabric, Color16/product
Food & BeverageOrigin, Roast, Flavor, CertificationsSize, Grind12/product
Digital ProductsPublisher, Platform, FeaturesLicense Type, Duration9/product

For complete YAML examples of each pattern, see references/industry-patterns.md.

Categories vs Collections

Both organize products, but they serve different purposes:

AspectCategoryCollection
StructureHierarchical (tree)Flat (list)
Assignment1 product = 1 category1 product = many collections
PurposeTaxonomy, navigationMerchandising, promotions
ExamplesElectronics > Phones > Smartphones"Summer Sale", "New Arrivals"

Use Categories for main site navigation, browse/filter structure, SEO URLs. Use Collections for curated groups, promotions, campaigns, temporary groupings.

Keep category trees to 3 levels deep. If you need a 4th level, consider using Collections instead.

Models and Structures

Models (Pages/PageTypes) let you create custom entities beyond products -- like Brands, Ingredients, or Scent Profiles. Use them when data is shared across many products, has its own attributes, and needs its own page.

Structures (Menus) assemble Categories, Collections, Models, and URLs into navigation hierarchies.

For complete guidance and examples, see references/models-and-structures.md.

Workflow: Designing a New Product Type

  1. List all product characteristics -- write down every field/attribute
  2. Categorize each -- apply the decision framework (product vs variant)
  3. Select types -- use the attribute type decision tree
  4. Calculate SKU count -- ensure the variant matrix is manageable
  5. Write the YAML -- create the ProductType configuration
  6. Validate -- deploy with --plan to check structure

Common Mistakes

MistakeFix
Over-dimensioning variants (6 sizes x 10 colors x 4 materials = 240 SKUs)Move non-purchasable attributes to product level. Aim for under 50 SKUs.
Using variant attributes for non-inventory fieldsIf it doesn't create a separate SKU (like Care Instructions), it's a product attribute
Product attributes that should varyIf value differs by size (e.g., Weight), move to variant level
Too many product typesReuse types when products share the same attribute structure
Skipping variant planningAlways calculate SKU count before creating product types

Additional Resources

Reference Files

Related Skills

  • configurator-schema - Complete YAML schema reference
  • saleor-domain - Entity relationships and Saleor concepts
  • configurator-recipes - Complete store templates

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

reviewing-typescript-code

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

implementing-cli-patterns

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

managing-github-ci

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

configurator-cli

No summary provided by upstream source.

Repository SourceNeeds Review