Revenue Cloud product catalog: modelling machine variants

In the Revenue Cloud product catalog, a machine builder models the sales view, not the ERP material master. Each machine family gets a product classification, a template with attributes such as press force or control type. The base machines inherit these attributes, and options that have no material number of their own stay attribute values. Accessories with their own material number become components of a configurable bundle. SAP delivers material numbers and list prices, Salesforce owns categories, selling attributes and bundle structure. Spare parts and services go into catalogs of their own. That keeps the catalog at a few hundred records instead of thousands of variants.

What does the Revenue Cloud product catalog consist of?

Product Catalog Management is the part of Revenue Cloud that holds products and their structure. Trailhead calls it “a centralized product model that’s the single source of truth for product data”, and other clouds such as Agentforce Manufacturing (Manufacturing Cloud) can use the same product and pricing information through APIs, according to the Revenue Cloud foundations module1. A note on names: Trailhead currently says Agentforce Revenue Management, the Developer Guide says Revenue Management, salesforce.com says Revenue Cloud. The overview of product names sorts this out.

The building blocks, per the Trailhead module on product catalog management2:

• Catalogs hold the products and bundles a company offers. You can create several, for example one for products and one for services.
• Categories and subcategories group products for browsing and search. A product can sit in several categories.
• Attributes describe products. An attribute is defined once and reused across products, picklists are reusable too, and attribute categories group related attributes.
• Product classifications are templates with a set of attributes. A product created from a classification inherits them, and single attributes can be overridden.
• Simple products and bundles. Simple products stand alone, bundles have a hierarchy of several items.
• Product selling models define how a product is sold, for example as a one-time sale, an evergreen subscription or a term-defined subscription. A product can have several, according to the object reference3.

All of these are standard objects on the core platform, from ProductCatalog and ProductClassification to ProductRelatedComponent and ProductSellingModel, as the data model4 shows.

How do you model machine variants without thousands of products?

The key decision is when a variant becomes a product and when it stays an attribute value. I use three tests. A variant gets its own product record when:

1. the ERP has its own material number for it, because the order must reach SAP with that number,
2. it is planned in a sales agreement, because agreements hold quantities per product, as described in from quote to sales agreement,
3. it is stocked or serviced separately, for example as an installed asset with a serial number.

Everything else stays an attribute value on the base machine. A press brake with three bending lengths, two controls and an optional backgauge is one product with three attributes, as long as SAP builds it from one configurable material.

The classification carries the attributes per machine family. Trailhead shows the mechanism with a simple example: products inherit the attributes of their classification, and a WiFi tablet does not need the SIM type its category would give it, so the attribute is overridden. For a machine family this means one template with the attributes sales needs to ask about, and a few overrides for models where an attribute does not apply.

Accessories and packages that carry their own material number belong in a bundle. The Trailhead unit on bundles5 explains the parts: product groups inside the bundle, local cardinality per component (required, included by default, quantity changeable or not) and group cardinality with a minimum and maximum number of products. Customers cannot change static bundles, configurable bundles can be customised during the sale. For a machine with tooling, a safety package and commissioning, that is a configurable bundle with three groups.

Which combinations are allowed is decided by the configurator, not by the catalog. How its rules work is covered in Revenue Cloud configurator: when constraint rules pay off.

Which data comes from the ERP and which lives only in Salesforce?

The first mistake I would avoid in a catalog design is copying the material master. Salesforce needs the sellable products, not the plant data, purchasing data or bills of materials. A bill of materials describes how a machine is built. The bundle describes how it is sold. The two look similar and are maintained by different people.

Data	Master	Note
Material number	ERP	Key for the order hand-over
Product name and short text	ERP or PIM	Translations come with it
List price	ERP	Lands in the price book
Category assignment	Salesforce	Sales structure, not the ERP material group
Classification and selling attributes	Salesforce	Attribute values must match the ERP characteristics
Bundle structure and cardinality	Salesforce	Product management owns it
Selling model	Salesforce	One-time, term-defined or evergreen
Bill of materials	ERP or PLM	Not in Salesforce

The fifth row needs care.

Who owns each object in the org is set in an object ownership matrix. How prices then come from the price book is covered in Salesforce Pricing: how Revenue Cloud calculates prices.

Should spare parts and services get their own catalog?

In most cases, yes. A machine builder sells a few dozen machines and often tens of thousands of spare parts. In a quote, the sales rep needs the machines, their options and the accessories. Spare parts mostly come up in service and in the dealer business. Trailhead explicitly mentions several catalogs, for example a product catalog and a service catalog, and products can sit in several categories when one item is needed in both places.

Services such as maintenance contracts or remote monitoring need a term-defined or evergreen selling model in addition, because they are sold as subscriptions. I would put them in a separate catalog so that product management and service management each maintain their own part.

Worked example: 40 base machines with options

A machine builder sells 40 base machines in four families, each with around a dozen selling options, plus 60 accessories with their own material numbers and around 8,000 spare parts. Without a model, someone suggests creating every sold combination as a product, which quickly runs into the thousands.

With the catalog model it looks like this:

• 4 classifications, one per machine family, each with about 12 attributes such as working width, drive, control and voltage.
• 40 products for the base machines, created from the classifications, with overrides where an attribute does not apply.
• 40 configurable bundles, one per base machine, with groups for tooling, safety and services.
• 60 accessory products as simple products, used as bundle components.
• A spare parts catalog with the 8,000 parts, loaded from SAP, and a service catalog with three subscription products.

The product catalog for quotes then holds around 140 records plus the bundles, and every combination a customer can order is still described completely.

Catalog data is configuration and needs an owner

Classifications, attributes and bundles are records, not metadata. So catalog changes are tested in a sandbox and moved as data through the same pipeline as metadata. How that works with SFDMU or commercial tools is in the DevOps chapter on data and configuration, and the Revenue Cloud specifics are in Revenue Cloud deployments.

For developers

What the object deployment reference sets

The Developer Guide has an object deployment reference (opens in a new tab) that lists the deployment sequence, object types, lookup fields and data translation requirements for Product Catalog Management. The catalog data moves through the pipeline in exactly that order.

The owner should be product management at the manufacturer, not the implementation partner. After go-live new machines, options and price changes arrive every quarter, and whoever maintains the catalog decides how fast sales can quote them.

List machine families and the questions sales asks

1. List the machine families and the questions sales asks per family. They become classifications and attributes.
2. Apply the three tests to every variant: own material number, planned in a sales agreement, stocked or serviced separately.
3. Agree the attribute mapping with SAP before the first data load.
4. Separate machines, spare parts and services into catalogs with different owners.
5. Name the catalog owner and put the catalog under version control as data.

Point 2 decides the size of the catalog: a variant that meets none of the three tests stays an attribute and gets no product record of its own. The whole chapter is in the masterclass part catalog, configurator, pricing, and drawing the line between SAP and Salesforce is part of my Salesforce architecture work.

Sources5

1. 1Revenue Cloud foundations module (opens in a new tab)trailhead.salesforce.com
2. 2Trailhead module on product catalog management (opens in a new tab)trailhead.salesforce.com
3. 3object reference (opens in a new tab)developer.salesforce.com
4. 4data model (opens in a new tab)developer.salesforce.com
5. 5Trailhead unit on bundles (opens in a new tab)trailhead.salesforce.com