UP3 - Callum’s Blog – Inbound Actions – Something you might not know…

Callum’s Blog – Inbound Actions – Something you might not know…

I’m sure we have all encountered issues with inbound actions at some point during our ServiceNow development careers, but today I came across an issue that that left me tearing my hair out.

The Requirement

An Inbound Action that only updates the state of a record and attaches the email to the record so that is is visible in the activity stream / related list.

The Problem

The Inbound Action would only sometimes work, but would always stop the processing from continuing further down the chain of other Inbound Actions, even though the Inbound Action in question says that is has been skipped in the logs.

The Resolution

Take the following Inbound Action script:

current.state = 2;

On the face of it, the above code looks relatively harmless. The Inbound Action will be triggered, the current record will be updated and the email will have it’s target set to the current record… Unfortunately this is wrong! Let me explain.

Imagine that your current record has a state value of ‘1’, and now imagine what the code above is going to do when an email comes in that triggers the Inbound Action… yep, you got it, it’s going to change the state of your record to ‘2’ and then then update the record.

Now imagine that a second email arrives for this same record, so let’s run through the code again. The code is going to ‘change’ the state of your record to ‘2’ and then update the record, and this is where it falls apart! The code is not changing anything on the record as the state is already ‘2’. In this situation therefore, current.update() actually does nothing.

At first you might think that this is not an issue, however there is an (undocumented?) feature of Inbound Actions that means this is fairly problematic. If the ‘current’ record is not updated, then the target of the email will not be set, and this means that the email will not be attached to the record. So how to solve this, whilst still meeting the requirements set out above. The following code should do it:

current.state = 2;
current.sys_mod_count++; // force the record to change so that it will update

And that is really all there is to it, by calling current.sys_mod_count++ we are ensuring that there is a change on the record, and thus we are ensuring that the record will always be updated, so if you have ever found yourself with emails not attaching to records in your instance, check to see if this might be the cause.

As far as I’m aware this is undocumented in the ServiceNow documentation site, so I hope this will help someone get out of a hole at some point.

Callum Ridley

Written by:

Callum Ridley

Technical Architect

Recent blogs

Advanced MID Server Series – Part 2 – A Better JavascriptProbe

In this article we will be creating our own version of the JavascriptProbe Script Include that adds additional functionality and helps us protect our sensitive data in transit.

Find out more

Advanced MID Server Series – Part 1 – Scripting Deep Dive

The first in our series looking at Advanced MID Servers. Taking a look at scripting on a MID server, including how to run MID Server Scripts

Find out more

My first 6 weeks at UP3 as a Technical Consultant: Adam Cawkwell

Q+A Blog interviewing a SeviceNow Technical Consultant on their first six weeks in the job, to learn about their goals, company culture, and working with ServiceNow.

Find out more