Jennifer Lee and Christina Nava in a new episode of "How I Solved It."

How I Solved It: Interrupt the Dreaded “Infinite New-Case-Loop”

By

Welcome to another post in the “How I Solved It” series. In this series, we do a deep dive into a specific business problem and share how one #AwesomeAdmin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Christina Nava used Flow and a custom setting to allow anyone in an org to stop sending auto-emails and interrupt the dreaded “infinite new-case-loop” that can happen when using Email-to-Case.


Key business problem

Email-to-Case is a wonderful tool in your Admin Arsenal. It allows customers to send an email to your support email address and automatically create a case. And of course, once a case is created, you want to send an email to the customer letting them know you received theirs and that a case has been created.

This works great 99.9% of the time.

But what happens when your automated "New Case Created" email generates an automated response from them, which creates a new case, which generates an automated response from both sides, which creates a new case, which...you get the picture. This can generate hundreds, if not thousands, of new cases very quickly!

This scenario happens when the automated response doesn’t REPLY back to your “New Case Created” email but sends a new email instead. Because this is a NEW email sent to your Email-to-Case email address, Salesforce creates a new case for it instead of attaching it to the original case.

You typically see this happen when the email is sent from a system that also creates a case or ticket and generates a “New Case Created” email of its own, or when an “Out of Office” email is sent back.

As a Salesforce Admin, you can deactivate the flow that sends the “New Case Created” email, which will break the cycle and stop the infinite loop. However, this means you have to wait for one of your support reps to let you know it’s happening before you can act. If the loop happens while you aren’t working, that is, overnight or while you’re on PTO, the number of cases created can be daunting.

It would be great to allow your support team leads to interrupt the infinite loop, but how can you give them access to do so without giving them permission to deactivate every flow?

How I solved it

I solved this by creating a custom setting that must be TRUE before the “New Case Created” email is sent via a flow*, and then creating a screen flow that allows specific users to change the custom setting.

When a user notices the infinite loop happening, they can go to their Home page and toggle the custom setting to FALSE. The next time a case is created via Email-to-Case, the “New Case Created” email is not sent, which interrupts the infinite loop. After waiting 60–90 seconds, they toggle the custom setting back to TRUE.

Scenario:
Cory, a support rep, is looking at the new cases in the queue and notices multiple cases created every minute with similar subject lines. He opens a few and confirms they’re created because of the infinite loop issue. He then contacts Amy, his team lead, and informs her of the issue.

Amy goes to the Support Home page and verifies the setting is currently set to Send the “New Case Created” email.

Screen flow showing the "New Case Created" emails are being sent

She changes the toggle to DON’T Send and clicks Next.

Screen flow showing the "New Case Created" emails are NOT being sent

Amy confirms the setting has been changed and clicks Finish on the next screen.

Screen flow showing the confirmation that the setting has been changed

After waiting 60–90 seconds, Amy follows the same steps to change the setting back to Send.

*Please note, this solution requires your “New Case Created” email to be sent via a flow.

Business results

After implementing this solution and training your end users, you’ll no longer have thousands of extra cases created. Not only does deleting these extra cases take time, even when using the Mass Delete Records feature in Setup, but also your customer is receiving the same number of emails, which isn’t a good experience for them. It causes a lot of confusion for your support reps, and legitimate cases can get lost in the mass of new cases.

With this solution, you can control who has permission to change the setting so instead of having to delete hundreds or thousands of invalid cases, the infinite loop can be stopped more quickly by the users who notice it happening first.

You can also use the same concept of using a custom setting to control if a flow runs in many other situations.

I hope this solution helps you solve a problem!

Try this at home

This solution is created using a custom field, a custom setting, and two flows.

Create a custom field on the User object in order to give specific users permission to modify the custom setting. If this field is set to TRUE for a user, they’ll be able to change the custom setting. If the field is FALSE, they’ll see a message letting them know they don’t have permission and they need to speak to their team lead.

New Case Email Override custom checkbox field on the User Object

Give permission to the appropriate users who should be able to control when the “New Case Created” email is sent by checking the New Case Email Override field on their user record.

