Summary Variables Versus Roll-up Summary

There is a concept called the “Law of the Instrument”. It basically says that if you are familiar with a tool, you are more than likely to use said tool over a better alternative.

For Salesforce Admins this happens all-the-time. “I don’t trust Flows so I use Workflow” could be the most stated comment from the old guard I’ve ever heard. Gonna let you in on a secret. These old stuff at times DOES work but is it scalable and now you create a troubleshooting mess to go to so many different places to figure out how Salesforce processed your records.

The same is true with Roll-up Summary fields. Too many CPQ configurations we audit use RUS fields over Summary Variables it is truly frightening. If I am a new CPQ admin I do not appreciate why this is a problem and that’s ok. I get it. Really I do. Let me help.


Hopefully by now, you appreciate that Salesforce has limits. Limits in terms of the number of fields, type of fields, CPU time, and number of queries. In fact there are so many limits, Salesforce has a whole article dedicated to limits. There is a quick guide webpage also but these are just the highlights.

So Salesforce has a limit of the number of RUS fields on the object. You also find that doing a good CPQ implementation requires roll-ups not just to process a quote and for reporting but also for document needs. Because of all this, you WILL hit the limit.

<<Quick aside.. This is the same reasoning I use to why Price Rules/Price Actions rule over the use of formula fields. Please don’t ask Salesforce to raise the limits. You’re just “kicking the can” down the road instead of solving the problem. CPQ configurations become MORE complicated over time not less>>

So while you CAN use RUS fields it is HIGHLY recommended that you instead go through the initial pain of using Summary Variables.

Usage of Summary Variables

Now I could in theory end the post here. But let’s not. How about some best practice guidance.

Price Rules fire under multiple events and so it’s useful to leverage those events. For example, I typically have a price rule that fires “On Initialization” that sets NULL or Zero any field on quote that stores summary data. I want the system to recalculate and factor in any changes that occur in the cycle.

I may also put some summary variable results during “Before Calculate” because I need to use the summary data in formulas for pricing calculations or for a lookup table query.

Finally I do all my quote summary work on “After Calculate” and typically make it the last rule that fires so that all the changes in my Price Rule work is factored.

Should probably say here, the more Summary Variables used, the more CPU time is consumed. Keep an eye on your limits during the calculation cycle.

Leave a Reply

Your email address will not be published. Required fields are marked *