Product families, bundles and the publish cycle

What it does

The product catalogue holds what the business sells, organised into product families, individual products and bundles, described by product properties. Records move through a draft-publish-revise lifecycle, and only published (Active) products can be sold.

Key facts

The ProductStructure column decides what a record is: 1 = Product, 2 = Product Family, 3 = Bundle.
Lifecycle states are Draft, Active, Under Revision and Retired. Draft → Active is Publish; Active → Under Revision is Revise; Under Revision → Active is either a re-publish or Revert (which discards the unpublished changes); Active → Retired is Retire.
Activate only works on retired products with no parent and retired kits. Retired product families and retired bundles can't be reactivated.
A child product or bundle can't be published unless its parent family is published first. PublishProductHierarchyRequest publishes a family and everything under it.
ParentProductId cannot be changed once set. That is the single most consequential constraint in the catalogue. A product belongs to exactly one family, and only families can be parents.
Product family nesting has no documented depth limit.
Bundles can contain products only — not families, not other bundles, not kits. Bundle members are ProductAssociation records carrying quantity, unit, and a required/optional flag (0 = optional, 1 = required). Kits are the deprecated predecessor; use bundles.
Maximum products in a bundle comes from Organization.MaxProductsinBundle, default 15. Maximum properties on a product or bundle comes from the organisation setting shown as Max number of properties of a product or bundle, default 50.
Product properties attach to Draft product families only, and support Option Set, Decimal, Floating Point, Single Line of Text and Whole Number. The data type can't be changed after creation.
Children can override an inherited draft-state property. Overriding an active-state property requires the child to be Under Revision and the property to be overridden already.
Product properties do not affect pricing. The pricing engine can't adjust a price based on a property value.
Organization.CreateProductsWithoutParentInActiveState controls whether products with no family are created Active or Draft. Fresh installations default to 0 (Draft); upgraded organisations default to 1 (Active). The Sales setting is Create product in active state, and it doesn't apply to products under a family.
Retiring a product that belongs to a published bundle isn't allowed, and retired products can't be added to bundles.
Product families are documented as supported in the Sales Hub app. Products, bundles and price lists work in Sales Professional as well.

When to use / skip

Build a family hierarchy when the client has enough products that sellers need to browse by category, or when properties genuinely differ by category. Build bundles when they sell fixed groupings and want the components visible on the quote.

Skip the hierarchy when the catalogue is under a few dozen products with no natural grouping. A flat product list with a good price list is easier to maintain and nobody misses the tree. Skip properties unless someone can name the report or the quote line that uses them — because they don't drive price, they're descriptive only, and they add a configuration dialog to the seller's add-product flow.

Be sceptical of clients who want the CRM catalogue to mirror the ERP item master item-for-item. Sales needs what sellers quote, not every SKU, spare part and packaging variant.

Configuration decisions

The family hierarchy itself, decided before the first product is created, because the parent can never be changed afterwards.
Whether Create product in active state is on. Off means every new product needs an explicit publish, which is governance; on means anyone with Create on Product can put something sellable in front of sellers.
Bundles versus separate lines. Bundles look tidy on a quote; separate lines are easier to discount and report on individually.
Which bundle members are required and which optional, remembering optional members bring price list constraints with them.
Whether product properties are used at all, and if so which ones live at family level for inheritance versus which are overridden per product.
Who owns catalogue maintenance and what the publish process is — including whether the ERP is the source and the catalogue is integrated rather than typed.

Gotchas

The unchangeable parent is the classic one-way door. Get the hierarchy wrong and the fix is deactivating products and recreating them, which orphans every historic line item that referenced the old ones.
Publishing order matters. Publishing a child before its family fails, and the message doesn't always make the dependency obvious to a functional consultant.
Revert silently discards everything done since the revision started. Someone editing a product over several days can lose all of it with one click.
Properties existing but not affecting price is the single biggest misunderstanding in this area. Clients assume "size = large" can add 20 percent. It can't, not without custom pricing.
Data migrating a catalogue is harder than it looks: products must be created in the right state, families before children, bundle associations after both, and publish is a state transition rather than a field update.
The default bundle limit of 15 products is small for clients selling configured systems, and it's an organisation-wide setting rather than per-bundle.
Retiring a product doesn't touch existing opportunity, quote or order lines. They keep referencing a product sellers can no longer find, which confuses everyone reading old records.
Kits still exist in the schema. Migrations from very old CRM systems bring them across, and they behave differently from bundles.

Consultant notes

Run a catalogue design workshop before any build, and treat the family hierarchy as an architecture decision with a sign-off. Say the words "this cannot be changed later" out loud.
Demo a bundle on a quote to a sales manager. They either love the component visibility or want it hidden, and that answer decides bundle versus separate lines.
Push back on properties unless the client can point at what consumes them. Otherwise you're adding clicks to every add-product action for decoration.
Get the catalogue owner named and the maintenance process agreed before go-live. An unmaintained catalogue turns into write-in products inside a quarter.
If the ERP holds the master data, scope the integration properly — including how retirement and republish propagate. Doing catalogue sync by hand never lasts.

Worth another look before any catalogue restructure, or if the bundle size limit starts biting.