User record displaying the New Case Email Override custom field set to TRUE

Create a custom setting called Automation Switches with a custom field that can be queried from your flow and is used to control if the “New Case Created” email is sent.

Custom setting called Automation Switches

Create a custom field called Case - Enable New Case Email on the Automation Switches custom setting. If this field is checked, the flow will send the “New Case Created” email.

Case - Enable New Case Email custom field on an Automation Switches custom setting

Create a record-triggered flow on the Case object that’s triggered when a new case is created. We’ll use this flow to send the “New Case Created” email.

Your final flow should look like this:

Case record-triggered flow that sends the "New Case Created" email

Perform a Get Records on the Automation Switches custom setting object to get the custom setting record we set up earlier. Since we have only the one record, we’re setting it to store the first custom setting record found.

Get Records element returning the first Automation Switches record

Then, we utilize a Decision element, which checks the status of the Case - Enable New Case Email field on the Automation Switch. I also find it best practice to verify that the email field you’re using in your email alert is not Null (meaning there’s an email address in the field).

Decision element that checks to see if the Case - Enable New Case Email field on the Automation Switch is TRUE

Lastly, add a Send Email Alert element on the outcome decision where Case - Enable New Case Email is TRUE and choose your “New Case Created” email alert. (These instructions assume you’ve already created an email template and email alert for when a new case is created. If you haven’t already created these, you can save your flow, go create them, then come back to your flow and start with this step.)

Send Email Alert element, which uses the Record.Id and the "New Case Created" email alert

Create a screen flow, which runs in System Context, to allow a user to modify the Automation Switch custom setting.

Your final flow should look like this:

Screen flow that allows an end user to modify the "Case - New Case Created Email" field on the Automation Switches custom setting

First, add a Decision element that checks to see if the user running the flow has the New Case Email Override field set to TRUE on their user record.

Decision element checking the New Case Email Override checkbox on the running user

If the New Case Email Override field is FALSE, use a Screen element to inform the user they don’t have the correct permission to disable the “New Case Created” email.

Display screen informing user they have insufficient permission to proceed

If the New Case Email Override is TRUE, we’ll continue with the flow and allow the user to change the Case - Enable New Case Email field.

Perform a Get Records on the Automation Switches custom setting object and get the first custom setting record found.

Get Records element returning the first Automation Switches record

After you have the current value for the Case - Enable New Case Email field on the Automation Switch, create a Screen element with a toggle component. Insert the Case - Enable New Case Email field into the Value field on the toggle. This allows the user to see the current value to ensure they want to change it.

Display screen with instructions and toggle component showing the current value of the Case - Enable New Case Email field

Now that we have the new value for the custom field, we need to update it. Add an Assignment element and set the value of the Case - Enable New Case Email field on the Automation Switch to the new value from the toggle on the previous screen.

Assignment element setting the value of the Case - Enable New Case Email field to the new value from the toggle on the previous screen

Next, use an Update Records element to update the Automation Switches record to reflect the new value set in the Assignment element.

Update Records element updating all field values for the Automation Switches record

After the custom setting has been changed, inform the user via a Screen element.

Screen element informing the user the setting has been updated

Lastly, save your flow and then edit the properties to run the flow in System Context Without Sharing—Access All Data to allow a current user to modify the Automation Switch custom setting.

Flow set to System Context Without Sharing—Access All Data

Add the screen flow to the Home page where you’d like the flow to reside. You can do this by adding a Flow component using Lightning App Builder.

Home page with screen flow embedded displaying the toggle set to TRUE

And there you have it! You have now stopped the infinite loop of cases being created. If you have any questions, please feel free to reach out to me on LinkedIn.

Resources

Want to see more good stuff? Subscribe to our channel!

SUBSCRIBE TODAY
How I Solved It with Jennifer Lee and Dee Ervin

Search Unsearchable Field Data Types | How I Solved It

Welcome to another “How I Solved It.” In this series, we do a deep dive into a specific business problem and share how one Awesome Admin chose to solve it. Once you learn how they solved their specific problem, you’ll be inspired to try their solution yourself! Watch how Dee Ervin searched unsearchable field data […]

READ MORE