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;
current.update();

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
current.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

UP3 Thrives: Major customer wins; sector prowess; and ServiceNow ecosystem growth

The story of how UP3 has become a highly respected partner in the ServiceNow ecosystem.

Find out more

Advanced MID Server Series – Part 3 – Standard MID Server classes

The third on our Advanced MID Server Series, this time explaining the Standard MID Server classes available to use as a developer.

Find out more

What it means to be UP3’s Head of Managed Service: Q+A with Ian Wynn

A fantastic interview with UP3's Head of Managed Service which provides some valuable insight into what makes our ServiceNow Managed Service so good at delivering for our customers.

Find out more