Salesforce Industries CPQ and Communications Cloud is one of the best BSS solutions in the Telecom Industry for asset and order management. Let see How To Reduce Advanced Product Rule Usage In Industries CPQ.
The software offers industry-specific data models and frameworks that can be used to create a solution that meets your business needs. You are able to display customer data such as account, order, and asset information to equip your reps with the coveted customer 360 experience.
Some of the main features of Industries CPQ are Asset-Based Ordering, Multi-Site Quoting, Order Management, CLM, and the Enterprise Product Catalog.
In this article, we will focus on the Enterprise Product Catalog (EPC) and how to reduce advanced rule usage to align with product modeling best practices.
What Are The Types Of Product Rules
Context Rules and Advanced Rules are the two main types of rule frameworks for product configuration in Salesforce Industries CPQ. Context rules match a pre-defined static value to a dynamic value. The dynamic value is either a context dimension or the output of a function. Advanced rules are built using product relationships and entity filters.
Entity filters are used to identify when a certain condition is true, and the product relationship is used to define the type of enforcement or action which needs to be executed.
Product relationships can also be used to define action parameters that outline actions such as attribute assignment or constraints. While both of these frameworks are useful, a product catalog should avoid using these when possible.
Of course, these type of rules have their place, but just like creating custom APEX functionality, you want to exhaust simpler solutions using more maintainable and static patterns.
Dynamic Vs Static Rule Enforcement
Product catalogs can help order capture and quoting software enforce business requirements to ensure correct configuration. This is done by using a combination of static product modeling patterns and dynamic rules.
A good product model should be as static as possible. This ensures there is less room for configuration errors and fewer dynamic rules need to be executed to ensure business requirements are enforced.
Dynamic rules which can be defined in Industries CPQ are context rules and advanced rules. In addition, it is possible to customize pre and post-invoke hook logic which executes around the cart and DC-based APIs.
However, static rule enforcement should be a priority of product modeling. Strategies product modelers use to statically enforce business requirements generally leverage product structure and cardinality.
Product structure is the static relationship between products. This follows a one-to-many parent-child hierarchy. Cardinality is a framework used to specify the minimum, maximum, and default number of specific line items which can exist within a product structure or ‘bundle’.
There can be group cardinality and local cardinality defined. Local cardinality is used to define the minimum, maximum, and default number of line items that can exist for a specific product.
Group cardinality enables you to specify the minimum and the maximum number of children under a parent product. For example, if a parent product has a group cardinality max equal to 5 and group min equal to 0, this means the parent product can have between 0 and 5 child line items.
Note: the group minimum and maximum only are respected for the direct children of the group cardinality defined.
How To Reduce Requires Compatibility Rules
A requires compatibility rule is a product relationship defined between two products and follows the format: product x requires product y. This is a dynamic rule which creates a dependency between two products.
A logical real-world example might be when there are product entities representing TV channels that require a TV service in order to be purchased. In this scenario, the compatibility rule would look something like TV Channel requires TV Service.
While this rule would enforce the business requirement of a TV channel requiring a TV service, this is a reactive dynamic rule. Additionally, there is typically more than just one TV channel offering and a rule would need to be created for each of these channels.
So, as the number of channels increase, so do the number of rules and hence from a scalability perspective, this approach does not hold.
To avert this issue you can use product structure to statically enforce this business requirement.
By having the TV channels as a child product of the TV service, the dynamic requires compatibility rules are no longer needed.
For the TV channel products to become available to add to the cart, the user must first add the top-level TV service product, thus meeting the defined business requirement without needing a large number of dynamic rules.
By using this approach the solution becomes more elegant from a configuration and maintenance perspective compared to using compatibility rules.
How To Reduce Auto-Add Compatibility Rules
Auto-Add rules are a type of product relationship which as the rule implies, auto-adds a product based on the addition of another product. This type of rule would be defined as TV Service Auto-Adds TV Channel. CSPs generally offer TV packages that come with included channels or equipment that might need to be auto-added when a certain TV service product is added to the cart.
By using Auto-Adds rules, the process of adding these included products and services can be automated using the auto-add rules. While using auto adds rule to meet this business requirement is possible, it is often not the best pattern to be used.
Similar to the argument for not using requires rules, this dynamic rule would need to be configured for every included product and service included within the parent TV package. Not the best for scaling and maintenance of rules.
Fortunately, you can use product structure and cardinality to statically define these enforcements to avoid the high number of dynamic rules which would otherwise be needed.
To improve the product model, you can make the products included with the parent product children with the local cardinality defined as 1,1,1.
What this means is that the child product which needs to be included will be added by default, cannot have more than one line item, and cannot have less than one line item. Max = 1, Min = 1, and Default = 1.
As you can see, this configuration is statically defined in the product model and does not require the configuration of advanced rules to enforce the automatic addition of products based on a product relationship.
Final Thoughts
Product modeling best practices attempt to remove as many dynamic rules from the product catalog as possible through the use of techniques such as product structure and cardinality.
Dynamic rules such as context rules and advanced rules in Industries CPQ can have performance implications, require more rule configurations and lead to more catalog maintenance.
In order to avoid these issues, product modelers can leverage static product configurations to meet business requirements without creating large quantities of product relationships and advanced rules. I hope this helped you to learn how To Reduce Advanced Product Rule Usage In Industries CPQ.
