Enforce to reprocess email as new

[kuba4]

Hi,

Is there a way to reprocess specific emails from sys_email table, but to enforce to be reprocessed as new?

I have a bigger issue with ServiceNow recognizing email as reply to Call, but not able to update target record and dropping emails. Before I resolve this bigger issue I need to have a quick solution for emails which were already missed by the system. I would like to reprocess them, but the problem is that they are classified as 'reply'. Is it possible to enforce this for some cases for 'new'?

Regards,

Kuba

[kuba4]

These emails are actually replies, but before instance upgrade it was working differently and they were classified as new. We don't have inbound rules to process replies in Call table and as a result emails are dropped.

Do you think it will work if I just remove "In-Reply-To" header from original email? I thought there might be some more "elegant" way to do it...

Regards,

Kuba

[kuba4]

Looks like removing "in-reply-to" header from the mail is the best short-term solution for me now.

Thanks.

[Chuck Tomasi]

FWIW, replies are recognized three ways.

1. There is a watermark (e.g MSG:xxxxxxxx) in the foot of the message that ties it to an existing record in the system.
2. There is a recognizable record display value (e.g. INC0001004) in the subject line
3. There is an In-reply-to in the header

I'm kind of surprised the last one was in effect because it is pretty rare. The first is the most common as it is attached to outbound messages from ServiceNow.

[kuba4]

Well, the scenario can be like this:

1. Someone sends email to multiple users, including our SN mailbox.

SN processes email as new (in our case - creates a CALL)

2. Any recipient of 1st mail replies with SN mailbox included.

SN processes this email as reply to CALL, based on "in-reply-to" header

This is actually the source of our problems, because we don't have replies to CALLs taken care in inbound rules and as a result email is dropped by instance. The odd thing is that this problem started after our upgrade from Istanbul to London. I've never seen such email log before and docs don't say about changes in this area between these versions...

I suppose the system does a lookup in tables which contain record with that message ID. Is there a way to exclude new_call table from this lookup? That could solve our issue in a long term...