Routing Rules - Email remaining unprocessed in mailbox

[Kevin Kennedy]

Hello

Relative newbie to the Hornbill world, trying our first go at Routing Rules.  Everything seems fairly straightforward, but I am missing something basic.  Below are the pertinent screenshots.  Can anyone let me know what I missed, I think I have tried all of the solutions in the wiki & forums.  Email just sits seemingly unprocessed in the Inbox

 

 

 

 

 

 

Thanks in Advance - 

Kevin Kennedy

[Steve Giller]

All the known reasons for Routing Rules not processing incoming emails are detailed in the Routing rules do not process emails and Routing rules do not raise requests from emails or apply emails to requests posts in the FAQ section.

If you haven't already, please review those posts and let us know whether you could resolve the issue; if not we'll look into it.

[Kevin Kennedy]

@Steve Giller

Thank you!  I had reviewed both of those previously, and made some changes to test whether any of reasons listed could have been the root cause.  I don't think they are, at least to my inexperienced eye.

[Steve Giller]

@Kevin Kennedy 

I've copied that setup into my Instance and the email I sent in successfully raised a Request.

One thing I've noticed is that you've defined a Routing Rule Template but that doesn't appear to be applied in the Routing Rule itself, I'm not sure if that should cause an issue but I'd certainly update the Rule to use it as a first step - if nothing else you'll be assigning the Request to the correct team.

I'd also remove and re-type the condition; if you copied it and pasted it in (especially from a Microsoft environment) there's a small possibility that there are non-standard characters in there.

Finally, I'd suggest that you match against the Subject - this shouldn't affect the result (I used body in my test so it was like-for-like) but assuming the subject contains the relevant text as it does in your example, it's a faster and more efficient match than comparing against the whole body.

[Kevin Kennedy]

@Steve Giller  Thanks for the prompt suggestions.

First point was definitely a problem, I fixed it (Red Arrow).  I also removed and retyped the condition, basing it on subject, and shortened the searched for text to "Alert" (Yellow Arrow).  These seem like very good suggestions, but the result is the same, the email stays unread in the service desk inbox   I know there must be something I have done wrong.

[James Ainsworth]

Hi Kevin,

Within the Email Domains section, I was wondering if you have the option Enable processing incoming mail on this route turned on?

[James Ainsworth]

Also, just thought I'm mention that the recommendation for this setting is to have it set to OFF.  This isn't required for routing rules and is more secure when off.

 

[Victor]

21 hours ago, Kevin Kennedy said:

the result is the same, the email stays unread in the service desk inbox

@Kevin Kennedy @James Ainsworth perhaps this was covered but mentioning just in case: re the above statement which suggests that the expectation is that routing rule will process an email that resides in the mailbox. This is incorrect. Routing rules only action on incoming emails, which are emails that are (about to be) received. Before Hornbill does anything with the email, if routing rules are enabled, they will process that email and action as configured. Once the routing rules process that email (either successfully or not) and the email lands in the mailbox, that email will no longer be processed by routing rules as it is no longer an "incoming" email, it is an email that is now "received". So, testing a routing rule will always require an email to be incoming so with any change made to the routing rule a new (test) email will have to be sent to Hornbill.

[James Ainsworth]

Thanks for the suggestion @Victor.  We were sending new emails for each test.  In each case the email arrived in the Inbox.  The success folder is set to a created folder called Processed and the failure set to the Inbox.  

[Kevin Kennedy]

@James Ainsworth @Victor

 

So embarrassed that the problem ended up being something you had suggested early on, that I told you was not the case in our instance.  Upon changing the two email addresses that were duplicated among out users, and retesting, it seems to be working as expected.