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.
She changes the toggle to DON’T Send and clicks Next.
Amy confirms the setting has been changed and clicks Finish on the next screen.
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.
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.
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.
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.
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:
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.
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).
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.)
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:
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.
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.
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.
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.
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.
Next, use an Update Records element to update the Automation Switches record to reflect the new value set in the Assignment element.
After the custom setting has been changed, inform the user via a Screen element.
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.
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.
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.
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 Deanne Walters uses Flow to create […]
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 […]
Welcome to another “How I Solved It.” 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 Rachel Park Brayboy used her sewing (and […]