system.limitexception apex cpu time limit exceeded

Question

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 {
        dlrs.RollupService.triggerHandler();
    } catch (Exception e) {
      //do nothing
    }
  }
}

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.