I have been trying to deactivate some triggers on the production environment by setting their status in the meta data files to Inactive , then deploying them straight to production with force.com ide from eclipse.

I did this process before for other triggers and was working fine, but now when I try to deploy it I get some failed assertion errors from the related test classes.

What would be the ideal solution in tackling this problem? The only thing I can think of currently is to remove the assertion checking from the test classes which seems to be the wrong approach.

  • you need to fix your test class failure then only you can update the metadata files
    – Ratan Paul
    May 31, 2016 at 10:39
  • @Ratan so the only solution is to remove the assert statements? Isn't there a smarter way such as setting the test classes to an inactive status? May 31, 2016 at 10:42
  • it will be ok untill unless you overall test class coverage more than 75 %
    – Ratan Paul
    May 31, 2016 at 10:44
  • What is the reason for deactivating the trigger? Some one time mass data load? May 31, 2016 at 13:41
  • @Robin De Bondt , indeed something like that May 31, 2016 at 13:44

3 Answers 3


An option that I see is to create a custom setting(let's call it Run_Logic__c) with a checkbox(let's call it Run_Triggers__c) and then check in your triggers if this checkbox is true. If so - run trigger, otherwise do nothing.

This approach will require a bit more lines of code, but it will be super easy to "deactivate" the triggers, just uncheck this checkbox and triggers won't do anything!

Your trigger would then look like:

trigger TRIG_MyTrig on MyObject__c (after insert, after update) {
    if (Run_Logic__c.getInstance('yourString').Run_Triggers__c) {
        // Your trigger logic

And if you need to "deactivate" it, just uncheck this checkbox.

The idea has been unashamedly stolen by me from this blog post

  • Nice one: "The idea has been unashamedly stolen by me from this blog post"
    – Nielsm
    May 31, 2016 at 12:50
  • @Novarag thanks for your response. I was thinking at some point to enable this sort of functionality using custom settings, but I never actually thought it is so simple to implement. Thanks again. May 31, 2016 at 13:28

Test classes are designed to show that the code is functioning the way that you expect it to. If you remove functionality, you should also remove the tests because you no longer expect the system to function that way.

If you are making the trigger inactive instead of removing it, the ideal solution would be to also make the test classes inactive or comment out the test methods that are asserting the functionality of the trigger.

In many common trigger architectures, the trigger is the backbone that holds all of the transactional apex logic together for an object, and inactivating an entire trigger is usually no small task. You might be better off just commenting out the parts of the trigger that you want to turn off rather than trying to remove the whole thing.


There are a number of ways to stop a trigger to run.

  • Deactivate trigger
  • Comment Code
  • Use custom settings
  • Using Eclipse IDE
  • Using ANT tool

I've consolidated the list. More on this here https://sfdcfanboy.com/2017/11/23/a-tip-a-day-23-5-ways-to-stop-trigger-in-production/

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.