How To Let A User Know Who Last Accessed An Incident

A common requirement I hear a lot is how to give itil users the ability to know that someone else is working on the same ticket as them. Out of the box, ServiceNow have provided an on submit client script which checks if there’s been an update since you’ve been working on the incident. However, my issue with this is it’s happening after the itil user has already spent some time working on the incident when someone else is already dealing with it.

It’s an inefficient way of working. So I came up with a different solution, one that checks when accessing an incident, whether someone else has accessed it since it’s last update within the last 30 minutes.

If someone other than you viewed the incident, an alert will be shown to the itil agent letting them know who accessed the incident and when. This simple solution provides enough information for the itil user to make an informed decision as to how they wish to proceed with the incident.

Continue reading

Stopping Updates Being Captured Within Update Sets

Before I begin, let me start off by saying this one probably isn’t going to be that useful for most people… I’ve only ever had two use cases where I needed this but I’ll share nonetheless.

There may be a scenario when you are updating table data via script whose updates are captured in an update set. An example of this, is in one of my previous implementations, I was dynamically creating business rules via a script. These shouldn’t have been captured in any update set and should be handled via the script only.

To do this, I discovered a session property to switch this off the update sets and then switch it back on again. To switch it off, run this command:

Continue reading

How To Pass Sensitive Data Via GlideAjax

Sometimes the data that you’re passing back from the client is sensitive data which nobody should be able to read (including administrators).

One particular instance for this is if you are passing a password back to do validation.

Also, sometimes some GlideAjax’s you just do so many times, that it’ll clog up the logs and possibly cause performance issues with the constant writing.

The logs I am talking about here are the Apache Tomcat logs (

Give it a go, have one window open with the logs and in another window run a GlideAjax and watch the information that’s written to the logs.

There’s a very simple parameter which you can use to prevent this logging:
Continue reading