How to Prevent Flows from Running in a Sandbox

Flows are very useful tools within Salesforce. However, there may be instances when you have a Flow that you do NOT want to run in a Sandbox. For example, maybe you have a Scheduled Triggered Flow that sends emails, or triggers an integration. Were this Flow to run in a sandbox you would see unwanted behaviour, like those emails actually being sent out.

Potential solutions to this problem may include deactivating the Flow or disconnecting an integration, but these solutions are not ideal. Although they may resolve the issue at hand, they can cause more problems down the line and make life more difficult when debugging the Flow or the integration. Deactivating the Flow altogether can negatively impact your DevOps pipeline and throw your sandboxes out of sync, so it is best for the Flow to remain Active. So what should you do?

In this blog, we will walk you through a simple solution that will allow the Flow to remain Active in sandboxes without actually running. With three simple Nodes and a Custom Metadata Type, we can prevent a Flow from running in a Sandbox unless we want it to. Before any Flow logic is executed, the first three nodes will determine whether or not the flow will run.

Example Use Case

The example used in this demonstration is a Schedule Triggered Flow named “Contact Send Email Alert”. This flow runs every day at 9AM and sends an email to Contacts, a process that we only want to be running in Production. So let’s walk through the steps to ensure our flow doesn’t run in the Sandbox.

1) Identify the Environment in which the Flow is running

The first thing the Flow needs to know is what environment it is running in. We can achieve this by querying for the Organization Object to determine if the flow is running in Production or in a Sandbox. Each Salesforce org has one record in the Organization Object that describes the org. You may be familiar with the Company Information page in Setup – this page surfaces data from this Organization record. The field for review is the “isSandbox” field. This checkbox will be True for Sandboxes and False for Production. This flag alone would be enough to resolve the issue; however, the Flow would never run in a Sandbox and we want to be able to run the Flow in order to test any further changes or debug issues. For this, we require a second flag, and that is where the Custom Metadata Type comes in.

2) Create a Reusable Custom Metadata Type

The next step is to create a Custom Metadata Type with a custom checkbox field called Run_in_Sandbox__c and a custom text field called Automation_Name__c. We will use the checkbox to allow or prevent the flow from running in a sandbox. A Metadata Type record’s Label and DeveloperName are both limited to 40 characters, whereas a Flow’s Label and API Name can be up to 255 characters. The Automation_Name__c field character limit is set to 255 to allow for the input of a Flow API Name.

It is good practice to make this Custom Metadata Type scalable. We are not limited to creating a Custom Metadata Type specifically for this Flow. By naming it “Run Automation in Sandbox”, we can reuse it with other types of automation.

3) Insert a Custom Metadata Type Record

Insert a metadata record to use with this flow. In this example:

  • the metadata record and Flow label are the same
  • the Automation_Name__c field matches the Flow API Name
  • the Run_in_Sandbox__c checkbox is unchecked

4) Flow Get Records Node to Query the Custom Metadata Type

The next step is to query the Metadata record in the flow. In the criteria we specify the Automation_Name__c is equal to the current Flow API name and we retrieve the Run_in_Sandbox__c checkbox field from the record.

5) Decide when to Run the Flow

The third node is a Decision Node with the following criteria:

  • Run the flow if the org is production, OR if the org is a sandbox and Metadata record Run_in_Sandbox__c field is true.
  • Else, don’t run the Flow if the org is a sandbox AND the Metadata record Run_in_Sandbox__c field is false.

And that’s it. Now the scheduled Flow will not run in sandboxes while still remaining Active. To test the Flow, check the Run_in_Sandbox__c checkbox on the relevant Metadata record. Note – Be sure to uncheck the checkbox when you are finished testing.

With these simple steps you will be able to prevent unwanted behaviour from automation running in your sandboxes.


Need any help with your Flows? Or just want to chat about Salesforce? Get in touch. We love talking about this stuff.

You may be interested in

Considerations Before Implementing Salesforce Financial Services Cloud

Announced in 2015, Financial Services Cloud (FSC) is a long-standing offering from Salesforce. Its platform goal is to empower Financial Institutions to build deeper 1-on-1 client relationships, be more productive, and engage with clients everywhere. The platform includes capabilities for managing interactions, the full client lifecycle, financial goals, and regulatory compliance. Financial Services Cloud is […]

Read More

Beyond Procurement: Selecting the Ideal Partner for Government Salesforce Projects

The public sector, especially the government, continually strives to provide high-quality and secure services in an ever-changing environment. So whether at the federal, provincial, or municipal level, there are numerous factors to consider when choosing the right partner for the implementation of your Salesforce projects. The government must balance several competing priorities, shifting timelines, intricate […]

Read More

Sign up for the latest tips & news from CloudKettle

Thank you for subscribing.