Consider the following two Salesforce CPQ scenarios:

1) In one scenario, a Summary Variable can have the following values:

  • Aggregate Function: Sum
  • Aggregate Field: SBQQ__ListPrice__c
  • Target Object: Quote Line
  • Filter Field: SBQQ__ProductCode__c
  • Operator: equals
  • Filter Value: foo,bar,bux

And the Summary Variable can be assigned to the Target Field through a Price Action on a Price Rule.

2) On the other hand, in a Quote Calculator Plugin (QCP) script, we can use connection.query to execute an aggregate SOQL query and assign the value to a target field as well:

  'SELECT SUM(SBQQ__ListPrice__c) ' +
    'FROM SBQQ__QuoteLine__c ' +
   "WHERE SBQQ__ProductCode__c IN ('foo', 'bar', 'bux')"
).then((response) => {
  const aggregateResult = response.records[0].expr0;
  // assign value to target field ...

Do both methods count towards the Governor Limits (or do Summary Variables bypass the SOQL limits)?

Are there any benefits to using one method versus another?

1 Answer 1


Yes. It helps to compartmentalize CPQ Data and save it for later use. This also stems from the design of SteelBrick CPQ. You could build you own custom rollups if needed.

What is a Summary Variable? “Summary variables can target the quote line, product option, subscription, or asset. They can calculate the SUM, AVERAGE, MIN, and MAX values of a number field. They can also COUNT the number of records that meet the filter criteria. You can set up the summary variable to consider records that match the filter criteria. Then, you can reference them in price conditions, price actions, product rule error conditions, product actions, quote term conditions, and other summary variables. ”

CPQ is saving the summary data as real data in a custom object that can later be accessed without needing to use complex calculations (subject to governor limits).

Summary Variables are subject to Governor Limits just like any other transaction; however, the summary variable processing could occur in a different transaction than where it needs to be used later downstream.

Look up a tool called DLRS (Declarative Lookup Rollup Summaries). It's a rollup tool that does something similar to what Steelbrick did. Yes it's subject to DML too.

You get 100 queries, 10,000 DML commits, etc for any one transaction. If this helped, it's not specific, but a developer viewpoint. Troy ~ Seattle

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .