Section 01
Salesforce CPQ
Revenue Cloud
Product Catalog & Configuration
An architect-level comparison of how Salesforce CPQ (SteelBrick lineage) and Salesforce Revenue Cloud approach product modeling, catalog taxonomy, bundle configuration, and variant selection — covering data models, automations, licensing, effort, and customization patterns.
1.1
Use Case, User Journey & Personas
Product Catalog & Configuration is the foundation of any CPQ or Revenue Cloud implementation. It defines what you sell, how products relate to each other, and what rules govern valid combinations. The choice of platform shapes every downstream process — pricing, quoting, ordering, and billing.
When to Use Each Platform for Catalog & Configuration
CPQ — Best Fit When
- Bundle-heavy catalog with complex option constraints
- Sales-rep–driven configuration in a quote context
- Existing Product2 catalog with CPQ fields already in place
- Need rapid rule authoring without Apex (Product Rules)
- Subscription products coexist with one-time hardware
- Partner communities require catalog access via PRM
Revenue Cloud — Best Fit When
- Product variety driven by attributes/variants (telecom, SaaS tiers)
- Rich taxonomy with hierarchical product categories required
- Headless or embedded catalog experience needed
- External PIM must synchronize into Salesforce catalog
- Long-tail catalog (thousands of SKUs) managed via classification
- OMS or B2B Commerce must consume the same catalog
Internal Personas
Sales Rep
Configures products, selects options, resolves configuration alerts during quoting.
Product Manager
Defines product hierarchy, bundles, attributes, and lifecycle state transitions.
CPQ / RC Admin
Configures rules, option constraints, attribute sets, and pricing structures.
Solutions Engineer
Designs complex bundle logic, validates feasibility, and supports advanced deals.
Salesforce Architect
Owns data model design, integration patterns, and platform governance.
External Personas
CPQ — External Users
- Partner (PRM): Accesses CPQ configurator via Salesforce Communities with partner-specific pricebooks and filtered product catalog
- Customer (Community/Portal): Limited self-service configuration via CPQ in Experience Cloud; typically requires custom UX work
Revenue Cloud — External Users
- Partner: Catalog served via headless API or embedded RC UI in Partner Community; category/attribute-driven browsing
- Customer (Self-Service): First-class support for B2C/B2B self-service via RC headless catalog + cart APIs; integrates with B2B Commerce
CPQ User Journey — Configuration
Admin configures Product2 + SBQQ__ bundle objects
Setup
→
Sales Rep opens CPQ Configurator from Quote Line
Initiate
→
Selects base product / bundle
Select
→
Adds options; Config Rules fire
Configure
→
Validation / alerts resolved; saved to Quote
Finalize
Revenue Cloud User Journey — Configuration
Admin sets up Product Categories + Attribute Sets in RC Catalog
Setup
→
Sales Rep opens Product Catalog UI / Cart
Initiate
→
Browses categories; filters by attribute values
Browse
→
Attribute values drive variant / SKU selection
Configure
→
Product added to cart/quote; relationship rules evaluated
Finalize
| Touchpoint | CPQ | Revenue Cloud |
|---|---|---|
| Primary UI | CPQ Configurator (iframe/LWC) | Product Catalog Browser (LWC/Headless) |
| Category Navigation | ~ Via Product Family field filtering | ✓ Native category hierarchy with nested browsing |
| Attribute/Variant Selection | ~ Configuration Attributes (limited) | ✓ Attribute Sets + ProductClassification (native) |
| Bundle Configuration | ✓ Rich bundle with Features, Options, Constraints | ~ ProductRelatedComponent + ProductComponentGroup (typed via ProductRelationshipType; less constraint granularity than CPQ) |
| Rules & Validation | ✓ Declarative Product Rules (4 types) | ~ Relationship types + Flow extensions |
| Partner Access | ✓ PRM + CPQ Communities integration | ✓ Headless API or embedded RC UI |
| Self-Service Customer | ~ Custom build required | ✓ First-class B2B/B2C Commerce integration |
| Headless / API Catalog | ✗ Not supported natively | ✓ Commerce Catalog REST API (headless) |
Key Takeaway — 1.1
CPQ excels in sales-rep–driven bundle configuration with rich declarative rules. Revenue Cloud's catalog is built for attribute/variant–heavy products, hierarchical taxonomy, and headless/multi-channel consumption. Neither is universally superior — the right choice depends on whether your catalog is bundle-first (CPQ) or attribute/category-first (Revenue Cloud).
1.2
Licensing Requirements
CPQ Licensing
- CPQ (Base): Named user license; includes Product2 bundles, configurator, pricing, and quote generation
- CPQ+: Adds Subscriptions, Amendment & Renewal automation, Contracting
- Per-user model: Every user who accesses the CPQ configurator needs a license
- Partner Community: Community CPQ license required per partner user accessing configurator
- Read-only access: Shared App license (lighter) for users who only view quotes
- API access: Included with CPQ license; no separate API-only tier
Revenue Cloud Licensing
- RC Base: Covers Product Catalog, Attribute Sets, Categories, and basic cart/quote
- RC Advanced / Full: Adds Billing, RevRec, advanced pricing, OMS integration
- Headless Catalog API: Requires specific Catalog Runtime entitlement (discuss with AE)
- Named vs. Usage: RC moves toward consumption-based entitlements for API use cases
- B2B Commerce bundle: Combined license available for Commerce + RC catalog sharing
- Partner access: Experience Cloud + RC license; no separate Community-specific SKU
| Catalog Feature | CPQ Std | CPQ+ | RC Base | RC Advanced |
|---|---|---|---|---|
| Product2 catalog management | ✓ | ✓ | ✓ | ✓ |
| Bundle / option configuration | ✓ | ✓ | ~ via ProductRelatedComponent + ProductRelationshipType | ✓ |
| Product Rules (declarative) | ✓ | ✓ | ✗ | ✗ |
| Product Categories & Taxonomy | ✗ | ✗ | ✓ | ✓ |
| Attribute Sets & Classification | ✗ | ✗ | ✓ | ✓ |
| Configuration Attributes | ✓ | ✓ | ✗ | ✗ |
| Headless Catalog API (Commerce Catalog REST) | ✗ | ✗ | ~ limited entitlement | ✓ |
| Subscription products (catalog-level) | ✗ | ✓ | ✓ | ✓ |
| Partner Community catalog access | ~ add-on license | ~ add-on license | ✓ via Exp Cloud | ✓ |
| Product lifecycle management (states) | ✗ | ✗ | ✓ | ✓ |
Licensing Pitfall
CPQ licenses are all-or-nothing per user — even a Solutions Engineer who only occasionally reviews configurations needs a full CPQ seat. Revenue Cloud's per-API-call model for headless scenarios can become expensive at high volume; validate Catalog Runtime entitlements before architecting a high-throughput integration.
Key Takeaway — 1.2
CPQ licensing is simpler to understand (named user, one SKU covers catalog + pricing + quote) but can be expensive for large sales orgs. Revenue Cloud's catalog features are generally included in the base RC license, but headless API usage and advanced subscription features require tier upgrades. Always confirm Catalog Runtime API entitlements with your Salesforce AE before commit.
1.3
Data Model
CPQ Objects
Product2
Platform-Standard
Base product record; extended by CPQ managed fields
SBQQ__Component__c— marks as component-onlySBQQ__BillingType__c— Advance / ArrearsSBQQ__SubscriptionType__c— Renewable / One-timeSBQQ__ConfigurationLayout__c— Conf. layout override
Pricebook2 / PricebookEntry
Platform-Standard
Standard pricebook records; CPQ adds cost/markup fields
SBQQ__Cost__con PricebookEntrySBQQ__CustomPrice__cflag
SBQQ__Feature__c
CPQ-Specific
Groups related options within a bundle (e.g., "Storage Add-ons")
SBQQ__Product__c— parent bundle productSBQQ__MinOptionCount__cSBQQ__MaxOptionCount__cSBQQ__Number__c— display sort order
SBQQ__ProductOption__c
CPQ-Specific
Links an option Product2 to a bundle Feature
SBQQ__ConfiguredSKU__c— bundle productSBQQ__Feature__c— owning featureSBQQ__OptionalSKU__c— option productSBQQ__Type__c— Component / Accessory / RelatedSBQQ__Selected__c— default selectedSBQQ__Required__c
SBQQ__ConfigurationAttribute__c
CPQ-Specific
Exposes a field as a visible/filterable attribute in the configurator
SBQQ__Product__cSBQQ__Feature__cSBQQ__Column__c— field API nameSBQQ__TargetField__c— field to set on QL
SBQQ__OptionConstraint__c
CPQ-Specific
Include/exclude rules between option combinations
SBQQ__ConstrainedOption__cSBQQ__ControllingOption__cSBQQ__Type__c— Dependency / ExclusionSBQQ__Operator__c
SBQQ__ProductRule__c
CPQ-Specific
Declarative rule engine: Validation / Selection / Filter / Alert
SBQQ__Type__c— rule typeSBQQ__Scope__c— Quote / Product / BothSBQQ__EvaluationEvent__cSBQQ__Active__c
SBQQ__ProductAction__c
CPQ-Specific
Actions fired when a ProductRule condition is met
SBQQ__ProductRule__cSBQQ__Type__c— Add / Remove / Show / Hide / Enable / DisableSBQQ__TargetField__c
Revenue Cloud Objects
Product2
RC-Modified
Enhanced with catalog fields for categories, lifecycle, and attributes
ProductClass— Simple / Set / BundleIsActive,BasedOnId(variant parent)ProductSellingModel— links to selling model
ProductCategory
RC-Standard
Hierarchical taxonomy node (supports unlimited nesting)
Name,ParentCategoryIdSortOrderIsNavigational— show in browse treeCatalogId— optional catalog scoping
ProductCategoryProduct
RC-Standard
M:M junction — assigns product to one or more categories
ProductCategoryIdProductIdIsPrimaryCategory
ProductAttributeSet
RC-Standard
Named set of attributes reusable across multiple products
Name,DescriptionDeveloperName(immutable API name)
ProductAttribute
RC-Standard
Individual attribute definition within an Attribute Set
AttributeSetIdFieldId— maps to a product fieldSequenceIsRequired
ProductRelationshipType
RC-Standard
Lookup table that classifies parent-child roles for bundle and set components. Referenced by
ProductRelatedComponent via ProductRelationshipTypeIdName— e.g. "Bundle to Bundle Component Relationship"MainProductRoleCat— role of the parent (Bundle, Set, ProductRequest)AssociatedProductRoleCat— role of the child (BundleComponent, SetComponent, etc.)
ProductQualification
RC-Standard
Declares that a product is eligible within a given product hierarchy context; supports date-range and criteria-based eligibility
ProductId— the product being qualifiedRootProductId/ParentProductId— hierarchy contextIsQualified,EffectiveFromDate,EffectiveToDateRowQualificationCriteria— expression-based rule
ProductDisqualification
RC-Standard
Declares that a product is ineligible within a given product hierarchy context; can carry a human-readable reason
ProductId— the product being disqualifiedRootProductId/ParentProductId— hierarchy contextIsDisqualified,EffectiveFromDate,EffectiveToDateReason,RowDisQualificationCriteria
ProductClassification
RC-Standard
Links a Product to an AttributeSet (drives attribute rendering)
ProductIdProductAttributeSetId
AttributeCategory
RC-Standard
Groups attributes for display within the catalog UI
Name,SortOrderProductAttributeSetId
Commerce Catalog REST API
RC-Standard
Headless API endpoint for catalog browsing, search, and cart operations — not a Salesforce object; accessed via the B2B/B2C Commerce API surface
- Invoked via
/services/data/vXX/commerce/webstores/{id}/catalog - Supports category tree, product search, variant resolution
- Connected to Commerce entitlement for external access
Migration Mapping — CPQ → Revenue Cloud
SBQQ__Feature__c → ProductCategory (for grouping) + ProductAttributeSet (for display attributes) |
SBQQ__ProductOption__c → ProductRelatedComponent (with ProductRelationshipTypeId for role classification) |
SBQQ__OptionConstraint__c → ProductDisqualification (eligibility exclusion) or Flow-based validation |
SBQQ__ConfigurationAttribute__c → ProductAttribute within ProductAttributeSet |
SBQQ__ProductRule__c → No direct equivalent; replaced by Flow-based validation or custom LWC logic.
Revenue Cloud — Core Object Deep Dive
ProductCatalog
RC-Standard
Top-level container that scopes categories, products, and channel availability. Every product browse/search request is catalog-scoped.
Name— display name (e.g., "QuantumBit Enterprise Catalog")Status— Draft / Active / ArchivedEffectiveStartDate/EffectiveEndDateCurrencyIsoCode
Created by: Product Manager admin via Products & Catalog app setup tab. Typically 1–3 catalogs per org (by region or channel). Not created by end-users.
ProductSellingModel
RC-Standard
Defines the commercial model (One-time / Evergreen / Term) and billing frequency. A single product can have multiple selling models for different buyer journeys.
Name,StatusSellingModelType— OneTime / Evergreen / TermDefinedPricingTermUnit— Monthly / Annually / etc. (picklist)PricingTerm— number of units (e.g. 12 for a 12-month term)
Created by: RevOps / Pricing admin via setup UI or bulk data load during implementation. Shared across products — define once, reuse. Changes affect all linked products.
ProductRelatedComponent
RC-Standard
RC's equivalent of CPQ product options. Links a child product to a parent bundle and defines quantity, min/max, and whether it is required or optional.
ParentProductId— the bundle/Set productChildProductId— the componentProductComponentGroupId— optional groupingMinQuantity/MaxQuantityDefaultQuantityIsDefaultComponentIsRequiredSequence— display order
Created by: Product Manager via the product detail page "Components" tab in the Products & Catalog app. Can also be bulk-loaded via Data Loader / API during catalog migration.
ProductComponentGroup
RC-Standard
Groups related components within a bundle for display and selection rules — analogous to CPQ's
SBQQ__Feature__c but model-layer only (no min/max enforcement natively).NameParentProductIdSequenceDescription
Created by: Product Manager via the Components tab on a Bundle product. Displayed in the configurator UI as collapsible group headers.
AttributeDefinition
RC-Standard
Defines a reusable attribute (Color, Storage, License Tier, etc.) that can be assigned to attribute sets and presented in configurator/catalog UI. Supports text, picklist, boolean, and number types.
Name,DeveloperNameDataType— Text / Picklist / Number / Boolean / DateDefaultValueIsRequiredIsSearchable
Created by: Catalog/RevOps admin via Attribute Definitions setup tab. Created once and referenced by multiple
ProductAttributeSet records. API-name is immutable after save.
AttributePicklist / AttributePicklistValue
RC-Standard
Manages controlled picklist values for Picklist-type attributes. Separate from Salesforce standard picklists — allows context-specific value filtering per product type.
AttributePicklist.Name,DeveloperNameAttributePicklistValue.NameAttributePicklistValue.SequenceAttributePicklistValue.IsDefault
Created by: Catalog admin via the Attribute Definition detail page. Values can also be bulk-loaded; used in Advanced Configurator (IndustriesConstraints) constraint rules.
How RC Catalog Objects Get Created
| Object | Creation Method | Who Creates It | Frequency | Notes |
|---|---|---|---|---|
ProductCatalog |
Products & Catalog app → Catalogs tab | Catalog / RevOps Admin | Once (1–3 per org) | Scopes channel exposure; requires Status = Active to appear in runtime |
ProductCategory |
Products & Catalog app → Categories tab, or Data Loader bulk | Product Manager / Admin | Initial build + as taxonomy evolves | Supports parent nesting; changes immediately visible in browse/search |
Product2 |
Products & Catalog app → New Product wizard, or Data Loader / API | Product Manager | Ongoing (each new SKU) | Wizard sets Class (Simple/Set/Bundle), attaches Attribute Set, and links Selling Model in one flow |
ProductSellingModel |
Products & Catalog app → Selling Models tab, or API/Data Loader | Pricing / RevOps Admin | Low (shared templates) | Defined once, reused across many products; drives billing schedule generation downstream |
AttributeDefinition |
Setup → Attribute Definitions, or API | Catalog Admin | Low (library grows over time) | DeveloperName immutable after creation; plan naming convention before first use |
ProductAttributeSet |
Products & Catalog app → Attribute Sets tab | Catalog Admin | Low–Medium | Groups related AttributeDefinitions; linked to products via ProductClassification |
ProductClassification |
Auto-created when Attribute Set is assigned to a product in the wizard | System (via product wizard) | Per product | Junction between Product2 and ProductAttributeSet; rarely created manually |
ProductRelatedComponent |
Bundle product → Components tab in Products & Catalog app, or Data Loader | Product Manager | Per bundle | Replaces SBQQ__ProductOption__c; bulk-loaded during CPQ migration |
ProductComponentGroup |
Bundle product → Component Groups tab | Product Manager | Per bundle | Optional grouping for display; no native min/max enforcement (use Constraint rules) |
ProductCategoryProduct |
Auto-created when a product is assigned to a category in the wizard, or Data Loader | System / Product Manager | Per product-category assignment | IsPrimaryCategory flag drives default breadcrumb; a product can belong to multiple categories |
AttributePicklist / Value |
Attribute Definition detail page → Values tab, or Data Loader | Catalog Admin | Per picklist attribute | Values used by Advanced Configurator constraint rules; separate from Salesforce global value sets |
🖥️
Product Manager UX — Products & Catalog App
The Products & Catalog app (Lightning app included with Revenue Cloud) is the primary UI for catalog setup. It provides a guided New Product wizard that walks through: (1) set Product Class → (2) assign Attribute Set → (3) attach Selling Model → (4) assign to Category → (5) set pricing. This wizard auto-creates
ProductClassification and ProductCategoryProduct junction records behind the scenes. For bulk catalog loads (migrations, ERP-sourced catalogs), Data Loader or the REST/Bulk API is used — object order matters: Catalogs → Categories → AttributeDefinitions → AttributeSets → Products → Classifications → Components.
Products & Catalog App — New Product wizard and catalog setup UI
⚠️
End-User Interaction vs. Admin Setup
Catalog objects are never created by end-users (sellers, buyers). All Product2, Category, Attribute, and Selling Model records are pre-configured by admins before a quote or cart session begins. End-users interact with catalog data only at runtime — via the CPQ configurator, the Experience Cloud storefront, or the Agentforce quote agent — which reads catalog records but does not write to them. The only runtime-written catalog-adjacent record is
ProductSellingModelOption, which is generated when a transaction line selects a selling model.
Key Takeaway — 1.3
CPQ's data model is dense with SBQQ__ custom objects tightly coupled to the configurator UI. Revenue Cloud's model is more normalized — separate objects for categories, attribute sets, relationships, and classification — but requires more joins to reconstruct a full product view. For migration, the hardest mapping is SBQQ__ProductRule__c: there is no direct declarative equivalent in RC and the logic must be reimplemented in Flow or custom code.
⚡ RC Admin: Product Catalog Search Index
Revenue Cloud's Browse Products modal does not query Product2, ProductCategoryProduct,
and PricebookEntry records live. When "Use Indexed Data for Product Listing and Search"
is enabled in Setup → Product Catalog Management → Search Settings, the modal reads from a
pre-computed search index instead. This index is a snapshot of all catalog
products, their categories, attributes, selling models, and pricing — optimised for fast browse and search.
WHY CATEGORIES LOAD BUT PRODUCTS DON'T
The left-nav category list is loaded directly from ProductCategory records — no index needed.
The product grid on the right reads the index. If the index has never been built (or was cleared after an org
reset), the grid returns "Something went wrong when retrieving products" even though the data is perfectly
configured in the org.
HOW TO BUILD / REBUILD THE INDEX
- Go to Setup → search "Product Catalog"
- Navigate to Product Catalog Management → Product Discovery → Search Settings
- Ensure "Use Indexed Data" is Enabled
- Click "Create Full Index"
- Wait 30–60 seconds — the background job indexes all active catalog products
- Return to the Quote and open Browse Products — products will now appear
When to rebuild: After bulk product imports, after org refreshes/resets, after enabling "Use Indexed Data" for the first time, or whenever Browse Products stops showing products that you know exist in the catalog. The index is not auto-rebuilt on product record changes — it must be triggered manually or scheduled via the RLM Rebuild Search Index Screen Flow in Setup → Flows.
1.4
Automations
CPQ Automations
- Product Rules — Validation: Blocks quote save when conditions are violated; error displayed to user
- Product Rules — Selection: Auto-adds or removes options when trigger conditions are met
- Product Rules — Filter: Hides/shows options or quote lines based on field values
- Product Rules — Alert: Non-blocking warning message surfaced in configurator
- Configuration Attributes: Drive dynamic filtering of options; read field values and apply to OptionConstraints
- Dynamic Bundle Inclusion:
SBQQ__DynamicOptionCondition__c— conditionally includes component products - Price Actions (via PriceRule): Trigger price overrides or discounts on product selection
- Quote Calculator Plugin (QCP): JavaScript plugin for complex calc logic beyond declarative rules
Revenue Cloud Automations
- Product Eligibility Rules:
ProductQualification/ProductDisqualificationgate which products are eligible within a hierarchy context; bundle component roles are typed viaProductRelationshipTypeonProductRelatedComponent - Product Lifecycle Management Flows: Auto-launch Flows on lifecycle state transition (Draft → Active → Retired)
- Auto-launch Flows on Product Add: Triggered via Platform Events when product added to cart/quote
- Change Data Capture (ProductCatalogChangeEvent): CDC events fire on ProductCatalog record changes; subscribe via Apex trigger or CometD to notify downstream systems (OMS, ERP)
- Decision Tables: Attribute-driven product recommendations; replaces rule-based selection
- Flow Screen Components: Custom attribute validation using invocable Apex or Flow
- External PIM Webhooks: Catalog sync via connected app + REST callbacks
| Automation Type | CPQ Equivalent | RC Equivalent | Trigger | Outcome |
|---|---|---|---|---|
| Block invalid combination | Product Rule — Validation | Flow on cart save + custom validation | Quote/cart save | Error message; blocks save |
| Auto-add required product | Product Rule — Selection (Add action) | Flow (auto-add logic) + ProductQualification (eligibility gate) | Option selection event | Product auto-added to lines |
| Auto-remove incompatible product | Product Rule — Selection (Remove action) | Flow (remove logic) + ProductDisqualification (eligibility gate) | Conflicting product selected | Incompatible product removed |
| Filter visible options | Product Rule — Filter + Config Attributes | Attribute-driven category filter + Decision Table | Attribute value change | Option list filtered dynamically |
| Non-blocking alert | Product Rule — Alert | Flow toast / Screen Component | Rule condition met | Warning shown; save not blocked |
| Substitute product recommendation | Guided Selling (custom flow) | Decision Table + custom LWC recommendation component | Product view / add | Alternate product surfaced |
| Lifecycle state transition | N/A (manual field update) | Product Lifecycle Flow (auto-launch) | Status field change | Related records updated, events fired |
| Downstream system notification | Apex trigger on Product2 | CDC Event (ProductCatalogChangeEvent) | Catalog change | ERP/OMS notified via event bus |
| Complex calc/pricing from config | Quote Calculator Plugin (QCP) | Pricing Procedure + Pricing Element | Cart/quote calculation | Price computed from attribute values |
Automation Gap to Know
CPQ's four Product Rule types (Validation, Selection, Filter, Alert) are fully declarative with zero code. Revenue Cloud has no direct equivalent — complex rule logic requires Flow, Apex invocable methods, or Decision Tables. For orgs migrating from CPQ to RC, budget time to re-implement all Product Rules in Flow; this is typically the largest hidden effort in a migration.
Key Takeaway — 1.4
CPQ's automation model is deeply declarative for configuration rules — admins can build sophisticated include/exclude/validation logic without code. Revenue Cloud's automation model is event-driven and Flow-centric, offering more flexibility for lifecycle and integration scenarios but requiring development effort for configuration rules that CPQ handles declaratively. Architects must plan for this paradigm shift during transition planning.
1.5
Configuration — Architect Setup Effort
Effort ratings assume a mid-complexity product catalog (~100–500 SKUs, 10–30 bundles). Actual effort scales with catalog size and rule complexity.
| Configuration Task | CPQ Effort | RC Effort | Notes |
|---|---|---|---|
| Product hierarchy setup (families, sub-types) | Medium | Medium-High | RC requires ProductCategory tree + ProductCategoryProduct assignments in addition to Product2 Family |
| Bundle / option configuration | High | Medium | CPQ requires Features + ProductOptions + OptionConstraints per bundle. RC uses ProductRelatedComponent + ProductComponentGroup typed via ProductRelationshipType (less setup per product, less granular constraint control) |
| Attribute / variant setup | Medium | High | CPQ: Configuration Attributes on Product2 fields. RC: must create AttributeSet → ProductAttribute → ProductClassification → optionally AttributeCategory for each product type |
| Constraint / rule setup | High | Medium | CPQ: ProductRules + Conditions + Actions per scenario — very granular, very powerful. RC: ProductQualification / ProductDisqualification handle eligibility gating; behavioral rules (auto-add, exclude, recommend) require Flow |
| Category taxonomy design | N/A | High | CPQ has no native category taxonomy — Product Family picklist only. RC requires deliberate IA design; changes to hierarchy are risky post-go-live |
| Price book linkage | Low | Low-Medium | Both use PricebookEntry. RC additionally requires a ProductSellingModel with PricingTerm / PricingTermUnit for subscription pricing; adds 2–3 config steps |
| Community / Partner catalog | Medium | Medium | CPQ: Profile-filtered pricebook + Community CPQ license. RC: Catalog visibility via Commerce entitlement or headless API; comparable effort, different tech |
| Headless catalog API | N/A | High | Not available in CPQ. RC: requires Commerce entitlement, webstore setup, API authentication, and custom front-end integration against the Commerce Catalog REST API |
| Product lifecycle management | Low | Medium | CPQ: IsActive toggle on Product2. RC: formal lifecycle states (Draft → Active → End of Sale → Retired) with Flow automation; more control but more setup |
| Initial data load (ETL) | High | High | Both require ordered ETL: products first, then relationships/bundles/attributes. RC has additional FK dependencies (AttributeSet before ProductClassification) |
Effort Legend
Low < 1 week | Medium 1–3 weeks | High 3–6 weeks | Very High 6+ weeks | N/A Feature not available
Key Takeaway — 1.5
CPQ has higher per-bundle setup effort due to the Feature/Option/Constraint object chain, but that investment pays off in declarative rule power. Revenue Cloud has higher up-front taxonomy and attribute modeling effort — the category hierarchy and attribute set design must be right before loading data. Both platforms have high ETL complexity for initial catalog loads; plan 20–30% of catalog build time for data quality and load sequencing.
1.6
Customization — Common Additions
CPQ Customizations
-
Apex triggers on
SBQQ__ProductOption__c: Dynamic option filtering based on Opportunity or Account data not available in declarative rules; executes before/after option record upsert during bundle load -
Custom LWC replacing CPQ Configurator UI:
Fully custom configurator UI using CPQ's
cpq-configuratorlibrary or calling SBQQ REST API directly; used when standard configurator UX is insufficient - Visualforce pages (legacy): Older implementations still use VF-based configurator overrides; being deprecated in favor of LWC
-
Custom fields on Product2 surfaced in configurator:
Configuration Attributes expose custom Product2 fields as filterable dimensions; add
SBQQ__ConfigurationAttribute__crecords pointing to custom field API names - Quote Calculator Plugin (QCP): JavaScript plugin for per-line or aggregate price logic tied to configuration choices; runs server-side inside CPQ engine
Revenue Cloud Customizations
- Custom LWC for catalog browsing (headless pattern): Invoke the Commerce Catalog REST API from LWC; build fully custom browse/filter/search UI while keeping RC as catalog backend
-
Flow extensions for complex attribute validation:
Screen Flow with invocable Apex validates attribute combinations that can't be expressed via
ProductQualification/ProductDisqualificationcriteria expressions - External PIM integration via REST API: Scheduled or event-triggered REST inbound to sync product records, attributes, and categories from PIM (Akeneo, Informatica, etc.) into RC catalog objects
- Custom product recommendation engine: Decision Tables + custom ML model output stored in custom object; surfaced via LWC recommendation component on catalog page
-
Platform Event subscriber (catalog sync):
Subscribe to
ProductCatalogChangeEvent(CDC) from external OMS/ERP via CometD or Apex trigger to react to catalog record changes in near-real-time
CPQ Anti-Patterns — Do NOT
- Do NOT write Apex triggers that modify
SBQQ__Quote__clines during the CPQ calculation cycle — causes infinite recalculation loops - Do NOT bypass CPQ's save mechanism with direct DML on quote lines — breaks calculated fields and price waterfall
- Do NOT create more than ~150 Product Rules per org — performance degrades significantly above this threshold
- Do NOT use Configuration Attributes to store pricing logic — keep pricing in Price Rules, not Product Rules
- Do NOT nest bundles more than 2 levels deep — CPQ configurator rendering becomes unpredictably slow
Revenue Cloud Anti-Patterns — Do NOT
- Do NOT restructure ProductCategory hierarchy post go-live without a full data migration plan — category IDs are referenced in many records
- Do NOT use before-insert Apex triggers on Product2 to enforce attribute rules — use Flow invocable to stay within RC's transaction model
- Do NOT assign a product to more than one AttributeSet of the same type — causes attribute rendering conflicts in catalog UI
- Do NOT poll the Commerce Catalog REST API synchronously inside a Flow — use async CDC event subscription for catalog-driven automation
- Do NOT replicate CPQ OptionConstraint logic 1:1 using
ProductQualification/ProductDisqualification— these are eligibility gates, not behavioral rules; use Flow for auto-add/remove behavior
| Customization Pattern | CPQ Approach | RC Approach | Complexity |
|---|---|---|---|
| Replace configurator UI | Custom LWC calling CPQ REST API or cpq-configurator library | Custom LWC + Commerce Catalog REST API (headless) | High |
| Dynamic option filtering | Apex on SBQQ__ProductOption__c or QCP | Flow + Decision Table + custom Apex invocable | Medium |
| Complex attribute validation | ProductRule (Validation) — declarative | Screen Flow + Apex invocable | CPQ: Low / RC: Medium |
| External PIM sync | REST inbound → Product2 + SBQQ__ managed fields; Apex upsert | REST inbound → Product2 + Category + AttributeSet objects; ordered ETL | High |
| Recommendation engine | Guided Selling Flow (CPQ+) or custom LWC | Decision Tables + custom LWC recommendation component | Medium |
| Downstream system notification | Apex trigger on Product2 / Outbound Message | Platform Event subscriber (event-driven, decoupled) | CPQ: Medium / RC: Low |
Key Takeaway — 1.6
CPQ customizations are tightly coupled to SBQQ__ managed package patterns — always extend via supported hooks (QCP, Configuration Attributes, Product Rules) rather than direct DML on managed objects. Revenue Cloud's headless-first architecture is inherently more customization-friendly for UI and integration scenarios, but the absence of a declarative rule engine means validation logic requires developer involvement. For catalog-heavy, API-first implementations, RC's customization patterns are more composable and future-proof.