Email has three chances to recognize a reply email arranged over subject, header and email body. The last chance an email has to recognize a reply is related to the subject of having a reply prefix and the record <number>. This method is popular because it does not requires a previous email from the instance to use it; however, its power is limited. I can see that using watermarks is more efficient. Nevertheless, here are my findings.
Incoming emails are classified following an algorithm as New, Reply or Forward. Inbound email actions enable an administrator to define the actions ServiceNow takes when receiving those emails. Reply emails can be identified by several methods. The most complex of methods to identify reply emails is: subject with a reply prefix that contain the record number and no watermarks.
Recognizing the reply by the subject record number
Based on my tests, to classify the email using the Subject as reply, the text needs to be as follow:
- The first characters need to match the reply prefix and it is not case sensitive.
- The record number needs to be ONE word. Only spaces or ':' are accepted before and/or after.
- The record number prefix needs to exist on the sys_number table.
- The number needs to be within the first 160 characters (including the number itself)
- The user that sent the email needs to have access to the record refered by the number
Based on that, you can see it can be consider as temperamental. Well, maybe.
The first characters need to match the reply prefix.
This is usually done by your email client. Nothing to worry except spaces before the prefix or other languages. Just ensure the subject line is starting with a recognized reply prefix. Just avoid spaces (or invisible spaces - e.g. MS word justifications paragraph markers) before the prefix.
The record number needs to be ONE word. Only spaces or ':' are accepted before and/or after.
The record <number> is the field called 'number' on the target table. The record <number> has to be one word (e.g. INC00001) and with a valid record number that matches an existing record.
Yes, <number> needs to be ONE WORD (no symbols or characters around them) with spaces around it (e.g. MM-INC0001 is wrong).
The record number 'prefix' needs to exist on the sys_number table
The number "prefix" needs to EXIST and ideally be unique (or first found) on the Number Maintanance (sys_number table).
e.g. INCxxxx record will INC match on sys_number table, and it will provide the 'incident' target table.
Another example is TASKxxx record. It will match TASK, which points to two target tables. Use with caution. It will match the first table found causing inconsistency. Prefixes are stored on Number Maintanance, and there are TWO "TASK" prefixes. On my testings, it was matching TASK prefix from the task table, instead of TASK from sc_task table.
To validate the prefixes, check
<instance>/sys_number_list.do?sysparm_query=prefix!%3DNULL
Here is the how it looks:
The number needs to be within the first 160 characters (including the number itself) of the subject
There is a limit of 160 characters on the sys_email subject. When creating the subject, ensure the <number> is on the first 160 characters. To validate if the subject was correct, after the instance process the email, the incoming email logs will show:
Received id=<Message-ID> Classified as reply to '<number>' found in subject
If the subject is incorrect, the incoming emails will get classified as New.
Here are the results of my testings with different subjects. INC0001 is a valid incident number.
Working subjects: | Reason |
Re:INC0001 | Reply prefix + number |
re: Review INC0001 | Reply prefix + anything + "space" + number |
RE: Review:INC0001: | Reply prefix + anything + "colon" + number + "colon" |
rE:INC0001 Review | Reply prefix + number + space + anything |
You can see the reply prefixes are not case sensitive. Space and colon are acceptable.
Not working subjects: | Reason |
Re:Review-INC0001 | Minus is not acceptable. Space and colon are fine. |
Re:Review -INC0001 | Minus touching the number is not acceptable. |
Re:Review TEST0001 | TEST is not a valid sys_number prefix. Even if the number=TEST0001 exist. This could happen on manually created numbers |
Re:TASK0001 | Acceptable but it may pick the wrong target table. from sys_number. There are two TASK prefixes. |
Re: XX…(160+chars) INC0001 | The subject will get truncated leaving the number out. Place the number on the first 160 characters. |
Re:INC0001 | Space before the prefix is not acceptable. |
As you can see, the character - before the number is not acceptable. Also, the number needs to exist on the target table. Also, if the number was created without following the prefix (e.g. TEST instead of INC), it will not match.
Here are the results on the sys_email table:
If you are using subjects for reply emails without watermarks, ensure you are using the email prefix, then <number> separated with spaces and the rest of the subject. Then all should be as easy as drinking a glass of water.
I have tested with Chrome as browser on Fuji. Emails were written on Outlook 2011.
More information here:
- Email Resources Page (KB0540674)
- Inbound Email Action Type is not Matched (KB0535515)
- Inbound Email - New, Reply, and Forward - ServiceNow Guru
- Inbound Email Troubleshooting (KB0524472)
- Docs: Inbound Email Actions
- Docs: Examples of Inbound Email Actions
- Part Three | Verifying Inbound Email User and Incident Creation Settings - YouTube
3 Comments
