The Product Relationship object is the standard, purpose-built tool for modeling complex product structures like bundles, kits, and substitutes. It allows you to define parent and related products with specific relationship types (e.g., Bundle, Component, Substitute), which is crucial for accurate pricing roll-ups and hierarchical reporting. A self-lookup on Product is too simplistic for many-to-many relationships, a custom junction object reinvents standard functionality, and Assets represent sold instances, not the sellable product definition.

At a minimum, a functional Simple Price Rule requires a Condition (to define WHEN the rule should run, e.g., ‘Product Category equals Electronics’) and a Target Action (to define WHAT the rule should do, e.g., ‘Apply a 10% Percent Discount’). A Schedule is only required for Subscription rules, and Eligibility Criteria are used for more complex rule filtering but are not a minimum requirement for a Simple rule to work.

Product Rules are specifically designed to dynamically filter which products are available in the Product Selection UI based on conditions (like the presence of another product on the quote). This proactively guides the user. A Validation Rule would be reactive, blocking saving after the fact. A Price Rule manages pricing, not product availability. A Workflow alert is a workaround, not a controlled enforcement of the business logic.

A Discount Schedule is the standard mechanism for applying a discount that decays or changes over specific subscription periods. You can set it to apply a 20% discount for the first 3 periods (months) and 0% thereafter. This schedule is then attached to the product via a Price Rule. Contracted Prices override list price but don’t have built-in time-based decay. A prorate discount applies to the first invoice calculation, not a multi-month promotion. A Price Rule with an expiration date manages the rule’s active period, not the duration of the applied discount on the subscription itself.

`SBQQ__ListPrice__c` represents the base price of the product as defined in the active Price Book Entry. `SBQQ__CustomerPrice__c` is the calculated result after all applicable discounts, surcharges, and pricing rules have been applied. It is the net price the customer will pay per unit before any additional quote-level adjustments.

In CPQ, separation of concerns is key. Approval Rules are specifically designed to manage the approval workflow process (routing, criteria, approvers). Price Rules are designed to manage pricing logic (discounts, markups). These are distinct functionalities handled by different rule engines. Combining them into one rule type or using standard workflow/validation is not the correct, scalable CPQ pattern.

The `SBQQ__SubscriptionTerm__c` field defines the length of the subscription in months. This term, multiplied by the recurring charge (adjusted for billing frequency), is fundamental to calculating the Total Contract Value (TCV). The Start Date begins the term, Billing Frequency determines how often charges occur within the term, and Additional Discount affects the net price, but the Term is the core multiplier for TCV.

The ‘Evaluate’ checkbox on a Price Rule is a master switch that determines if the rule’s logic should be executed during quote calculation. If it is unchecked, the rule will be ignored entirely, even if all conditions are met. This is a frequent oversight during configuration and the first thing to check when a rule isn’t firing. Quote status, user permissions, and configuration requirements do not prevent a correctly configured rule from evaluating.

The `SBQQ__ChargeType__c` field is fundamental to defining the revenue recognition pattern in CPQ. A ‘One-Time’ charge type recognizes revenue fully upon invoicing/delivery. A ‘Recurring’ charge type recognizes revenue ratably over the `SBQQ__SubscriptionTerm__c`. This is the standard, out-of-the-box way to model this common business scenario. Billing Type (`SBQQ__BillingType__c`) controls invoice timing, not revenue recognition.

The Product Relationship object is the standard, purpose-built tool for modeling complex product structures like bundles, kits, and substitutes. It allows you to define parent and related products with specific relationship types (e.g., Bundle, Component, Substitute), which is crucial for accurate pricing roll-ups and hierarchical reporting. A self-lookup on Product is too simplistic for many-to-many relationships, a custom junction object reinvents standard functionality, and Assets represent sold instances, not the sellable product definition.0