Taming Automation in Salesforce

Workflows, Process Builders, Validation Rules and Apex Triggers — these are some of the best friends of a Salesforce developer. They help maintain data quality and remove a lot of manual steps. But the problem is that they always work and never take a day off. How many times have you wondered “maybe I can just turn them off for the next half hour so thatI can migrate my data or mass update records of an Object or even have a deployment in peace?” Yeah, I can understand your frustration, as I’ve been there countless times. But at Picnic, we decided to do something about it.

The Challenge

First, let’s look at the details:

1. Though all the configurable automations can be toggled by a few mouse clicks, the real challenge arises when there are quite a few of these automations that needs to be toggled. At Picnic, the entire data model is centered around the Product Object. This means that it has a lot of Validation Rules, Workflows, and more around it. If I had to toggle them one by one, it would take me forever. So we had to come up with a solution to turn all of them off in a snap.
2. How about Apex Triggers? If they need to be activated, they would require a complete deployment process, which takes a significant amount of time. Moreover, there is a risk of Test Classes failing during deployment if the Triggers are deactivated. Lastly, this is not something which a Salesforce Administrator can do and would require developers to jump in.
3. Let’s complicate this a bit more. We have seen situations where we need to turn off only a portion of an Apex Trigger. The only way to do that is commenting that portion and face all the challenges from #2. What we really want is a way to turn these Triggers completely or selectively off, without going through all the hassle.
4. Sometimes, we have to consider a scenario where these automations apply to only a handful of users or only for a certain amount of time. We would not like to spend our time updating them for these users or do so only at certain times.

The Solution

In the end, it turned out that what we were looking for was a ‘switchboard’ for these automations, one that is used in Workflows, Processes, Validation Rules and Apex Triggers. But we also wanted the ability to use these automations selectively, depending on the user. For those reasons, Custom Settings fit the bill perfectly, because:

1. The hierarchical Custom Settings can provide different values on User, Profile and Organization level, which means we got the potential to control every user’s automation.
2. They can be used seamlessly in Workflows, Process Builders, Validation Rules, and Apex Triggers.

The Implementation

Now that we had our heart set on Custom Settings, we needed 2 of these — one for a broad control and one for granular control. But you must be thinking “if hierarchical Custom Settings already gave us the range, then why two?” Good question, and the answer is that we need the range both in the users and in the automation. Thought technically we can, 2 Custom Settings is a cleaner approach. Let me explain with an example of Product.

Assume that the Product Object has:

• 2 Validation Rules
• 1 Workflow
• 1 Process Builder
• 1 Apex Trigger with 2 actions

We created the 1st Custom Setting (Bypass Settings) with the following checkbox fields:

• Product
• Validation Rules
• Workflows
• Process Builders
• Apex Triggers

Then, we update our automations to include this Custom Setting:

AND(
    NOT(
        AND(
            $Setup.Bypass_Settings__c.Product__c,
            $Setup.Bypass_Settings__c.Validation_Rules__c)
        ),
    <Validation Rule Condition>
)

This means that if I mark Product and Validation Rules as TRUE in the Custom Setting, this Validation Rule will not run. Similarly, we updated our Workflows and Process Builders.

For Apex Triggers, we create another Custom Setting (Automation Settings) to work in conjunction. This contains the following checkbox fields:

• Apex Function #1
• Apex Function #2

Then, we add the following portions of code to the Apex Trigger (and of course, Test Classes):

//Bypass the whole trigger
if (!(bypassSettings.Apex_Triggers__c && bypassSettings.Product__c)) {
    
    //Bypass Apex Function #1
    if (automationSettings.Apex Function #1) {
        //Code for Apex Function #1
    }
    
    //Bypass Apex Function #2
    if (automationSettings.Apex Function #2) {
        //Code for Apex Function #2
    }
}

This means that if both the fields Product and Apex Trigger is TRUE for Bypass Logic, then this trigger will not execute and if only the field Apex Function #2 is TRUE then only Apex Function #2 will execute.

The Motivation

To keep up with Picnic’s dynamic operations, we often have to turn certain functionalities on and off, and sometimes only for one or two users. Sometimes, even the developers need to turn them off for testing purposes or to resolve deployment conflicts. Who knew that checking some boxes in Custom Settings could keep us sane!

Another reason for us to gain control over the automations was Picnic’s exponential growth. Because of it, changes here can come quickly, resulting in a need to turn functionalities on and off on a regular basis. Sometimes, the changes have to be made on a global scale but sometimes, they have to be more selective.

But beyond the time saved and the repetitiveness avoided, we realised that this was the typical kind of challenge Picnic loves to undertake. It opened up a new playing field for us to play around in, and come up with creative and interesting solutions which impact a very large proportion of the people at Picnic.

With the same user-focused perspective we have for our customer-facing tools, we significantly improved the user experience of our Salesforce users, admins, and developers. With this time saved, we can now focus on more impactful things and enjoy a beer at the end of the day!