Salesforce Flows | Consider Implementing a Kill Switch Design for Flow (On/Off Switch)

In this post we will see why we should consider to create a Kill Switch or an On/Off Switch for Salesforce Flows. Also, we will see one of the potential (many) ways to create this Kill Switch or On/Off Switch for Flows .This can be useful specially for Record Triggered Flows(After Save, Before Save and Before Delete Flows ). 

Basically, I will talk about creating a kind of a Kill Switch which can turn OFF the Flows temporarily without making them Inactive every time we need to stop them from firing.Same Switch can be used to again turn them ON. This is specially helpful for Record - Triggered Flows (Before Save,After Save) and sometimes also for Auto-Launched Flows.
Note: The theme of this article is to understand both about Why and How to create a Kill Switch for Flows.

Why should we consider a Kill Switch (On / Off Switch) for Salesforce Flows?

As Flows are becoming more powerful and a go to choice for automations, it has now become more important to use a Flow Design Strategy which can be used to quickly switch them Off or On in various scenarios. This can be in parallel with same design being widely used already for other Automations like Apex Triggers, Processes, Validations and Workflows.
With the introduction of Record Triggered Flows (Before Save Update and After Save Update Flows) which fire on Record Save(Insert/Update) automatically, it becomes crucial to think about the same strategy while designing the Flows too. 
One such common scenario is a bulk data load activity in orgs where we need to sometimes turn off some of the system's automations like Apex Triggers,Validations,Process Builders etc. – without the risk of automation errors. This also improves the speed of the data upload.
The same strategy(Kill Switch) has been used for a long time in Validation Rules, Apex Triggers and Process Builders as they fire automatically on Record CRUD operations (Create, Update and Delete). Many times Salesforce admins want the ability to control these centrally for exceptional scenarios like bulk loads. 
Now we should think about extending that design to Flows too, specially the Record Triggered Flows.

Example/Hypothetical Use Case/Scenario for Kill Switch in Salesforce

Suppose, in a Salesforce Org, Account Object has below Automations.

5 Validation Rules

1 Apex Trigger

2 Process Builders

1 Before Save Flow

1 After Save Flow

2 Autolaunched Flows 

Now, Imagine during a Bulk Data upload, we do not want any of these or some of these automations to fire.This is to prevent any automation errors and also to make data load faster. If this org did't have a kill switch design implemented in all these automations, a Salesforce admin will have to Switch off all of these manually (after actually checking where all and what all automations are written/developed for the Account Object). Also, after upload finishes, admin will have to manually switch on every thing. Seems quite complicated and manual right?

Potential Solution (High Level): We can have a general framework in our org that every time we create any Apex Trigger,Process Builder, Flow or Validation Rule for a particular object, we can refer single or multiple Switch Fields/Criteria so that all of these can be controlled centrally by an Admin. This is the ideal scenario. 

But we can also create localised switches or functionality specific or even just Flow specific Switches. It all depends on the requirement and use case. For example a different Switch for different object's automations or common for multiple Objects. Or even different switches for different types of Automations like validations, Flows, etc. It all depends on actual requirement and org design.

For Example, suppose we have a Hierarchy Custom Setting named "Account Switch" and it has a custom field of type Boolean named "Stop".  So now if we refer this Custom Setting in any Trigger, Flow,Process etc.at the beginning to check the value of Field "Stop", and design the automation in such a way that it only proceeds further when this field value is False, this becomes a On/Off Switch. 

This is because if the Salesforce Admin anytime changes this field's value to True, all the automations where this is referred will not be processed further because we specified that in the automation. This will continue till the value in the Custom Setting is not changed back to False.

How the On/Off (Kill) Switch Design can Work for Salesforce Flows?

The strategy behind this is very simple. At the Start of the Flow, we can introduce a Decision Element. This decision Element is basically used to check if at the time of firing this Flow, should the Flow run further or stop at decision only. 

How can we create Kill Switch or On/Off Switch for Salesforce Flows?

