Configure a dynamic object for an MC number & Fraud Detect

@bbay Thank you for reaching out! I’m glad to hear that you were able to solve your second question, and I’m happy to provide insights regarding your first question:

Bad news and good news: unfortunately, as of today, a Dynamic Object can currently only recognize one defined text pattern. But the good news is that there is a solution that you can leverage (it involves building a smart rule in Front) so that you do not have to build separate dynamic objects to capture the variants.

The smart rule grabs the digits from variant text patterns that you’re seeing from the body of an email (e.g. MC#123435, MC# 12345, MC12345, MC 123345, MC: 123445), and then posts a comment on the conversation with a defined text pattern that does match the defined text pattern for the MC Dynamic Object that you’ve already created. For this smart rule to work, please double-check that within your MC Dynamic Object, it has a text pattern as follows. It’s important that there is no space between MC and Digits.

Important to note, if the mc number (e.g. MC#123435, MC# 12345, MC12345, MC 123345, MC: 123445) is in the subject line of an inbound email and not the body of the email, unfortunately this smart rule will not trigger as we’re only looking at the mc number in body of the email.

Once that’s confirmed, please proceed to creating the smart rule. Below is the completed smart rule (Please choose your appropriate inbox or inboxes within the smart rule.) 

And here’s how to construct the MC dynamic variable:

And here’s how to construct the MC# dynamic variable:

In order to construct the MC: dynamic variable that’s used in the smart rule, please follow the above screenshot, but simply replace “MC#” with “MC:” in the Only if preceded by section of the build.

Make sure you save the rule and that it’s active, and that’s it 😎

Lastly, our Product Team has been informed of what you’d like to see in the future regarding Dynamic Objects, (i.e. functionality implemented where you can have a single dynamic object recognize multiple text patterns) but please also submit a request for it at this link. When features are submitted, they're listed in the Ideas Portal and can be upvoted by other Front users who discover requests that can improve their team's workflows. And you'll receive an email update if a feature that you submitted or upvoted is developed and shipped.

Hi @bbay 

The first dynamic variable mentioned should match if there’s a space in between MC and the digits. Note that you can test this using Test extract text when you create the dynamic variable.

 

FYI @steve_b 

Hey @bbay good question - I’m not entirely sure what rules you have set up on your side but I imagine you’ve got a rule in place that will quarantine flagged emails based on the information pulled in from Highway.

If you’ve independently verified the contact is not suspicious and should not be quarantined in the future, you can think about adding a rule condition to check a contact list of these ‘internally verified contacts’. Something like:

This will require you to maintain your own contact list, which shouldn’t be too difficult to do. You can easily add a contact to a contact list via the Contact Details plugin on the right hand side of the app. If you want to go the full automation route, you could consider creating a rule where you automatically add a contact to a contact list when you move a conversation out of the quarantine inbox.

This should be enough for you to get started but let me know if you have any additional questions!

@bbay we’ve updated the smart rule solution posted earlier. Please add these conditions in the rule so this way a comment is only auto-posted when an mc number is included in the body of an email and not when it’s not included in the body of an email (please see below screenshot.)

Also, important to note, if the mc number (e.g. MC#123435, MC# 12345, MC12345, MC 123345, MC: 123445) is in the subject line of an inbound email and not the body of the email, unfortunately this smart rule will not trigger as it’s only looking at the mc number in body of the email.

We’re currently working on an updated smart rule solution to account for when an mc number occurs in the subject line and/or the body of an email, but we’ll have to get back at a later date with an update.

If it’s a problem that the smart rule only gets triggered if an mc number is in the email body, the only alternate solution, at this moment, would be to create separate dynamic objects so that you can capture each potential variant text pattern that exists for the mc numbers when they show up in the subject or body of an email.
 

@andersen  Im assuming that a contact thats added to a list wouldnt trigger the rule again? Even in a new conversation?  

Hey @bbay good question - I’m not entirely sure what rules you have set up on your side but I imagine you’ve got a rule in place that will quarantine flagged emails based on the information pulled in from Highway.

 

If you’ve independently verified the contact is not suspicious and should not be quarantined in the future, you can think about adding a rule condition to check a contact list of these ‘internally verified contacts’. Something like:

This will require you to maintain your own contact list, which shouldn’t be too difficult to do. You can easily add a contact to a contact list via the Contact Details plugin on the right hand side of the app. If you want to go the full automation route, you could consider creating a rule where you automatically add a contact to a contact list when you move a conversation out of the quarantine inbox.

This should be enough for you to get started but let me know if you have any additional questions!

@andersen  Im assuming that a contact thats added to a list wouldnt trigger the rule again? Even in a new conversation?  

Hey @bbay good question - I’m not entirely sure what rules you have set up on your side but I imagine you’ve got a rule in place that will quarantine flagged emails based on the information pulled in from Highway.

 

If you’ve independently verified the contact is not suspicious and should not be quarantined in the future, you can think about adding a rule condition to check a contact list of these ‘internally verified contacts’. Something like:

This will require you to maintain your own contact list, which shouldn’t be too difficult to do. You can easily add a contact to a contact list via the Contact Details plugin on the right hand side of the app. If you want to go the full automation route, you could consider creating a rule where you automatically add a contact to a contact list when you move a conversation out of the quarantine inbox.

This should be enough for you to get started but let me know if you have any additional questions!

 

That’s correct @bbay. The idea here is to create that ‘trusted’ list so all subsequent conversation from ‘trusted’ contacts wouldn’t be moved to the quarantine inbox and can remain in whatever inbox the email was sent to.

@andersen The contact list method doesnt seem to be working. I created the lists as shared. Would that be the issue? Does it need to be a private list? 

@andersen  I apologize, I was crossed up, so many rules going! HAHA I think we’re good there. I was thinking that I could add any trusted contact and that would also stop the email detector. With the volume that comes across it makes the inboxes a bit noisey. It would be nice for the Dynamic object to only create if one of my conditions we’re true, which then fires off the Quaretine rule we have. 

Good news: it turns out that you don’t have to create a separate dynamic object for every single text pattern variation that you’re seeing for MC Numbers. That said, I recommend leveraging the solution demoed within the first 4 minutes and 30 seconds of the hyperlinked video below. This solution has a huge advantage — it will not only work when just 1 MC Number appears in an email subject and/or body, but also when many different MC Numbers appear in either the subject line and/or body of an inbound email. And since you’ve already built one Dynamic Object for the mc use case (MC[Digits]), you’ll only have to build 2 more 😎 I’d recommend building those out and you can then delete the smart rule that we walked through on 1/5/24.

With 3 Dynamic Objects you can capture 6 text pattern variations

After watching the video: to reiterate, the downside of using a solution that involves leveraging 2 smart rules is that it’ll only work if you’re just dealing with 1 specific MC Number being referenced in the subject line and/or body of an inbound email. If multiple MC Numbers are listed in an inbound email, it will not trigger a Dynamic Object to be created for all of those numbers because of a limitation. (For Example, if MC#1234, MC#1236 are in the body of an inbound email, a dynamic object will only be triggered for MC#1234.) 

For that reason, I recommend creating at least 3 separate dynamic objects as the solution.

 @steve_b wanted me see if you had any ideas on the below. Our inboxes have become very noisy with the fraud detect we’re looking for a solution that only creates the object if there is a fraud or spoof or possibly be able to mark domains as safe, in turn not triggering a the dynamic object. 
 

@andersen  I apologize, I was crossed up, so many rules going! HAHA I think we’re good there. I was thinking that I could add any trusted contact and that would also stop the email detector. With the volume that comes across it makes the inboxes a bit noisey. It would be nice for the Dynamic object to only create if one of my conditions we’re true, which then fires off the Quaretine rule we have.