Inbound email actions are a truly stunning feature for 'processing emails.' It is scalable and simple design to a high standard that does not require expertise to develop them. Incoming emails with matching inbound actions are an ideal combination to provide a fine level for processing for incoming emails. It provides real feel of control and the scripting power mixed with modern email settings for very different scenarios. Independently tucked away, the inbound actions are executed by matching the incoming emails.

Let's talk about incoming email actions that do not have a real update. Not all emails that are processed will have a target set, even if the system has classified it as a reply with a matching record. This is normal.

Lets talk about:

• Incoming emails and matching inbound actions
• What is a 'real' update
• Examples to test incoming emails with no 'real' updates
• How to force the incoming email target
• Advanced cases when target table is none in the inbound actions

Incoming emails and matching inbound actions

Incoming emails are emails sent to the instance. The incoming emails are classified following an algorithm as New, Reply or Forward. Inbound email actions enable an administrator to define the actions ServiceNow takes when receiving emails. The feature itself offers a superb level for scripting and a well balanced design for classified emails, saves you time on coding, and guarantees a clear understanding to expand and keep your email actions up-to-date.

Inbound email actions are similar to business rules, using both conditions and scripts. If the conditions are met, the inbound email actions run the script. The inbound action's conditions include the Type, the Target Table and the condition itself. The 'Type' can be None, New, Reply or Forward to match the classified emails. None will match all types of incoming emails. The target table in the inbound action will help to define the GlideRecord created for 'current.' For inbound actions, the "current" is a GlideRecord based on the target table and the information gathered by the email system.

Here is a table to show the relationship between incoming email received type and matching inbound actions:

Incoming	Received type	Classified as New	Classified as Reply	Classified as Forward
Emails	Target record	-	Found	-
	Target record if success	New	Found if data updated	New
	Notes	Target set based on inbound action target table	Target set based on target found on reply	Target set based on inbound action target table
	Logs if there is no update	Skipping 'xxx', did not create or update incident	Skipping 'xxx', did not create or update	Skipping 'xxx', did not create or update
Matching	Type	New or None	Reply or None	Forward or None
Inbound Action	Usual inbound action update	current.insert()current.update()	current.update()	current.insert()current.update()
	Target table	Set	Set — it needs to match email target found with this table	Set

The table shows the incoming emails are classified then matched to the respective inbound actions. Setting the target table makes the inbound actions much easier to understand. Also, setting the inbound action type to None, increases the complexity as the rule matches all received types.

A 'real' update

A real update means that at least one field on the 'current' record has been changed or the 'current' record has been created. If after receiving an incoming email there is not real* update on the inbound action 'current' record, the target field on the matching incoming email will remain empty.

It makes sense as a way to control which emails would display in the activity formatter.

The Incoming email target is only set if the 'current' record is updated or inserted in the inbound action. Otherwise, it remains empty

Examples to test incoming emails with no 'real' updates

Besides inbound actions that do not meet the conditions, there are a few cases where the current.update() does not execute because the data has not changed.

I've created the following incoming email action to validate the behaviour:

Inbound action
Name	=	Update Incident.JS
Target table	=	Incident
Type	=	Reply
Condition	=	current.getTableName() == 'incident'

Script is

gs.log('CS - Update Incident.JS starts'); // comment on prod

// the following line set impact to 2 = Medium

current.impact = 2;

// As the previous change is a static field,

// if current is already 2, no update happens

current.update();

// No further inbound actions are required - stopping them

event.state="stop_processing";

gs.log('CS - Update Incident.JS ends'); // comment on prod

The inbound action looks as follow:

For the test, I have created an incident 'TETS' with impact = 3.

After sending an inbound email to the instance, once it get processed the first time, the following is the result: The incoming email target is set to 'Incident: TETS' as expected. This is because current.impact was 3, then the script change it to 2, causing the current.update() to execute, the the system will set the target to current.

After sending a second inbound email to the instance, once it get processed, the following is the result: The incoming email target is set to (empty) as expected. This is because current.impact was already 2, then the script set it to 2 again, which is not causing any change, then the current.update() do not to execute. Then the system will set the target to (empty). This does not mean the watermark did not match.

I've created a new inbound action that creates a new problem called "vproblem." It looks like follow: After sending an inbound email to the instance, once it get processed, the following is the result: Results: The incoming email target is set to (empty) as expected. This is because the system only tracks the inbound action 'current' to set the incoming email target. As current did not have any update or insert, the the system will set the target to (empty). That is the reason I prefer to use 'current' on inbound actions.

Force the incoming email target

You can manupulate sys_email.instance to set the target and sys_email.target_table to set the target_table.

The following is an example of an incoming email action that explicitly set the incoming email target:

Inbound action
Name	=	Update Incident.JS_1
Target table	=	Incident
Type	=	Reply
Condition	=	current.getTableName() == 'incident'

Script is

gs.log('CS - Update Incident.JS_1 starts'); // comment on prod

// the following lines will create a new incident

var vproblem = new GlideRecord('problem');

vproblem.priority=2;

vproblem.short_description = 'New incident - test - short';

vproblem.description = 'New incident - test - descr ';

vproblem.insert();

// No further inbound actions are required - stopping them

event.state="stop_processing";

gs.log('CS - Update Incident.JS_1 ends '); // comment on prod

// WORKAROUND: To force setting the email target (not recommended)

// This set it to the new record vproblem created

sys_email.instance = vproblem.sys_id;

sys_email.target_table = vproblem.getTableName();

// Or if you need to be set to current

// sys_email.instance = current.sys_id;

// sys_email.target_table = current.getTableName();

The inbound action looks like:

After sending an inbound email to the instance, once it get processed, the following is the result:

The incoming email target is force to be set to the problem created. This is because we manipulated the sys_email record on the script. It could be forced to any record. If the target is empty on the incoming emails, we can assume there were no valid update on the matching inbound actions. Sometimes simple is more.

I have tested this with Fuji and Chrome as the browser.

More information here: