Ive solved the second question, would still like an insight on my first. 

@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.

What a great soltion, i just made the rule, ill cirlce back with feedback! Will this rule also catch a space if there is one? If so, im trying to wrap my head around it! 

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 

AHHH perfecto! On this same overall Highway intergration. Do you have any suggestions on being able to mark a contact’s email safe after it hits the fraud detedter API? As in not run the rule? We have a lot of emails that are getting flagged daily, and have to remove a tag, or move back to an inbox. 

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!

Thank you for the recommendation. I will see what I can do with your guidance. Love the automation piece. I’m wondering if we can tag the contact in someway shape or form that would then move it to a trusted list.  I tried the route of adding a tag after we move it out of quarantine but the issue is there are many times that the rule takes place in the individual inbox and I’m not able to move it back  

@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.
 

Thank you for the follow up I updated the rule! Please let me know when you guys are able to create the mentioned. Smart rule as well

@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 Here is what I have, Ill let you know how it plays out!
 

@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.

Great thank you for the confirmation. I added the rule suggestion this past; Friday. I’ll take a look Monday and see if there were enough rule executions to ensure it’s working correctly. 

@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? 

Do you mean the contact isn’t getting added to the contact list or that contacts that are added to the ‘trusted’ list are still being moved to the quarantine inbox?

Can you share the rule you’ve created to quarantine conversations? @bbay 

@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. 

Very fair comment @bbay ! It’s something I know the product team is exploring - giving users more granular control over when a dynamic object is created - so thank you for sharing your feedback. FYI @robby_p 

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  Thanks for the quick solution, and video walk through to boot. Took me some time, but I fiollowe your video, and made two other dyanmic variables. I went ahead and updated my rules (just in case), but turned them off.  Ill let you know if i see any issues! Let me know if you come up with anything else that may be useful! 

 @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. 

 

 

 

 

@bbay it’s understandable why you’d only want a Dynamic object to only create if one of your conditions are true, which then fires off your Quarantine rule; but unfortunately, I don’t have a solution to work around this; but the product team is definitely exploring the idea of giving users more granular control over when a dynamic object is created