L
ast week i came across an issue where the system was 
receiving emails that we thought should have been classified as Forwarded emails and processed by a ‘Forward’ inbound email action. Even though all of the emails coming in had ‘Fw:’ as their subject prefix, some of the emails were being classified by the system as ‘New’ for their receive type instead of ‘Forwarded’ as we expected. After a little more investigation we discovered that the back-end code to identify forwarded inbound email actually requires more than just ‘Fw:’ as the subject prefix. The inbound email was being classified correctly because it didn’t meet all of the criteria for a forwarded email. This article contains a summary of the classification criteria for inbound emails. It should come in handy if you’re wondering how Service-now distinguishes between New, Reply, and Forwarded emails.
New:
- ‘New’ is the default classification for any email coming into Service-now. The system first performs all of the checks to see if an email should be classified as a ‘Reply’ or ‘Forward’ and only classifies the email as ‘New’ if none of the conditions are met.
Reply:
- Subject Prefix is insignificant (The system doesn’t care if the subject starts with ‘Re:’, ‘Reply:’, or ‘Chicken:’)
- System looks for watermark in subject and body. If a watermark is found that matches a ticket in the system, then email is classified as a ‘Reply’ receive type.
If not found, system checks the ‘In Reply To’ header - Value of ‘In Reply To’ from ‘Header’ field is tested against the value of ‘Message ID’ field for a message that was sent. If a match is found, then email is classified as a ‘Reply’ receive type.
- If ANY of these conditions are met, then the email is classified as a ‘Reply’ receive type and will be processed by ‘Reply’ type inbound email actions.
Forward:
- Subject Prefix is critical
- System looks for ‘FW:’ or ‘FWD:’ as the prefix in the subject line (Case sensitivity doesn’t matter)
In addition, the system also looks for ‘From:’ in the body of the email. This must match exactly! - If BOTH of these conditions are met, then the email is classified as a ‘Forward’ receive type and will be processed by ‘Forward’ type inbound email actions.
- Forward conditions take precedence over reply conditions
Hi,
We have setup for Inbound emails. Everything seems to be working fine except that the inbound emails are not getting logged in the activity log.
For the Inbound emails, the target is coming as None.. Is this impacting it anyway??
The target value needs to be defined for the email to be displayed in the activity log. This issue could be caused by a few different things depending on the setup you have. Are the emails coming in reply emails? Do you see a watermark in the subject or body? If you don’t see a watermark, does the header information match anything?
Yes the emails are coming in as reply emails.
I see the watermark in the body but still I am facing the issue.
When I reply the target field is showing None. It is updating other fields in the form which means system is recognizing it but only problem is that it is not logging in the Activity log. How to solve this issue?
It’s hard to say without working with the actual system and data. I would look to see if any reply emails are getting a target populated or if there are just certain types of emails that have an issue. You could also look at your inbound email actions and see if there might be an issue there. Maybe you could temporarily replace your inbound email action for replies with the one from the Service-now demo instance. Outside of that, you may have to contact Service-now support or ask on the forums for assistance.
Hi Mark!
Have you created inbound rules for processing emails based on record number? This would be useful feature as many IT organizations already have ID for their incident and vendors incident.
Regards
James
@James, I’ve done similar things before but I don’t have anything pre-built. If you think it’s something that would be useful for lots of different people then send me a message via the ‘Contact’ form outlining the idea and process in detail. If I think it’s something people could use and I have time I’ll write a post on it. You can also try asking on the ServiceNow forums.
Hi Mark,
Quick question;
Inbound rules check for SN record number on top of the watermark on incoming emails. This is all good, but it comes with a limitation. The check for SN record number is only limited to the subject line, so if the SN record number is missing from the subject line, it will be treated as a new. My question is:
Is there a way I can modify this inbound checking to look for the SN record number within the email body as well?! It would be great if there is a way to do this this.
Thanks much in advance.
There’s no simple way to do this that I’m aware of. What you would need to do is parse out that number from the body of the email and then query for a task with a matching number. Depending on what you found, you could insert or update.
That’s useful info, but I’m wondering if there are any keywords that can be placed in the body of an e-mail to get Service Now to conmplete fields like Service, Classification, Assignment Group and assigned To. I’d like to be able to send an e-mail with the details included so that individual techs receive notification when a client e-mails a request. Then I’d create an e-mail template for the client to complete and simplify the system somewhat. A lot of my clients refuse to log on to Service Now, and just want to be able to e-mail the tech directly.
There are no pre-defined keywords, but it’s fairly simple to set up an inbound email action to key off of name-value pairs. You can check out the default incident inbound actions for examples.
Hi Mark,
In your article, you have mentioned that you have discovered the back-end code around the email notification process.
Could you tell me how to access/view the back-end code?
Thank you
ServiceNow actually doesn’t make the back-end code available to customers. At the time I wrote this post, I was a ServiceNow employee so I had access to the back-end code.
Any thoughts on what the condition is or should be if you want to say does not contain? I’ve tired all of the Service Now suggestions and so far I have not any any luck with trying to make a condition that does not process new incidents if it contains (xxxx). I was able to create a condition for an email subject that always starts with the same string, however the challenge I have now is that I can’t get any of the does not, or is not conditions to work? I’ve got a condition that is working correctly for a custom request table, however currently every time it creates a task the incident also is created. Service Now really needs to add a condition builder to inbound actions. I’ve tired the Service Now suggestion of using indexOf, and that hasn’t worked?
Any thought on what a generic condition should look like to exclude a string that appears in the subject, I’m going to add this as a condition to the incident so that it does’t create a 2nd task for the same inbound email.
Both the Incident and Custom table inbound actions are based on new emails.
Andrew, not sure if you solved this or not but have you considered ordering your inbound actions so that the one related to your custom request table is fired before the incident IA and placing a “event.state=”stop_processing”;” at the end of each IA. This will stop any further IA’s from processing.
Quick question …
Under Forward, you wrote:
System looks for ‘FW:’ or ‘FWD:’ as the prefix in the subject line (Case sensitivity doesn’t matter)
In addition, the system also looks for ‘From:’ in the body of the email. This must match exactly!
What email address must the From field match?
(This post has finally answered a question for me – thanks for all your posts!)
Thanks Sue! Regarding your question, the inbound email actions don’t look at the actual email address at all unless you code it into the inbound email action script. The base functionality just examines the prefix information as I’ve described above.
One of the condition to classify email as Forwarded is the key word “From:” in body of massage.
Is there any way to add another key word, e.g. if customers are from different countries and they are using mail clients in another languages that add some another word instead “From:” to the body of mail??
Thank you
Sure. Check out this wiki link, there’s a system property you can modify.
http://wiki.servicenow.com/?title=Inbound_Email_Actions#Specifying_Recognized_Forward_Prefixes
I’m not sure if i understand you correctly, but i think about that sentence:
“In addition, the system also looks for ‘From:’ in the body of the email. This must match exactly!”
I know that i can add more prefixes to the glide.email.forward_subject_prefix but ServiceNow will be still looking for “From:” in body of mail.
And that is my problem, subject of mail contains prefix witch is in glide.email.forward_subject_prefix – and that is correct.
But body of mail contains some another word instead “From:” witch is needed as 2nd condition.
In conclusion, my problem is that ServiceNow still looks for “From:” in body mail.
Thank you
Hi, I am having an issue with some inbound emails which have FW: in the prefix and contain From: in the email body still being classified as type New and then being ignored – what else can I check for?
Thanks
Only other thing I can suggest is this…
http://wiki.servicenow.com/?title=Inbound_Email_Actions#Matching_Incoming_Email_to_an_Inbound_Action_Type
On the surface this question i has seems easy but not sure if its a simple command I dont know or something much more complicated.
If forward an email to our Helpdesk – I want the caller to be the original sender. This issues is the caller is always the person forwarding
I want to make or modify an inbound email action. We have a particular email address that sometimes gets emails that should actually go to Service Now as incidents. Folks are forwarding the emails to Service Now but the caller is ALWAYS that email address. Does anyone know a command or script I can add so that when anything is forward from the address support@myorganization… to Service Now- it looks at the email and grabs the original sender and makes them the caller. I tried current.caller_id = email.body.email; , current.caller_id = email.origemail; and many other things I saw posted in the community.. I know other things might come into play like creating the user if they dont exist but it may already be built in to the systems functionality when it gets an email from someone it doesn’t recognize. Any insight would be appreciated.
Hi Sam , did you get a solution to this. I am looking for the same thing .
Please help!
Great to see that this thread is still relevant after all this time.
I have set it up that PRB,CHG and PRJ are considered reply prefixes. Emails with the subject line beginning with PRB and CHG are treated as replies however emails with the subject line beginning with PRJ are seen as new (and create a new incident). Emails with the prefix RE: PRJ work fine.
Would you have any ideas to why this is happening
That seems like a bug or misconfiguration of some sort. I’d check with SN support. Not sure why that would be happening.
Hey Mark,
I NEED TO RECEIVE EMAIL CONVERSATIONS FROM OUTLOOK TO MY INSTANCE. WHAT SHOULD I USE NEW OR REPLY OR FORWARD?
If it’s an existing conversation and you want to send that to ServiceNow you would forward the email. Whatever you decide, the system just needs to have the appropriate inbound actions configured.
Mark, email.from and email.origemail do not appear to behave as they did in the past. I often used email.origemail to grab the email creator/original sender as the caller on a forwarded email. Now it returns the same result as email.from. I found a post concerning the definition of each, but am reluctant to accept it. I have been using this method for 10 years. Will you please share your wisdom? Bill
https://community.servicenow.com/thread/169561
That’s interesting. I’ve always thought of it that same way. I don’t know for sure what it does now and it wouldn’t surprise me if ServiceNow has changed things. Without access to the back-end code it’s hard to know for sure what will happen without a lot of trial and error. I’d suggest asking for clarification from SN support to see what they say.