How do you handle incoming emails from D/Ls or shared mailboxes

[johnfeist]

The challenge that I see is that users send emails from those shared objects.  They are accepted but then the members complain about getting email for incidents that they didn't create and can't access.  The later part can be for one of two reasons.  The obvious first one being that in the service portal, the incidents widget doesn't recognize the members as the caller on that incident.  The other reason is that we have internal firewalling that segregates incidents because we have a number of internal help desks.  Some of those incidents can have very sensitive information in them.  The partition rules are that regardless of the partition, a user can see incidents on which they are the caller.  If the user doesn't have access to the partition where the incident has been assigned, they don't see it.

I'm curious how others handle emails from those shared objects.

[DylanB]

We are also interested in this and I had a couple of avenues of thought, but none of them are great solutions so I'm replying to hopefully rekindle this conversation!

My first thought was to identify shared mailboxes from email headers, but from my research, email headers don't offer any identification of whether the email was from a shared mailbox, so that's a dead end. 

Our shared mailboxes are automatically added to the sys_user table in our organization. Those shared mailbox user records don't have info such as an employee number, title, department, or manager. The inbound email actions could be adjusted to require the user to have an employee number, etc. This solution allows too much room for error though.

Of course, specific shared mailboxes could be blocked from sending in but that's not practical either. 

[Israel Baral]

I would treat this as a training and process issue. In general its a bad idea to accept incidents from email. But even more so from anonymous accounts. If this were my company I would push to remove/deactivate DL/shared inbox accounts from the user table in servicenow and if a user sends an email from that type of account it should just bounce. (maybe you can find a way to check if its an inactive account using an inbound email action and send a response recommending using the appropriate portal).