When I use the Mass Transfer (Account) tool I am encountering the error message in the subject line regarding the following Trigger. Is this a issue where this trigger is not bulkified and is causing the timeout? Note: When I transfer 150 instead of all 250 records at once the Transfer tool completes the transaction.

/* Auto Generated and Deployed by the Declarative Lookup Rollup Summaries Tool package (dlrs)
trigger dlrs_AccountTrigger on Account
    (before delete, before insert, before update, after delete, after insert, after undelete, after update)
    private Boolean deactivateTrigsForBatch = (!Test.isRunningTest())?App_Settings__c.getInstance('ACCOUNT_Deactivate Triggers for Batch').isActive__c:FALSE;

  if(!deactivateTrigsForBatch) {
    try {
    } catch (Exception e) {
      //do nothing
  • 1
    Just because this code is where the LimitException is encountered does not mean it is the cause. The trigger you have included is generated by a managed package. You should first try to optimize the rest of your Account trigger logic before focusing on dlrs. You may also wish to reduce the number of summaries you calculate for this object.
    – Adrian Larson
    Dec 1, 2016 at 2:00
  • And if you are using PB, it is immune to CPU time limits. It will use up > 10 seconds without fail and the very next line of code that is executed after PB exists will throw the Cpu time limit error. Follow the debug logs and you will see what is going on
    – Eric
    Dec 1, 2016 at 6:11

1 Answer 1


We have no way we tell you based on this information. The fact that it crashed during this trigger means nothing.

For example, say you have triggers A and B, where A happens first and B happens second. Even though this isn't true, for example's sake, let's say that the governor limit is exactly 60,000 ms (we're running asynchronously), and anything over that throws the exception. Trigger A takes 299 milliseconds to process one record, and Trigger B takes just 50 milliseconds to process a record. At 200 records (the size of a full batch), Trigger A used 59,800 ms, while Trigger B used just 10,000 ms. Even though Trigger A used 99% of the allocated time, Trigger B takes the blame because it was the one to actually step over the 60,000 ms limit.

So, you're going to have to enable debug logs (Setup > Monitoring > Debug Logs), set a trace on your user account with Profiling set to FINEST, run the process, and read the logs. The trigger with the most time used is the culprit, and is the one you actually need to focus on. DLRS is likely not at fault, because it's actually a highly optimized algorithm. Most likely, it's another trigger, or perhaps a sum of all triggers in your org that are causing the issue.

Depending on the exact nature of the situation, you may need to (a) move some of the code to a future/queueable call, (b) optimize one or more triggers, and/or (c) remove some functionality entirely, and instead leverage other features, such as workflow rules, process builder, flows, or other non-code means of performing updates.

You must log in to answer this question.

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