We have different options to achieve this in a Lightning Flow. All these options are Admin Controlled and can be easily referenced in Flows. Every option has its own Pros and Cons. Please checkout TrailHead in case you are not familiar with these options/features of Salesforce.
1. Hierarchy Custom Settings : Easy to maintain and Admin Controlled. Can have Profile and User Level Control. Another advantage is that, they can be fetched in a Flow without using a Get Record Element. Data is not deployed from Sandbox to Production but that's not a big issue. If you are not familiar with how to Use Hierarchy Custom Setting in a Flow, check my previous article here :  Use Hierarchy Custom Settings in Flow
2. List Custom Settings : Easy to maintain and Admin Controlled. But it can not have Profile and User Level Control without creating special logic to handle that. Data is also not deployed from Sandbox to Production.
3. Custom Labels : A very Primitive way to check Custom Label value in Flow and take decision based on the value in the label.
4. Custom Metadata Type : Similar to List Custom Setting almost in this scenario. Advantage is that it's easier to manage and adding new values is easier.Data is also deployed from Sandbox to Production. One downside is that, we can fetch these in Flows using Get Record Element only whereas Hierarchy Custom Settings can be fetched without Get Element by using just a Formula Variable. 

We can use any of these depending on our use case and complexity. I will be using a Simple Hierarchy Custom Setting (my favorite) in this example. 

Sample Scenario: 

Create a Admin Controlled Kill Switch for Record-Triggered Flows (After/Before save) for Account Object using Custom Settings.

Steps

1. Create a Custom Setting of type Hierarchy

I have named this custom setting as "Flow Kill Switch" 

2. Create a new Field for this Custom Setting which will be acting as our actual Switch.

I have named this Field as "Run Flow". Default Value is Checked.

3. Assign the Values to this Field for Default Organization Level Value and any specific Profiles or users as per requirement.

I am only using Default Organization Level Value in my Example and making the default as True. It means that until explicitly changed, the value in "Run Flow" is True for all the Org Users.

--------------------------------------------------------------------

Note/Tip: Using Hierarchy Custom setting, you can control behaviour of this switch differently for different Profiles and Users. For example, if you want that for a certain use-case, the Flow should only fire if it's being Run by an Admin Profile's user, then you can assign the "Run Flow" field value as True for System Admin Only and keep the Org Default as False. Now Flow will Run further only if it's run by an Admin User. Like wise we can have different use cases and can design our custom setting accordingly. 

--------------------------------------------------------------------

2. Reference this Custom Setting Field in the Flow by creating a new Variable of type Formula and fetching the Value using $Setup option. The general syntax is {!$Setup.CustomSettingName__c.CustomSettingFieldName__c}.

If you are not familiar with how to Use Hierarchy Custom Setting in a Flow, check my previous article here :  Use Hierarchy Custom Settings in Flow

3. Use a Decision Element at the Start of the Flow to check the value in this Formula Variable.

--------------------------------------------------------------------

Note: As we are using Hierarchy Custom setting, the value in Formula Variable will depend on running User/Profile. But since, I have not created separate records for any specific User or Profile, we will get the current value from "Org Default" value for the custom Setting Field "Run Flow"

--------------------------------------------------------------------

4. Write Flow Logic for the Decision True Path so that it only proceeds further if "Run Flow" is found True.

This Flow will only proceed after the Decision Element if the value of the Formula Variable from Custom Setting is True. If an Admin changes that value to False, the Flow will not go beyond Decision and no other logic will be performed. 

And we are Done!

So we have seen a very basic example of how to Create an On/Off or Kill Switch for a Flow.This design strategy can be extended further to create much more complex and advanced switch based on various conditions.

What do you think about this strategy? Is it actually going to be useful in Future when we depend on Flows for Automations or is there a better way to achieve this?

Please let me know your thoughts, ideas or feedback around this topic.

Checkout other Salesforce resources

For Other Flow Use Cases, checkout this link : Explore Salesforce Flow Use Cases

Never miss any new Post and get it delivered to your inbox. Subscribe Now!

Enter your email address:

Delivered by FeedBurner