Dealing with larger data loads in Salesforce often leads to the task of turning off automations, such as validation rules, workflows or process builder flows. This can be done directly in the Production Org, or even better, by using tools such as the Ben Edward’s Salesforce Switch.
Although the tool also offers to turn off triggers, it isn’t quite that simple. That is because any changes to triggers can only be done through code deployments, and those require the unit tests to succeed for the changes to take effect. However, some unit tests may depend on other triggers or automations to be active, which can make this a very complex and time-consuming undertaking.
Turning Apex Triggers On and Off with Feature Switches
A possible solution to this dilemma can be the implementation of feature switches. Feature switches are a simple concept of turning features on and off. In traditional software development, especially in cloud applications, this practice is used for controlled feature deployments, A/B testing, and more. In Salesforce, this principal can be used to quickly turn off all your trigger functionality to run data uploads – without the risk of trigger errors. This also improves the speed of your data upload.
How to Implement Feature Switches For Data Loads in Salesforce
Custom Settings have the advantage that they allow for hierarchical overrides of the global settings. Depending on what use cases the feature switches are needed for, this might be a desirable option. Each feature switch would be represented as a checkbox field in the Custom Setting. The downside to this approach is that any new feature switch requires the Custom Settings metadata to change, which is not ideal.
In Salesforce, I would consider feature switches to typically be of a global scope only. So, my personal preference is to work with Custom Metadata Types. Each feature switch is represented as a new record in the Metadata Type, which does not require changing the actual type itself as it would for Custom Settings. Those records can also be migrated as part of a metadata deployment.
Now, Let’s See What Such an Implementation Could Look Like
1. Creating custom metadata type
We start by defining the Custom Metadata Type. Create a Custom Metadata Type called “Feature Switch”. The type will need a new custom field.
2. Creating custom field on metadata type
3. Adding a record to turn off triggers
Now, let’s add a record to turn off triggers, by clicking the “Manage Records” button or link and select “New”. I named the record “All Triggers”, used the default API name, and left the “Turned Off” checkbox unselected. The image below shows the list of records for the feature switches including the record that was just created. Note that I created a new view to include the custom field.
4. Creating an Apex class
Next, create an Apex class that can be used elsewhere in the code to conveniently retrieve the state of a feature switch. The class will contain a single function to ask if a switch is turned off.
In our environment, feature switches are commonly used, so it makes sense to load them statically. However, using lazy loading is also a good option here. Making the SWITCH_MAP visible for unit tests decouples the manager from the actual configuration and allows the unit tests to inject the values they need for testing. In this case, changing the value of feature switches will not impact the success of an Apex unit test run.
5. Querying feature switch in the trigger
Last, the feature switch needs to be queried in the trigger. This can be as simple as introducing an early return statement in the code. If a central trigger dispatch pattern is used, the All Triggers feature switch requires the following snippet to be introduced in a single class only. However, if the pattern isn’t used, simply add the snippet to any trigger deployed in the Org.
6. Adding a unit test for the manager class
All that is left to do is to add a unit test for the manager class to ensure the code coverage requirements are fulfilled and you are good to go.
That’s all! Now, when another data load is about to happen, all that needs to be done to turn off triggers is to set the “Turned Off” flag for the “All Trigger” record to checked and you are ready to go.
There is no deployment or code hack necessary anymore. We used this pattern successfully during large projects with numerous data loads. It has saved us a lot of time and stress, as well as allowed us to focus on the data migration tasks, instead of getting distracted with environmental prerequisites.
Using Feature Switches for Integration Classes
Using the feature switches for all triggers is only one use case. Feature switches are also extremely useful for any integration classes using web requests to third-party services.
For example, if the third-party service is currently experiencing an outage, the feature switch can be used to activate a routine that deals with this situation. This allows your organization to inform users of the current outage. Plus, it will give the third-party service time to recover without penetrating the system with additional requests.
If there are triggers that should run during data loads, I would just rename the trigger to “Data Load Sensitive” or similar.