2

We are working on an app which has functionality to perform a large number of record updates in a batch.

We would like to be able to programmatically disable all triggers at the start of the batch logic, execute the record updates, and then reactivate all triggers programmatically once the batch has finished.

Can anyone suggest a solution in terms of api calls we could make via apex (or a solution similar) to achieve this programmatically?

Answers to other issues that already exist or have been highlighted as duplicated point to the deploy() file based method of the metadata api but I can't see how I achieve the above using this method. Would I have to do a metadata api file based retrieve of all trigger objects in the system, change the metadata xml for each to set the trigger as inactive, and then deploy all of the triggers again? (for an org that has a large number of triggers this would be a very significant operation)

Improve this question
5
  • 3
    All of your triggers, or all triggers in general?
    – sfdcfox
    Mar 10, 2017 at 16:29
  • All triggers that exist in the org (to prevent any logic triggering as a result of the batch updates). Regarding the potential duplicates i've updated the description as the solution is not clear.
    – Peter Tibbitts
    Mar 10, 2017 at 17:11
  • The point is you have to use a deploy call.
    – Adrian Larson ♦
    Mar 10, 2017 at 18:09
  • Also not, although not programatic this is a good tool to do ad hoc: sftoolkit.co
    – Eric
    Mar 10, 2017 at 19:05
  • OK thanks for the link - interesting to know anyway about sftoolkit
    – Peter Tibbitts
    Mar 10, 2017 at 19:34

1 Answer 1

Reset to default
3

There is no way to temporarily disable a trigger that does not have this sort of functionality written into it.

If you can modify the triggers you want to disable, there are many ways of going about adding conditional logic to ensure that they fire only when you want them to.

If you can't modify these triggers (like if they're part of a managed package or they're maintained by a different developer), then you've got two options:

  1. Abandon your current approach and find another solution.
  2. Figure out what sort of conditional logic is built into those triggers that may prevent them from firing, and then exploit that logic in your own code to ensure that the fire conditions are never met. This approach is rarely feasible, and is a great way to end up with lots of technical debt and fragile code, but it could be justifiable in rare cases.

Generally speaking, this is the reason why I am extremely wary of any managed package or custom development that includes a trigger on a standard object.

Improve this answer
1
  • Nice explanation. Thanks for your response Sequoyah
    – Peter Tibbitts
    Mar 10, 2017 at 19:39

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