9

I need to mass update 1000's of objects, which have triggers, but I don't want the triggers to run, as that brings me over the SOQL limit very quickly. I'm just trying to update via Anonymous.

So is it possible to stop triggers from occurring within a single transaction? Without modifying or disabling the triggers (this is a one time thing).

I've seen data import tools having the option of "prevent triggers", so I imagine it is possible without modifying the trigger or disabling it org wide....

9

The way I typically see this implemented is via a custom setting.

Create a custom setting of type hierarchy called Trigger_Disabled__c. Then you can create Account_Disabled__c, Contact_Disabled__c etc fields on it for the particular sobject instances you need to disable.

Why a hierarchy setting? You could use list custom settings as well, but if you wanted to disable workflows or validation rules as well, you can reference hierarchy custom settings in formulas.

Additionally, custom hierarchy settings will allow you to enable / disable the trigger for different users based on the organization hierarchy, etc.

In your trigger you would reference the trigger enablement check similar to below:

trigger AccountTrigger on Account(before insert){
    Trigger_Disabled__c triggerDisabled = triggerSettings.getInstance();
    if(triggerDisabled == null || !trigger.Disabled){
       //call your method or logic here
    }
}
  • 1
    Shannon Hale presented a great DF13 session explaining this in detail: youtube.com/watch?v=4nF0XYx4m80 – metadaddy Feb 4 '14 at 0:59
  • Not exactly what I need, is there a method to disable at transaction level rather than org/user level? – Mattisdada Feb 4 '14 at 3:06
  • 1
    If you are doing your mass updates as a single user, shouldn't hierarchical level control be sufficient? I don't think there is a way to turn it off otherwise unless you add a field to the record that tells the trigger to immediately end via code. – Michael Welburn Feb 4 '14 at 3:39
  • Thats fair enough, I've just seen data import tools being able to stop triggers with no modifications (why fill up classes with boiler plate when the overall app doesn't need it, DRY) to the triggers. So I'm assuming there is another way – Mattisdada Feb 4 '14 at 22:23
  • I marked this as the answer, as it is a good solution, but I still think there could be better ways, in my implementation I used the "early termination" method rather than a large if tree if(triggerDisabled!=null && triggerDisabled.Disabled__c){return;} – Mattisdada Feb 5 '14 at 0:21
2

You can deactivate your trigger anytime you want.Deactivate your trigger in your sandbox and deploy the trigger inactive to PRD. Be careful and notify your users / lock their access down so that there are no data inconsistencies during the time the trigger is inactive.

  • I don't want the triggers to be disabled for everyone, just during the one transaction while I mass update all objects. Disabling the trigger for everyone will cause data issues for us (triggers on this object is important) – Mattisdada Feb 3 '14 at 23:41
0

First Note: My answer is only applicable only if you could modify the triggers (which in your situation is not, but others might consider).

You can do this with a dummy User that should exist in your Sandbox/Prod Environment and only controlled by your Administrator or someone who should be able to update data without activating the Triggers.

  • Create a dummy User and get its ID
  • Modify the Trigger Code to have something like this:

    trigger TriggerName on SObject(before update, after update) {

        if (Trigger.isUpdate) {
    
            if ('theIdOfYourDummyAccount' != String.valueOf(UserInfo.getUserId()) {
                //All your update Trigger Code here
            }
        }
    

    }

Now if I am the administrator and you requested to be able to bypass the triggers while updating data, I'll give you the credentials of that dummy user. You'll login using that User to do your thing. Then I'll change the credentials afterwards.

  • While this does strictly work, it is far less maintainable and flexible than the solution using the Custom Setting that's described in this question's accepted answer. – David Reed May 22 '18 at 13:06

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.