0

We implement Trigger Framework in our organization however we start buying apps that use trigger in managed package which we don't have control over it.Therefore I believe one trigger perobject is no longer applied because we have other triggers in managed package.

There is one apps that it always hit Apex CPU limit whenever we update data and current work around is to turn off that apps whenever we want to do bulk update.

I am thinking if there anyway that we can control the sequence like checking if the apps trigger is run, and if yes then we will not run our trigger so it can minimize the apex cpu limit exception.

I already apply bulkify in our org trigger , minimize the soql by using Maps etc. But I don't have control over trigger in managed package.

Have anyone face this issue before ?

Improve this question

1 Answer 1

Reset to default
3

If the other app is triggering the CPU limit, there's no way to determine if you'll be contributing to the problem ahead of time. Instead, you should probably contact the vendor to see if they have a mechanism to disable the logic through a utility class for bulk updates, or ask them to optimize their code. Alternatively, if it's not validation code, you might simply decide to use a Queueable instead of normal code so that you minimize your impact to CPU time.

Improve this answer
3
  • Thank you for your reply @sfdcfox , I am looking for any possibilities if the issue is coming from us because if yes it would be better to fix rather chasing the vendor. Also beside trigger we also has Process Builder.There opinion saying process builder consume CPU time, and I should not use it -- but so far it runs well as long we turn off the managed package.Let me know if any other thing that I should check before I contact the vendor.I am really appreciate if you can give me idea what to check with vendor in order to identify their trigger is good.
    – unidha
    Apr 20, 2018 at 7:21
  • @unidha You can run a debug log to see where the CPU time is coming from. And yes, Process Builder counts against you. You'll need to run the logs to see where most of the time is being used. Keep in mind that Process Builder or Workflow Rules can potentially double the amount of CPU time used.
    – sfdcfox
    Apr 20, 2018 at 7:41
  • We had a similar issue with CPQ Salesforce managed package. We just disabled all our own custom logic on the affected objects to prove that the issue was coming from the CPQ package.
    – Francis
    Apr 20, 2018 at 10:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.