I have an existing trigger that updates parent/grandparent/great-grandparent records with several totals when a child object is updated. The object relationship looks like this:


All objects are related by lookup. Changes to the Student status cause totals at all levels above student to change. The existing trigger is not reliable. I'd like to replace it with something more maintainable (and correct).

Leading contenders for replacement are:

  • Andrew Fawcett's "Declarative Rollups for Lookups". More here.
  • Process Builder and Flow. Example here
  • Some sort of scheduled job that runs multiple times per day

I should note that as many as 3,000 student status changes could happen at (almost) the same time. These bulk updates are generally done with Demand Tools.

Is this volume of changes likely to break either of the first two approaches? Andrew Fawcett's summary tool is described as being able to handle 50,000 child relation records. Some limits of Processes/Flow are listed here but I'm not certain if any apply to my situation.


I'm adding a bounty because I'd like to get a better idea of the limits of the options described and the likely failure modes. So what I'd like to know is:

  • Will "Declarative Lookup rollup summary" handle an update of 3,000 records with summaries at multiple levels without issues? What's the most records you've successfully updated at once in conjunction with this tool?
  • How many updates can a Process Builder/Flow based summary support? 50?, 500?, 1000? It has been suggested that this approach will almost certainly break for the volume I'm discussing, but it's not clear where the limits are.
  • How often can one safely update the totals with a scheduled job? In total, there might be 20,000 - 30,000 records to summarize. Hourly? Every half hour? more frequently?
  • 4
    Dlrs can handle it, pb will almost certainly break.
    – Adrian Larson
    Commented Jun 17, 2016 at 20:11
  • 2
    DLRS or Scheduled Job
    – crmprogdev
    Commented Jun 19, 2016 at 12:37
  • 1
    Jagular -- have you created a testbench environment to try out DLRS on the volumes you mentioned?
    – cropredy
    Commented Jun 24, 2016 at 16:25
  • I have a full data sandbox where I can test, but I'm hoping to avoid testing all three approaches.
    – Jagular
    Commented Jun 24, 2016 at 16:39
  • 2
    DLRS has a Scheduled mode as well, you can either have it process records that have been flagged as requiring a recalc or configure it to run full recalc on time/date frequency of your choosing. There is a doc link to the summer edition that covers a recent enhancement to the later. Commented Jun 25, 2016 at 8:14

2 Answers 2


If you do not need "Real Time" updates your best solution would be to use a batch process to cycle through the parent records individually and summarizing the children.

When you attempt to do it with triggers and sync you are going to increase the time it takes to load the data as well as potentially introduce other problems.

Those other problems include CPU Time outs, too many row, etc.

Andrew's technique is one of the better ones but how well it performs is also a function of the rest of your environment along with any other code that runs along side it. You also run into multiple executions if you have a bunch of inserts that cause updates and updates that cause updates.

Process builder is not ready for this type of work and will lead to premature baldness, do not even try it.

This is a difficult question to answer because the choices are highly dependent on your org and its existing processes and code base.

  • 3
    +1 from me on Eric. Ultimately DLRS is limited by the same governors as any other peace of packaged Apex code. So getting to carried away with realtime rollups can lead to the governors kicking in. This can be mitigated as you say by knowing about the likely volumes and ways in which records are inserted. Then planning use of Realtime or Scheduled rollups accordingly (see my comment on the answer as well). There is an API for DLRS, there is also this Apex Library that DLRS wraps github.com/abhinavguptas/Salesforce-Lookup-Rollup-Summaries if you want to roll your own Commented Jun 25, 2016 at 8:18

I'm of the opinion that doing this asynchronously is the best way to ensure this process will scale with your org as both you database and number of users grows. Its clear to me that Process Builder can't reliably do that. A triggered approach as used by DLRS doesn't have the advantage of vastly higher limits that using an asynchronous process will have.

Taking it a step further, if using either schedulables or queueables, one could chain them to split the work up between consecutively chained jobs fired from finish methods, should limits ever become an issue as the volume of data grows. Additionally, rather than doing all the work in a single class, you'd also have the choice of splitting the work out between each level in the hierarchy either alphabetically, or numerically in separate execution methods of unique classes in your chain.

You must log in to answer this question.

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