en

Spam filter in Flow? It looks that this can work!

18/07/2023

Basic Information

From time to time, as part of the life of a Salesforce Consultant, I have to deal with email logic, routing into the system, and lately, what kind of emails we want to receive. Spam is a category of its own and should be handled on the email service provider's side.

Unfortunately, it is not always the case, and very often, we hear reasons why it's not possible, how much time it would take, and so on. I don't want to claim that it's easy, as it probably isn't (after all, I know nothing about it). Nevertheless, I don't think so that Salesforce should provide a service that should be on email mailbox side.

And then there's the outcome. A person must come up with how to fulfill the customer's request, which is:

  • I don't want to have Spam emails in Salesforce, popping up in Cases

  • Actually, sometimes I do want them there, but I want to set the Case to closed and mark it as spam

  • Actually, not everything is spam, but please automatically mark automatic responses as spam

  • I would like it to be fully automated; agents don't have time to click buttons.

We could come up with many more requirements, but let's demonstrate how to achieve the first two using Flow and Metadata.

(Yes, it's possible to do it more simply, like, uh, hardcoding email values in a Validation rule (watch out for the limit!) or Case Assignment rules, but that's definitely not the right approach. This solution is scalable, it is possible to use it for small or big company.  I've verified that it can handle large implementations too - 500+ agents).

Metadata

As we work with live data, we need to store and work with them somewhere when necessary. The ideal place for these purposes is Metadata (Custom Metadata Object).

We will create a new object called 'Spam Email.' Shortly after, we'll create a new field of type Email with the same name, 'Email' (or 'Spam Email' - it's up to you). Alternatively, we could simply use the 'Name' field and avoid creating any additional fields. In this case, I'll choose to create a new field to maintain the correct data type.

Now that we have prepared the object, we just need to populate it with the necessary information. Click on 'Manage Spam Email' and create a new record, entering the name and email.

.. and that's all as far as metadata is concerned.

(On the object, we can have a field called "Active" that will inform us whether we actually want to keep this email as "spam" or not. This will prevent it from being deleted and re-added to the metadata. Of course, this needs to be reflected in the Flow as well.)

Flow

Let's take a look at the flow that will be responsible for managing the process. Within this use case, we are addressing the following points:

  • Cases where the origin is an email

  • We want to work only when a case is created

  • We have two distinct record types, and we want the process to be different for each

(The below-described guide for the flow is merely an inspirational foundation)

  • Let's create a new "Record Trigger" type of flow
  • The starting object will be Case, and the flow will be triggered only on the "Create" action
  • The entry condition will be limited to cases where Case.Origin="Email" 
  • The flow should be optimized for "Actions and Related Records" 
  • Let's save it
  • Next, we need to determine whether our Spam email is recorded in the Metadata
  • We will use the "Get Record" component
  • Select the object as "Spam email" 
  • The entry condition will be "SpamEmail__c.Email__c" = "Case.SuppliedEmail" (or we can combine conditions as needed).
  • As we work with two types of cases, we will use a decision element to react based on the Case Record Type

(The Case record type is dynamically assigned using email-to-case based on the email address, but for the decision's value, we can use anything that we have recorded on the Case object. So, for example, we can use "Subject > Contains > Automatic Response" or something similar.)

  • Next, we proceed directly to the actions we want to perform with the record

  • One branch (or one record type) is designated for direct deletion, and the other automatically closes the case

  • For deletion, we will use the "Delete Records" component, and as "Records or Record Collection," we will use "{!$Record}."

  • For update, we will find the "Update Records" component and input all the necessary information that the case should contain after the update. For example, we can close the case, fill in the custom field "Category" with "SPAM," or similar.
  • Save!
  • Activate!
  • Ready to test!

Last words...

As described above, this solution can be apply for small or big implementation. Of course, like any flow, like any automation, it has its limitations. If subjected to excessive usage, it may reach its limits and lead to invalid behavior. There are certainly many of you who might come up with a better solution, and I encourage you to share it! info@salesforcestuff.com

It's essential to be mindful of the order in the Flow Trigger Explorer.

This flow is a foundation and can be expanded upon as per your discretion.

Share