Salesforce Data Loads: Using Feature Switches to Manage Apex Triggers
Salesforce Data Loads: Using Feature Switches to Manage Apex Triggers

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

Feature switches are based on a configuration object. This can either be done by using Custom Metadata Types or Custom Settings.

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.

Creating Custom Metadata Type - Salesforce Data Loads

2. Creating custom field on metadata type

From a development perspective, it will be easier to consider an exceptional case for when the feature is turned off, so I will create the custom field type “checkbox” and label it “Turned Off”. Creating Custom Field on Metadata Type - Salesforce Data Loads

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.

List View of All Trigger Feature Switches

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.

Are you looking for help with Salesforce implementation? Let’s meet at Dreamforce 2017, or contact us to discuss over the phone.

About Johannes Fischer

Johannes is a software engineer with over 10 years of experience working on web-based contact center products and cloud applications. At Aria Solutions, he is currently the Technical Lead for the practice. With a primary focus on integration, Johannes connects applications to handle real-time, high volume events, such as phone interactions and user contributions. He enjoys empowering companies to get more out of their IT environment, by linking their ERP systems to operate more efficiently and create better customer experience.



5 reasons why you shouldn't build your own WFM feed

5 reasons why you shouldn't build your o...

3 Quick Principles of Re-engineering a Process in Salesforce

Designing a process from scratch is alre...

5 Pillars of Success for the Modern Contact Center

As we’ve come to know that understandi...

How to Enable Customer Service Agents in the Omnichannel Era

Change is the only constant in the conta...