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

For years I’ve been working with ServiceNow and every time, one thing that always got to me that I never understood how it was accomplished was when viewing a sc_request record in self service view, it always re-directed to the order summary UI page.

I just couldn’t figure it out and just assumed it was some hard-coded logic hidden away from us… until now! (yes, I’m a little excited about this…)

Continue reading

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:

Continue reading

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