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!

[Tom Sienkiewicz]

I wonder if the below restriction can be the cause of your issue:

But this would mean that those emails would not even get processed. If you look up such an email in the sys_email table, what can you see there? Is the target record set? What is set in the User fields? Any errors in the email log?

[mark_oldroyd]

Hi Tomasz,

Thanks for your reply.

Yes the Flow still gets processed and creates the Incident just fine. It's just that original email that is missing.

In the emails themselves:

User is set to senders email address as per normal.

Target Record and Target Table are empty.

I did wonder if this is was issue, and tried adding an additional step that updated these fields in the email. That part worked, but still does not add that email into the Activity Log.

I also tried the Create Incident and Update Email record in parallel and still no luck.

I'm now wondering if the only way it is possible is via an entry in the initial sys_history_set for the Incident. Feels like this sort of thing might be frowned upon if it's even possible. But then it could be exactly what an Inbound Action does behind the scenes.

Else I might need to settle for dropping the original email in work_notes as a compromise.

Thanks,

Mark

[Tom Sienkiewicz]

So I just tested this, but for an update from email (receive type = Reply), and this is in the log:

The workflow was not run since the user was not matched. Are you 100 % sure your workflow runs, and not some inbound action? If you go to Flow Executions, is the relevant execution there?

In any case, I think you can try one of two options, create some business logic (e.g. a before insert BR) on your email table (this is generally considered as risky but I don't see any other option TBH), and either try and set the user field to the "guest" user if no other user found, or enforce impersonation of the guest user.

I think the guest user should have access to your records then.

[Tom Sienkiewicz]

I think it could be that flow designer already impersonates guest if it cannot find the user (don't remember 100%), if so then perhaps check if your guest user passes the ACLs to create/update records.