quote → cash
EN/FR Contact

Product·Reference·8 min·Updated 2026-10-05

A bundle catalog that survives contact with sellers

Model bundles, options and regional variants without producing a catalog nobody can maintain.

Salesforce docs documented by SalesforceField experience observed on a real orgRecommended pattern what we recommendTo verify unverified

Business requirement

Offers made of a base plus options, where the options differ by region and the price depends on volume.

Why it is not trivial

Everything about a bundle is easy except the second region and the third option. The structures that break are the ones where category, classification and bundle membership were treated as the same idea.

Recommended architecture

Keep the three axes separate: the classification says what a product is and therefore which attributes it carries; the category is where a seller finds it; the related-component structure is what a bundle contains.

Salesforce components

Select one to open its detail.

Flow

Product and catalog architecture two axes, one product
CATALOG DEFINITION SELLING browse shape required ProductCatalog the container ProductCategory the shelf Classification what it is AttributeDefinition what it carries Product2 the product SellingModel how it is sold RelatedComponent the bundle PricebookEntry the list price

Scroll the diagram sideways

Attributes hang off the classification, not off the product. The category is only what the seller browses. Modelling them as one thing works until the first product needs to appear on two shelves, or two products of the same type need different attributes.

Implementation

  1. Classifications before products. Changing one afterwards changes the shape of every line already captured against it.
  2. A sequence on every bundle component. A null one throws an index error at configuration time.
  3. Build one product by hand in the UI first, then compare it field by field with one created by API before loading the rest.

Watch out

  • Products created in bulk by API can behave differently from identical-looking products created in the UI — observed as a bundle that refused to open the configurator while a hand-built equivalent worked. The UI fills fields the API call does not.
  • A duplicate price book entry where one is inactive blocks the active one.
  • The selling model on the price book entry is immutable after insert.

Alternatives

Flattening every combination into its own product removes the configurator entirely and is defensible for a small, stable catalog. It stops scaling at the first attribute that multiplies the combinations.

Salesforce resources

Guide