I am making a bold prediction that this post will receive the most views over time. Especially compared to other technical posts. And here is why, Price Rules to CPQ is both the core and the most misunderstood feature. Most people read the help manual or trailhead and believe they understand how Price Rules work. This is where most fail.
Why? Simply put, most admins write far too many price rules or don’t appreciate how one price rule influences another. I’ve done it quite a bit and so I speak from experience. Let me help ya…
The Order of Things
We have 4 times that rules are considered when CPQ starts and does a calculation cycle. During each event, the Calculation Sequence runs and there are variations in the sequence depending on the event. But for most situations, the differences do not influence us heavily. We need to have each rule be assigned to at least one event and have an order.
All events are run every time a calculation is asked for EXCEPT for “on initialization” which is only run once when you “Edit Lines” and enter the CPQ Visualforce pages. Be careful with this event. Typically the best use for this event is to clear any fields that hold Summary data since the rules will refactor those values.
What CPQ doesn’t tell you in the documentation clearly enough is that for each event, CPQ queries the Price Rule object for all rules that will apply to the Quote and Quote Lines. This means that if I have two price rules on the same event, what I can’t do is have the effect of one price rule be the condition for the second rule. Take a moment and re-read that sentence. How about an example:
- Price Rule 1 – If the quote is based in Canada then set the Country field to Canada
- Price Rule 2 – If the Country field = Canada then update the text field Sport to “The New York Rangers are bozos”
The problem with the above, besides taking the hockey team debate out of the equation, is that the first price rule’s action is trying to influence the second price rule on the same event. CPQ will NOT process both of these rules during the same Calculation cycle.
The only way for a user to see this working correctly is to press the “Calculate” button twice so that the values are available. We call this a “Double Calculate” problem and everyone who has ever worked in CPQ has created this problem.
You need a function like this to work? Then the two rules need to be on different Calculation Events. This is described in this Salesforce article about halfway down.
When two price rules share an evaluation event, the earliest-firing price action’s target field value isn’t usable in the other rule’s price condition. Salesforce CPQ evaluates all an evaluation event’s conditions simultaneously. Actions then fire sequentially for rules whose conditions have been met. An action from one rule in an evaluation event can’t influence the conditions of another rule in the same evaluation event.
(now you know why the hockey reference was used.. that’s a bit heavy.)
HOWEVER while evaluation order is super most helpful, if we want to use the RESULTS of one Price Rule in another within the same Event. Totally cool and encouraged.
An example from a prior project:
- Query for the correct interest rate based on business line, date, and dollar amount being financed. Set that value on the Interest Rate field on the quote line
- Use that value in a formula calculation for Scheduled Payment on the same quote line
All in the same event. No worries. Works like a champ. The value of the Interest Rate is not being used in the criteria. Instead it’s usage is in the Price Action. CPQ loves that.
How does all of this tie to my comments above? Well most new CPQ admins:
- Create a price rule for every possible combination
- Try to put every price rule on the event “On Calculate” because of the name
- Or they put every price rule in all the events. (why do this?! Just consuming resources for no good reason)
- Run into Double Calculate issues
A well managed CPQ instance may not necessarily need a lot of Price Rules to be effective. In fact most of our implementations find that there are more Price Rules used for Document Generation than for actual pricing. Yeah, it is crazy. The Salesforce governor limits are pushed to the max when there are lots of Price Rules. So efficiency is important.
Also with lots of rules, troubleshooting issues becomes a HUGE headache. I see that often when auditing other CPQ implementations. And I’m not going to start on the Dynamic Bundle/Product Rule conundrum because that is a different post all together and one that I loathe to write.
I like to take a moment and truly consider what needs to be factored to generate a price.
- Could I use a lookup table to solve the pricing problem?
- Could a Discount Schedule or Tiered Pricing be used instead?
- How often is pricing changing? Would an admin need to adjust the rules with new price changes?
I then factor that in and write down the process of price rules on a spreadsheet. Doesn’t have to be too technical. Write what you believe are the steps necessary at first and assign an event(s) and an order. Test it out with some examples. Add more detail to each row. Plan! Test! Then put it in CPQ.
Finally my suggestion is that you please read the help article a few times and the examples above. Understand how Price Rules truly operate before you dive head first.