inbound-email

Inbound Email for ServiceNow

This guide is about mail arriving at the instance: a message lands, the platform classifies it, and an inbound email flow or action turns it into a record. Mail leaving the instance — notifications, templates, mail scripts, weights — is a different subject; see email-notifications.

Three things account for most of the time lost here:

1. Inbound email flows run before inbound email actions and can end processing entirely. Debugging the action list on an instance that uses flows is looking at the wrong layer.
2. Inbound actions run in order, and stop_processing on a matching action suppresses the actions that come after it. People consistently read that arrow backwards.
3. Several snow_inbound_email_action arguments do not write the column their name suggests. The column does not exist, so the value never persists, and the tool's create response reports only sys_id, name and type — nothing in it tells you a field went missing.

Three tables carry all of it: sys_email (every message, inbound and outbound, one row each), sysevent_in_email_action (the inbound email actions — condition plus script, evaluated against received mail) and sys_email_account (the mailbox the instance polls over POP3/IMAP or sends through over SMTP).

What happens when a message arrives

1. The instance polls the account in sys_email_account and inserts a row in sys_email with type=received. Inbound mail sits in the Received mailbox until it is processed.
2. The platform classifies it as forward, reply or new, stored in sys_email.receive_type.
3. Inbound email flows run first. ServiceNow: "Inbound email flows take priority over inbound email actions. If you create flows with inbound email triggers, emails are first processed by the inbound email triggers before they are processed by inbound email actions." If a flow issues stop processing, the email is finished; only an email matching no flow falls through to actions. (https://www.servicenow.com/docs/r/platform-administration/processing-inbound-emails.html)
4. The instance walks the active inbound email actions in order, lowest first.
5. An action runs when sys_email.receive_type matches the action's type and its condition matches.
6. If a matching action has stop_processing=true, the actions after it never run — provided orders are unique, see below.
7. The sys_email row's state moves off Ready. Nothing is retried: if nothing matched, the message is consumed and no record is created, with no error anywhere. That is why this is hard to debug.