ServiceNow instance ignores email sent by another instance (Recommendations)


Description


Email loop: ServiceNow instance ignores email sent by another instance



Symptoms


You build an email-based integration between two or more instances and send an email to another ServiceNow instance, but the receiving instance ignores emails coming from the sending ServiceNow instance.

Or, you receive an email that gets ignored because it contains the header "X-ServiceNow-Generated:true"

Cause


The X-ServiceNow-Generated:true header exists on an instance's outbound email. Instances also have a property glide.pop3.ignore_headers (or a filter if the Email Filters plugin is enabled) that by default prevents processing those emails.

This default configuration prevents an email loop that could form when instance A emails instance B, and instance B then processes the email, performs a record update, and a notification sends an email of its own back to instance A, which does something similar, then responds back, and so on.

ServiceNow prevents this kind of interaction by default because these implementations are easily broken, and it has has been shown to cause varying incidents and outages. 

Solutions


Implement a Web Service Integration – recommended

Customers implementing instance-to-instance integrations should use web service calls between the instances, which avoids the ambiguity inherent in trying to distinguish human-generated and system-generated inbound email to drive an appropriate system response.

Implement an Email-based Integration

ServiceNow does not recommend integrations between instances via email notifications because it is fragile and easily broken.

A decision to integrate two instances in this manner must be considered with care.  It is imperative that you regression-test your instance-to-instance use cases. For example, simple changes to inbound email actions or filters can easily cause an automated email to slip through and create an incident, rather than execute the integration action you intended and tested when first deployed.

Before removing the inbound email filter or property header that prevents the email from being processed, customers must consider the automation scenarios possible when two instances email each other.  Some areas where things can go wrong are:

Test email between automated systems as follows:

  1. Define outbound email use cases.

  2. For each inbound receiving instance, define handling use cases.

  3. Remove the inbound filter on test instances that receive emails (or update the ignore headers property) to allow the instance to process emails sent by other ServiceNow instances.

  4. Test each instance's behavior to ensure that email loops do not occur.

  5. Send an email from a third instance if you have a subprod available.  Does this email from an unintended instance behave as you expect?

Note – Make sure to retest email integration use cases after any changes to the email process on either instance.