Can we use multiple inbound email addresses for incidents

tom22
Kilo Explorer

Not sure this is the right forum for this question... if not sorry...

We are moving from ConnectWise to SNOW Fuji.

In ConnectWise we have a couple different email addresses that are used for our customers to create incidents/tickets.   Used for Incoming Email to an Inbound Action Type.

I see in SNOW it has a default email address of companyname@service-now.com.

Can I add additional email addresses like we have in ConnectWise, e.g. companyname@domain.com?   Instead of forwarding companyname@domain.com to companyname@service-now.com?  

When we use forwarding don't we loose the header feature and options for inbound action types?

Thanks,

Tom

12 REPLIES 12

If I complicate this too much let me know.

 

We have one large single inbound action and dozens of "smaller" ones that are purpose built. Our one large action accepts email from 20-30 email addresses (could be more by now, I don't keep track but simply keep adding them in). Within the action we "split" the addresses into assignment groups (e.g. IT is in charge of techsupport@ourdomain.com, itsupport@ourdomain.com, ithelp@ourdomain.com) to create the Incidents.

We do have the odd case where an email needs to trigger multiple record creations. In these case we just populate our conditional logic appropriate. For example an email from our Server Room environmental warning system may create an Incident to investigate the immediate cause (high temperature) and a Request to investigate how to prevent it in the future (higher capacity AC units).

So our typical flow is one email generates one record (Incident, etc.) and what that record contains is custom to the email address (e.g. Category, Assignment Group). However there are a handful that actually create/update multiple records.

In short, yes, each of the email addresses creates it's own record through the single inbound action. The values in the record created are different for each email address that created it (like Assignment Group).

 

Because I sometimes type too much I will share some experience. Having one large condition will also be more to maintain, and the risk brought forward with something as simple as a typo could impact all of those addresses. I am not a fan of this level of risk, and would ideally like to see our one big inbound action split apart into department-level (or work-unit level) pieces. That way if we accidentally break one the impact is smaller, and when we do a change request we are getting the right approvals because it only impacts one area.

The challenge is breaking apart a perfectly functional one will create a large amount of work and we are already quite busy doing other development that will generate other more direct benefits. If I was developing from scratch I would instead use multiple inbound actions and not "stop processing" automatically, but rather only if I found and matched my logic. I think this would be easier to maintain in the future and remove the risk of one minor mistake taking down dozens of incoming email addresses.

Solid, thanks for the great explanation. 

How do we know the recipient if we are forwarding mails from our configured email addresses to ServiceNow email? Because we do want to know the requested person's name on our tickets which we want to create in ServiceNow

We use Microsoft 365 and when we setup forwarding at the mailbox level, the message is forwarded with all the information intact. ServiceNow receives the message with the original address in both the To field and From field. Here is an example:

TrevorK_1-1714967575609.png

 

The header shows that the original message was sent to the mailbox in question and is redirected to ServiceNow.

 

I think this is the confusion. When we mention "forwarding" we really should be saying "redirect". The problem is in the Microsoft 365 interface it's not labelled like that (or wasn't the last time I looked). But if you have your email administrator set it up to redirect then ServiceNow will receive the message and interpret it properly (where it keeps the to / from address).

 

In our environment (Microsoft 365) the problems we encounter is when users try to do it themselves and setup a mailbox forwarding rule like they do an out of office rule (or a rule that moves messages around their folders). Often I just tell our email admin to do it on their behalf to avoid this. 

Michael Kaufman
Giga Guru

We use the email forwarding like Trevor mentioned.   I also know in ServiceNow Geneva you can setup multiple Email accounts.