revenue-cloud-pcm

Salesforce Product Catalog Management (PCM)

You are helping with Salesforce Product Catalog Management in Salesforce Revenue Cloud / Agentforce Revenue Management / Revenue Cloud Advanced / Revenue Cloud Billing. This is the newer core-platform product family that uses standard/core Salesforce objects such as Product2, Quote, QuoteLineItem, ProductClassification, and related PCM objects. Do not drift into legacy managed-package Salesforce CPQ (SBQQ__) or legacy Salesforce Billing (BLNG__) patterns unless the user explicitly asks for those products.

PCM models the company's product portfolio — catalogs, categories, products, bundles, dynamic attributes, classifications, qualification rules, selling models, and the Product Discovery experience.

This file is your routing layer. It contains the gotchas you must always remember and a map of when to load which reference. Do not try to answer detailed PCM questions from this file alone — load the right reference first.

Always-true gotchas (never forget these)

These are the corrections most agents need before they can be useful in PCM. Internalize them:

1. Bundles use a TWO-table structure, not one. A configurable bundle has both ProductRelatedComponent (the line linking a child to a parent) and ProductComponentGroup (the section the line belongs to). Static bundles can skip groups; configurable bundles cannot. Don't model a bundle without thinking through both.
2. Attributes can be attached at TWO levels. ProductClassificationAttr defines the template attribute on a classification. ProductAttributeDefinition is the instance attached to a specific Product2. A product based on a classification inherits its attributes; you only create a ProductAttributeDefinition when overriding an inherited attribute on a specific product or adding a one-off attribute. Confusing these two is the most common PCM modeling error.
3. Qualification rules default to qualified. A product or category with NO qualification/disqualification record is visible. Qualification beats disqualification when both apply. Don't write a rule "to make it visible" — write a rule to restrict visibility.
4. ProductSellingModel is its own object, not a Product2 picklist. Pricing term length and unit live on ProductSellingModel. A product is linked to one or more selling models via ProductSellingModelOption. Pricing (rates, books) lives in a separate Salesforce Pricing module — do NOT try to put price on Product2 directly for PCM-driven flows.
5. Product2.Type = 'Bundle' is the switch that turns a product into a bundle. Without it, ProductRelatedComponent rows pointing to it will not be treated as bundle components by the runtime. Also set ConfigureDuringSale correctly: Allowed (configurable), Not Allowed (static), or None (simple product).
6. Product2.BasedOnId (the classification link) is what makes a product inherit attributes. Setting BasedOnId is mandatory before you can rely on classification-driven attributes; without it, you have to attach every attribute via ProductAttributeDefinition directly.
7. Catalogs and categories are time-bounded. EffectiveStartDate / EffectiveEndDate on Catalog, and EffectiveFromDate / EffectiveToDate on qualification/disqualification rules. A "missing" product in Product Discovery is most often an expired effective-window, not a permission or rule problem.
8. API version matters. Most PCM objects appear in API v60.0+. Some (ProductRampSegment, IsNavigational, ProductComponentGroup.ParentGroupId, Product2.UsageModelType) are v62.0+. AttrPicklistExcludedValue is v61.0+. Check the API version of the org before assuming an object exists.
9. PCM is not standalone. It hands records off to Salesforce Pricing, Product Configurator, Transaction Management, and Billing. A "wrong" PCM model often shows up as a downstream pricing or configurator error. When debugging, identify which module is actually emitting the error before changing PCM.
10. Permission set groups, not profiles. PCM ships permission sets: ProductCatalogManagementDesigner, ProductCatalogManagementViewer, plus community variants. Compose them via permission set groups; do not clone profiles.
11. Describe the org before data migration or bulk lookup work. Object and field API names vary by org/version: catalogs may expose as ProductCatalog rather than Catalog, and AttributePicklistValue may use PicklistId rather than AttributePicklistId.
12. This is not legacy managed-package CPQ/Billing. Revenue Cloud / Agentforce Revenue Management uses core objects and unnamespaced APIs for PCM. Avoid SBQQ__ CPQ and BLNG__ Billing assumptions, fields, and object names unless the user explicitly says they are working on those legacy managed packages.