Posts from December 2013 on Service Now Gems

Issue: For one of my projects, we had different views on the tasks than we did on the parent case. However, if you click on a task with a view called ‘Task view’, when you clicked the parent, the parent would inherit this view (even though we didn’t want it to). It would even ignore view rules set up specifically for that record. This was the same with all reference fields.

Solving this turned out to be a one line piece of code.

Continue reading

Sometimes, you only want to run a script if the user is on a particular view. I’ve had a couple of these requirements (albeit it they are very rare! Usually there are other ways around it). But anyway, if you can’t think of any way around it, a small little script can be used to determine that view:

So we’ve seen when creating new modules there’s a number of arguments and one of these are HTML.

So what can you do with this HTML field? Answer is pretty much anything you want! It doesn’t need to just be a link. Check out the video for a few examples and click into the article for the simple steps to reproduce these!

Very quick one…

This only applies to anyone working on a clustered environment using multiple application servers.

Going to the ‘Logged in users’ module only shows users logged into the same node which you are logged into.

So I wrote a quick script which you can use to print out the total number of users logged in across all nodes:

Views in ServiceNow are a very useful tool, but there are a lot of little ‘gotchas’ you need to be aware of.

One of these is using the ‘View’ field when creating a module. The expected behaviour is simple, you enter for example the ess view, you’d expect whenever the module was clicked, the ess view would be displayed.

Not exactly how it works though! The video attached shows this in action… The first time you select the module, it’ll select the view you entered into the module. But, if you manually change the view, it will remember this and even the next time the user clicks this module, it’ll use the view which you changed to rather than the view that you selected!

A simple argument to the URL can resolve this issue, and force the view to be what you selected it as.

Note: sysparm_view does NOT work and sysparm_force_view only allows one view to be selectable which isn’t what we’re looking for.

So, the answer? Simply add these details to the arguments:

Continue reading