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 Commerce+ Transaction Server 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.