Communication between organizations both using Service Now?

[Leonard Ambos]

I found that incoming email from another organization that is also using ServiceNow was marked received-ignored by the "Ignore header" email filter, since the incoming message headers contains "X-ServiceNow-Generated:true". There's a handful of other community posts which touch on this topic, but they all seem to lead to the same HI support post which recommends Web Service Integration, since Email is fragile and can be easily broken and cause loops.
https://hi.service-now.com/kb_view.do?sysparm_article=KB0551482

Coordinating with owners of other instances might work in a more controlled environment, but enough other organizations use ServiceNow that it doesn't sound feasible to coordinate with each one, even if we had an exhaustive list. We're hesitant to change the filter, as it sounds like if the two instances start generating messages at each other it could easily start a loop.

I'm reaching out to HI support to check for an official answer, but wanted to see if anyone else had workarounds to ensure messages between organizations that are both using Service Now are not ignored or dropped?

Additionally, reviewing outbound messages for our own instance shows they are using the header "X-ServiceNow-Generated: true" (with a space between the key and value), so I'm not sure that our own messages would even get caught in this filter.

[sachin_namjoshi]

These inbound emails are getting ignored and moved to JUNK due to OOB email filters.

you will need to update condition in these email filter to allow inbound email from another service now instance.

But, as per HI article, it's not recommended since it may cause performance issues due to loop.

Regards,

Sachin

[Leonard Ambos]

My question is how are other organizations getting around this?

We're using the HR module so external organizations often write into HR asking about work verification, etc. If any of those organizations are ALSO using ServiceNow and send mail using SNOW, there's absolutely a risk of creating a loop, since any autoresponse we generate and send back could prompt autoresponses from the external organization's instance. The HI article talks about setting up REST endpoints, but that doesn't seem feasible as this would be a problem for EVERY company using ServiceNow. There's just no way to get an exhaustive list of companies that are using ServiceNow and coordinate with each one to establish a communications channel outside of email.

I'd assume this is a problem for any organization that coordinates with external organizations through email. I may be running under a flawed assumption that other organizations using ServiceNow coordinate with external contacts through email; maybe they only use SNOW for internal contacts, and handle external separately?

Should we just be handling email requests from external organizations outside of Service Now?

[ryan_pope]

Per ServiceNow's suggestion, a REST call would be much simpler and much more stable. As a general rule of thumb I avoid the use of reliance on inbound actions as often as possible as there are too many variables at play that we can't control (mail servers, applications, filters, etc), and think it's worth the effort to work with those other entities to follow suit.

If that is absolutely not an option, I can think of a few "sketchier" ways around it:

1) Tweak a filter to permit SN-to-SN emails (despite that header tag). This would still require lots of logic be written to prevent looping of updates between the instances.

2) Business Rule on sys_email table that can override (or remove altogether) that header tag. If memory serves, a "before" BR on this table will execute on an email prior to it being evaluated by inbound actions.  This would also require lots of logic be written to prevent looping of updates between the instances

3) [I am not a email admin, so this may not work] If you set up a proxy email address that the other SN instances pointed to, and then had that forward to your instance, that may give an opportunity to remove the header, external to the platform?

If you have the communication open to the company's sending emails in (it sounds like you do because they have your instance's email address to send to), I would STRONGLY recommend using that communication channel to push towards a RESTful solution.

[Leonard Ambos]

You mention that it sounds like we have open communication with the company sending emails in since they have our instance's email. We actually just recently adopted ServiceNow, and one of the decisions made was to re-direct a number of pre-existing support addresses that handled both internal and external contacts to our ServiceNow email address. As a result, we could have anyone write in, and have no way to predict who or how they'll contact us.

Is there a recommendation on how to handle requests from external individuals/organizations that we don't have a pre-existing relationship with?