[UPDATE] – Released a new version of the node switcher
Completely new UI
Automatically recognises ServiceNow instances behind custom URLs (eg, recognises developer.servicenow.com as https://devportalprod.service-now.com)
Works on instances where stats.do page is restricted
As ever, let me know if you’re having any issues with it
There’s a new feature I’ve just learnt about in Kingston.
Using the GOTO feature for searching (image below), the out of the box query that is run is a greater or equal to search.
ie, if I was on the sys_user table, and for the field “name” I searched for Ahmed, it would find all names >= Ahmed. This would return “Ahmed Hmeid” but would also return “Bob Smith” and “Carla Jones” just because they’re alphabetically greater.
I’ve always had issues with this because
1) I didn’t search for Bob so don’t want Bob in my results
2) it’s not very efficient
Pre-Kingston, you could change the default query to be “greater or equal to”, to “contains”.
While this gave better results, it produced far more performance issues because “contains” queries cannot utilise the indexes at all.
Now in Kingston, you can change the default query to “starts with” (finally). This is generally what people expect when they type in the GOTO field. This approach is far more efficient for a better user experience. It also will give more accurate results based on what the user expected to see.
One of our customers is going through some rationalisation and simplification of their ServiceNow implementation. One of the many things we’re looking at, is reducing the number of fields available on CMDB and Task table. I couldn’t find any out of the box method to determine field usage, so I decided to attack this with a little background script.
The script goes through the base class that you pass in as an argument, and gathers all the fields available on that class. It then loops through these, discarding OOB fields by default.
It will then create a row for each extension class, the first column being the class name, followed by the total number of records directly on that class, followed by all the fields available on the table and their usage.
Once completed, it’ll create a CSV file and attach it to your user profile on the sys_user table.
A word of warning, it can take quite a while to run so either run it as a background script and get yourself a coffee, or run it as a fix script/scheduled job so you can continue working. Also consider running this outside of your core business hours.
I checked it on our customer’s CMDB table (1.5mil CIs) and it ran in 30 minutes and while the memory and CPU impact were minimal, running code during operational hours isn’t ever a good idea.
I am working on a new scoped app. One of the things it does is sets fields to mandatory.
My app is a generic app designed to work on all fields, whether in scope or not. But with the scoped apps this isn’t possible.
It turns out there’s a check that looks to see if the field you’re amending is part of the scope or not, and if not, will print an error in the console along the lines of:
Mandatory true not set on field impact: cross-scope access denied.
Sometimes you can run a piece of code, click an action, just generally do something a bit heavier than you expected and the transaction hangs and takes a long time to complete.
If you are in a window with the top navbar visible (the part with your name and setting etc.), then you will see a red cross appear with the time running. Clicking the cross will cancel your transaction. But what if you’ve opened up the main window in a new tab without the navbar?
If you’ve ever had performance issues within ServiceNow, chances are you’ve gone to look at the performance dashboards to see if anything looks “funny” there. If not, you then check the stats.do page.
Recently I’ve been working on automated monitoring, spotting a situation arising before the customer notices the system is going into slowdown.
While doing this I’ve discovered a new table with a whole load of metrics to read from. 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
