Salesforce CPQ: RequiredBy Field

In the world of Salesforce CPQ, price rules are an invaluable tool for automating and managing the complex pricing scenarios businesses often face. However, as anyone who has worked with Salesforce CPQ will know, managing performance while maintaining accurate business logic can be a challenging balancing act. This was the situation we found ourselves in when troubleshooting one price rule.

The price rule in question was used for calculating the quote line pricing for a specific product, relying on a formula within a price action. If SBQQ__RequiredBy__c was not blank (meaning that the product is part of a bundle), it calculated the price based on a related field (SBQQ__RequiredBy__r.Total_Subscription_Fees__c) multiplied by a percentage field. If it was blank, the formula simply fell back to the Original Price.

However, the formula was causing delays in calculations, negatively affecting the user experience. We needed to find a way to optimize this price rule.

We first examined the SBQQ__RequiredBy__c field, a relationship field in Salesforce CPQ that looks up "Quote Line of the parent product for any Quote Lines representing Product Options". We simplified the price action to include only the field reference SBQQ__RequiredBy__r.Total_Subscription_Fees__c, removing the IF condition entirely. Interestingly, with this setup, the data was being fetched promptly. 

The catch is that the SBQQ__RequiredBy__c  field itself remains unpopulated until a Save action writes to the database and creates the Quote Lines associated to the Quote. This complicates things because the calculation sequence would need to be triggered a second time to access bundle hierarchy information meaning that the Sales Rep would have to click Quick Save, then Calculate to see the price calculated correctly. 

Our proposed solution? Either leverage QCP or find a different workaround. We changed the reference field in the formula: we chose SBQQ__OptionLevel__c, which is a standard field in Salesforce CPQ that denotes the level of a product option in a bundle. By checking if SBQQ__OptionLevel__c was blank instead of SBQQ__RequiredBy__c, Salesforce could determine the condition immediately with no delay.

With this modification, we observed a considerable improvement in calculation times, effectively optimizing the price rule. This case study underscores the importance of a thorough understanding of the Salesforce CPQ data model for effective troubleshooting and optimization. While the necessity for accurate business logic remains paramount, exploring alternative methods to achieve the same results can lead to significant performance improvements.