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.
