A Tip A Day #23 – 5 Ways To Stop Trigger In Production

This post is a part of the daily blog series 

A Tip A Day, daily dosage of learning!


Day #23 – FIVE Ways To Stop Trigger In Production

In a scenario, you no longer want to use the functionality in your trigger and want to turn it off in your Salesforce production org, as in make the trigger Inactive, follow one of these 5 options.  Unlike in sandbox, where you can edit a trigger to uncheck the “Active” checkbox, you cannot do the same in a Production instance.  Its not that straightforward.

Note:  Many a times, you’d face a code coverage (less than 75%) issue while deactivating the trigger in production with any of the 5 approaches I mentioned below.  Just make sure, your overall code coverage is well above 75%.  Specially, if the trigger you are turning off has lots of code, it will definitely impact your overall code coverage.  So, be ready with your test classes for the other existing apex classes/triggers.

Bonus: 3 of the approaches mentioned below can also be used to Delete a class in production.


Read my other post – 3 Ways to delete an Apex class from Production


Here are your 5 options.  You can choose whatever is easier for you, there’s no recommendation here.

1. DEACTIVATE THE TRIGGER

This is the simplest way to do of all.  Deactivate your trigger in your sandbox by unchecking the Active checkbox of the trigger.  Create an outbound change set, upload and deploy the change set to production.  Tadah! The trigger in production will be deactivated.

2. COMMENT TRIGGER CODE

This is simpler than the simplest, comment your entire apex trigger code in your sandbox and then use outbound change set to deploy to production.  To comment code, you need to use /* and */ .  Anything in between those will be commented.

trigger opportunityTrigger on opportunity (before insert){
   /*
     your entire code
   */
}

Apex Class Deletion: This approach also can be followed to let an apex class be NOT used in production.

3. CUSTOM SETTINGS

Make use of custom setting using which you can control whether a trigger should run or not.  Create a custom setting (say Trigger_Settings__c).  Add a checkbox field “Is Active”.  So your custom settings will store the trigger name and its status in IsActive checkbox.

Then in your apex trigger, add an IF condition at the top to check if the Trigger status in Custom settings is TRUE, only then run the entire apex trigger code.

trigger oppTrigger on opportunity (before insert){
  Trigger_Settings__c TS = Trigger_Settings__c.getValues('oppTrigger');
  if(TS.is_Active__c == TRUE){
    //your trigger code
  }
}

So, every time you want to turn off the trigger in production, just go to your custom settings and uncheck the IsActive checkbox for that trigger! Simple! The trigger first checks the custom settings, knowing it is off, it won’t run at all !

Note: As pointed out in the comments section, if you’d like the trigger to be turned on/off for particular profiles, you can further play around with your custom settings to include Profiles and trigger status!

4. USING ECLIPSE IDE

This is similar to change set approach but here you would make the trigger InActive in the trigger’s XML file and then deploy from Eclipse.

1. You need to install Force.com IDE
2. Connect to the Sandbox Instance using the IDE and identify the trigger that you want to deactivate.
3. Open the trigger’s .xml file, and change the Status XML tag from Active to Inactive.
4. Save the file.
5. Select the two files (Code and XML) using “Ctrl-click,” and then right-click on one of them.
6. Select Force.com | Deploy to server.
7. Provide your credentials for the Production org and follow the steps.
Apex Class Deletion: To delete an apex class, change it to Deleted. Apex class Status can only be changed to “Active” or “Deleted,” not “Inactive”.

 

5. THROUGH ANT

Here’s a way to do using ANT tool.

1. Initializing destructiveChanges.xml: First, create an empty destructiveChanges.xml file. Yours might start out looking like this:ISV Team Dev Package.xml 1.png2. Check your destructiveChanges.xml file in to your source code control system.

3. Propagating Destructive Changes to Other Developer Edition Orgs.  Every time you delete a component:

a. Identify the name of the metadata component member.
b. Identify the name of the metadata component type.
c. Add an entry to your destructiveChanges.xml file using this format:ISV Team Dev Package.xml 2.png

4. Repeat steps 3-a,b,c for every component you have deleted.
5. Check in the changes you made to your destructiveChanges.xml file to your source code control system.
6. Note that you should refresh the destructiveChanges.xml files and run the Force.com Migration Tool for Apache Ant against it.

Apex Class DeletionThis approach also can be followed to let an apex class be NOT used in production.

If you are looking to delete an apex class production, read it here – 3 Ways to delete an Apex class from Production

 


Read all other tips of the blog series here – A Tip A Day, daily dosage of learning!


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

7 Replies to “A Tip A Day #23 – 5 Ways To Stop Trigger In Production”

  1. 3. CUSTOM SETTINGS – additionally it’s possible to create hierarchical custom setting and enable/disable triggers for specific profile. If you want you can add this tip 🙂 I’m still waiting to jobs and refresh “issue”.

    Liked by 1 person

    1. Hi Adamo, Yes, when you refresh the sandbox, the scheduled jobs do not run automatically (It is a known bug in Salesforce)! Need to delete and schedule them back again. Do you want to learn “how to delete and schedule jobs”?

      Like

Leave a comment