HCL Commerce Enterprise

Best practices for price rules

Review these best practices for creating price rules so you can learn ways to simplify price rule maintenance and reduce performance impacts.

1. Reuse components in your price rules

With careful planning, you can find ways to reuse components in price rules. For example, you can:
  • Reuse the same price equation in multiple price rules.
  • Reuse the same price constant to calculate a new price in more than one price equation.
  • Reuse the same price list in multiple price rules.
  • Nest price rules that contain a common set of pricing instructions within other price rules.
This way, it is easier to maintain a set of price rules that are based on reusable components. You can make a change to the reusable component, and all price rules that use the component are updated automatically.

2. Give price rule components meaningful names

One real advantage of price rules is that they display in a graphical format in the Price Rule Builder. To optimize the readability of your price rules, make sure you assign meaningful names to:
  • Price rules and price lists
  • Paths in branches
  • Price equations and constants

The following best practices relate to minimizing performance impacts of price rules. If your site is experiencing performance issues, you can review your price rules based on these best practices and make any necessary adjustments.

3. Place conditions that are most likely to be met on the first path in the price rule

One way you can minimize the performance impact of price rules is by ordering the conditions in the price rule like this:
  • Place the condition that is most likely to be met on the top path.
  • Place the condition that is the second most likely to be met on the second path, and so on.
This reduces the number of conditions that must be checked each time a customer views a catalog entry on the storefront. Consider a price rule that uses the Customer Condition to differentiate prices for three member groups; however, one member group has significantly more customers than the other two. To minimize performance impacts, specify the member group with the most customers in the condition on the top path.

4. In a price rule with conditions, the path with no conditions must be the bottom path

Typically, you should not add a condition element to the bottom path in a price rule. The bottom path should set pricing for any catalog entries or customers that do not meet the conditions on the other paths. Using a bottom path with no conditions ensures that your price rule can generate a price for all catalog entries and all customers that the price rule must handle. This prevents the situation in which catalog entries on the storefront show "No Price Available" because the price rule cannot output a price. Customers cannot purchase catalog entries that do not have a price. Make sure it is the bottom path, and not some other path, that has no condition. When the price rule reaches a path with no conditions, no additional paths below that path are used for pricing.

5. Limit the nesting depth for nested price rules

You can nest a price rule within another price rule, and then nest that price rule within another price rule, and so on. The more nesting you do, the greater the impact to performance.

6. Limit the number of Condition Branches in a single price rule

To handle complex pricing logic, you can have more than one Condition Branch in a price rule. The more Condition Branch elements you include, the greater the impact to performance.

7. Use the Coordinator Branch wisely and only when necessary

Consider this: if you use a Coordinator Branch that contains 20 paths, then HCL Commerce must run 20 price rules to come up with the prices to compare. This amount of processing can affect performance. For this reason, try to limit the use of the Coordinator Branch in your pricing strategy. If you do use it, try to keep the number of paths in the Coordinator Branch to a minimum.