Emails from a sender not matched to a user record do not appear in Incident Activity log when using Inbound Email Flow

[mark_oldroyd]

Hi,

When using an Inbound Email Flow specifically I noticed that if the sender is not matched to a user record (and thus is Guest or Empty) then that original email is not included in the created Incident's Activity Log. 

Note: When using Inbound Actions this is not an issue.

Has anyone else come across this and if so know of a solution? Or should I stick with Inbound Actions for now?

We currently don't automatically create accounts for unrecognised senders and are not likely to turn that on.

Thanks!

[mark_oldroyd]

Yes 100% sure it runs. Though I completely understand why you'd question it given the docs.

I have a fairly lengthy list of Executions.

Additionally, the Flow sets certain fields different values than any IA would (e.g. Assignment Team). This Flow is for a new inbox we need to ingest emails from so there's no pre-existing IA specifically for this.

The Incidents are created fine. It is simply the lack of the original email being there in the Activity Log for the "guest" Incidents. It is there on non Guest ones.

Reply Flow nearly works fine. The issue these have for me is that email separators don't work. But don't want to cover that here.

[Tom Sienkiewicz]

Interesting. Not sure I can recreate your exact situation, but for the emails to be displayed in the Activity Log, what I think needs to be there is the target table and target (instance) fields populated.

I would compare an email that inserts Incident and is not showing up, to another email that also inserts Incident and is showing up, and I would go field by field to see what the actuall differences are... maybe this will produce some useful hint.

There activity log itself is a black box, so not sure if it does restrict email records based on anything else.

Re. sys_history_set, can you first ensure that the newly received email has the target table/target fields populated, and only then open up the Incident form? Since the set is generated on first view of the record, I think.

[mark_oldroyd]

So it seems to be tied whether there's a userid listed or not in the trigger email. I tried changing this in the workflow before the create incident step but that didn't work.

I did find a workaround for my scenario. I created an Email Filter.

https://docs.servicenow.com/bundle/sandiego-servicenow-platform/page/administer/notification/task/t_CreateAnEmailFilter.html

This allowed me to set the UserID for the email in the script section. It looks like these filters are applied before Flows and IAs are run.

[Tom Sienkiewicz]

Hi, glad it worked out for you.

I vaguely remember having some issues with Email Filters updating my email records multiple times, in the end I would end up just creating a Business Rule on sys_email table which pretty much does the same.

I would suggest to double check for that using system logging, if it looks good then it's all good 😉

[mark_oldroyd]

Tomasz,

Thanks for trying to help with this. I think I'll follow your experience by using a Business Rule instead. More intuitive to find!

I also noticed over weekend that the original email wasn't actually there for known users either unless you put in the step to update target and target table on trigger email. Is that a normal step in Inbound Email flows? Or should I take this one back to SN support?

Thanks,

Mark