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

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

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 (https://instance.service-now.com/channel.do?sysparm_channel=logtail)

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

Within ServiceNow, anyone can go to any table by manipulating the URL or via the navigation menu.

I.E, if you want to go to the incident table, even if you haven’t access to the incident module, you can just:

Having ACLs in place makes sure that the actions that you don’t want to happen don’t happen (create, write, read, delete). However, what if you just want to stop navigating to that URL in the first place?

You can stop users getting to the page via the navigation menu by editing the ‘NavFilterExtension’ UI Script (it has very good comments in there and easy to edit to do what you want).

I accidentally stumbled across a neater solution, again using ACLs.

Continue reading