Recommendations to Improve CPQ Performance

This section describes the recommendations to improve the performance in different areas of CPQ.

Catalog Page

• If there is only one category, enable the Hide top level category setting to display subcategories as categories.
• Remove subbundles from parent bundles and treat subbundles as separate products.
• Use product structure (such as bundles), not rules (such as constraint, validation) wherever possible.
  For example, there is a requirement to include Product B if the user selects Product A. If you model A and B as standard items and a constraint rule to include B for A, this is not an optimal way of modeling. Instead, create bundles and auto-include Product B when the user selects bundle Product A.
• Minimize the number of options
  • Remove inactive options (end of life products) from bundles periodically.
  • Add products (options) to the price list in the region where they are sold.
  • Remove non-priced options from the bundle structure. Use attributes instead.
  • Avoid creating options for non-tangible products. Use attributes instead. For example, a country should be an attribute and not an option.
  • Set frequently used options as default.
• Avoid SKU proliferation (creating multiple instances of the options to handle quantity-based pricing).
• Leverage the Price included bundle option wherever applicable.
• Avoid creating duplicate data to maintain quality.
• Standardize naming conventions for rules and attributes.
• Use multiple option groups instead of maintaining all options under one option group.
• Create and manage Public favorite configurations effectively on the Catalog page. Use Private favorite configurations instead.
• Reuse and share configurations through favorites.

Cart Page

• Filtered lookup columns on the cart may impact CPQ performance.
• Manage the pricing callback code efficiency.
• Avoid defining multiple deal guidance setup for a single criteria.
• Avoid customizing a large cart.
• Verify if Option Groups with Max Cardinality = 1 can be used as picklist values.

Rules

• Keep the use of Product Visibility Rules to minimal to optimize catalog load performance. Create a separate price list or constraint rule.
• Create option specific rules. You can configure rules for common options without being specific to bundles.
• Define the criteria in a constraint rule condition wherever applicable, instead of constraint rule action criteria.
• Reduce the number of constraint rules by merging the constraint actions with similar conditions.
• Write your criteria on one condition. Do not repeat criteria on other conditions.
• Use client-side constraint rules to get better CPQ performance, that is, avoid server round-trip.
• Avoid using Formula fields in Constraint Rule Action criteria especially when you are using client-side constraint rules. Instead, use Conga numeric expressions.
• Avoid using formula fields on constraint rule conditions
• Avoid nested rule conditions.
• Avoid rules where the scope includes both bundles and options.
• Avoid creating redundant rules.

• Avoid creating multiple conditions with the same product when using AND association. The following table illustrates an example.

  Constraint Rule Field	Value
  Condition 1	Product A
  Condition 2	Product A with Attribute A
  Association	1 AND 2

  In the above-mentioned example, the condition is only fulfilled when both instances of the product are added to the cart.

• Do not create a server-side constraint rule with constraint condition using a formula field attribute from Product Attribute Rule Extension object.

Installed Product Page

• The number of renewals per trip is 20 by default. To avoid CPQ time out, reduce the number in the Max Renews Per Trip setting in Installed Products Settings.

Pricing on Cart

• Use Conga expressions wherever possible.
• Price Batch Size
  • The Price Batch Size must be high (higher the value faster the performance).
  • Define Price Batch Size correctly.
  • Measure and evaluate the highest possible value. Do not set up a value that can result in governance limits.
• Enable defer pricing only if the user experience is impacted (performance latency). Enabling defer pricing can increase the latency in the step when pricing is executed.
• Use the Compute Totals In Separate Step setting to avoid the CPU time limit issue to a large extent. This setting indicates whether the totaling should be performed in a separate step or if it should be combined with the base pricing step. This setting ensures that the totaling, which is dependent on the number of lines, is done as a separate remoting call.
• Manage deal guidance rules.
  • Consolidate rules wherever possible.
  • Simplify cross object fields.
  • Deal guidance limit varies based on the pricing complexity, number of lines, and deal guidance complexity.
• Manage the pricing callback code efficiency. For best practices for defining pricing callback, see Pricing Callback Classes.