Salesforce CPQ: Option Constraints vs Product Rules

After setting up the product features and product options, the normal course is to start building further rules around the configuration experience through Option Constraints and Product Rules.

Both are extremely useful, although Option Constraints can be viewed as early versions of Product Rules, and Product Rules are considered to be more powerful. They are also more scalable - once you set them up, you can scale them across different bundles instead of having to set them up on every single bundle individually. However, Option Constraints and Product Rules have different use cases. There are differences between them you should bear in mind when deciding which functionality to use.

First of all, Option Constraints cannot select products automatically for you (although they can deselect products when dependency applies). Basically, they are really good at two scenarios: dependency and exclusion. Automatically selecting a product is an advantage of the Product Rules whose main uses cases are validation and alert within a configuration or on a quote line editor and product selection within a configuration. Product Rules can also be used for product filters in dynamic bundles. So, they can Add or Remove products, Show or Hide, Enable or Disable. Option Constraints can't do all these.

Furthermore, and this can be considered as a benefit of Option Constraints - they allow for real-time processing. Thus, the feedback is immediate to the user instead of having to trigger a rule calculation sequence. Whenever the user selects or deselects an option, the dependency or the exclusion fires immediately. While with Product Rules, there is the Apply Immediately checkbox to indicate that a certain Product Option should trigger a rule evaluation event. For Product Rules, it is required to choose an evaluation event to specify when Salesforce CPQ should consider and run a product rule: Load, Edit, Save, or Always.

What's also good to know about Option Constraints is that dependency and exclusion have innate logic built-in - for example, when conditions are not met anymore, the options are deselected automatically and grayed out immediately. Product Rules fire very specifically. If the conditions are met, the actions are fired. Within a Product Rule, it's necessary to define all the logic for your product rules because if you set up a rule to add products, this doesn' mean the reverse will apply automatically. 

That's it! We hope this blog post will help you next time you have to decide which functionality to use when building further rules around the configuration experience.