Preventing Flows From Sending Emails in Sandbox Environments

Salesforce Flow has a range of useful features, and one of its key functions is allowing users to send emails. This action is widely used and has a significant impact within the platform. Users can easily send personalized emails by using the platform's user-friendly features, which seamlessly connect with email templates and Salesforce data. It enables effective communication with customers, potential clients, and stakeholders, leading to overall business success. While sending emails is a common practice, doing so in a sandbox environment can pose risks and may be undesirable.

For example, let's say that there is a record-triggered flow that sends an email to a Lead whenever its status changes. There can be some users that play with the data, at the end it is a sandbox, right? So, the system will send emails to these Leads. Moreover, since record-triggered flows run in the background, users won't even have an idea that they are sending emails. What if it is a refreshed partial/full sandbox with some real data and they are doing a mass update? It will be a disaster.

Therefore, it is critical to prevent flows from sending emails in sandbox environments.

Finding the Environment Type

First step is to determine whether the current environment is a sandbox or not.

As you may know, Company Details page shows many details about your organization. Although it is not on the layout, it has a boolean field called IsSandbox. This field shows whether the current environment is a sandbox or not. In order to get this information, it is possible to run a SOQL query from Organization object. For instance, result of this query indicates that it is a sandbox environment.

SELECT id, InstanceName, IsSandbox, OrganizationType FROM Organization 

If you run the same query in a production environment, you will see that the value of IsSandbox field is false.

Organization Object and Global Variable

In order to prevent flows from sending emails in sandbox environments, you can use the Organization object. Here is how to use it.

As you may know, there is a global variable called Organization.

This global variable stores some values from the Organization object (a.k.a Company Details). For instance, you can find the organization's name, address, or phone. However, although IsSandbox is one of the fields of the Organization object, $Organization global variable doesn't have this information. Therefore, it is not possible to use this global variable to determine whether the current environment is a sandbox or not.

In order to find the remaining field values, you can use a Get Records element and get the Organization record.

Then, add a Decision element to check the IsSandbox field's value.

For example, this flow sends an email if the environment is not a sandbox. If it is a sandbox environment, it skips the Send Email action.

What Else Can You Do?

Using the Organization object is only one way of preventing flows from sending emails in sandbox environments. You can use many other options like custom settings, custom metadata, custom label etc. On the other hand, you can change the deliverability of the environment to "No access" or "System email only". This restricts flows from sending emails, but the limitation extends beyond just flows. Consequently, it might not be the suitable approach for your specific use case.

Same logic can be used for other actions as well. For instance, you can prevent flows from sending notifications, making callouts, etc.