Intercepting Record Access

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…)

Turns out there’s a hidden table in ServiceNow which holds this routing logic called sys_navigator. In here, you can intercept direct record access and re-direct it to another page, or add parameters, set parameters etc.

So let’s look at the sc_request out of the box entry in more detail. First step is to select the table it impacts which is pretty self explanatory.

The code associated with the sc_request table is:

var view = g_request.getParameter(‘sysparm_view’);
if (!view && !gs.getUser().hasRoles())
view = ‘ess’;

if (view == ‘ess’ || view == ‘checkout’) {
var checkOutForm = gs.getProperty(‘’, ‘com.glideapp.servicecatalog_checkout_view’);
var useLayouts = new SNC.ServiceCatalogLayoutService().useSCLayout();
if (useLayouts == ‘true’ || checkOutForm == ‘com.glideapp.servicecatalog_checkout_view’) {
var realID = g_uri.get(‘sys_id’);
g_uri.set(‘sysparm_sys_id’, realID);
g_uri.set(‘sysparm_new_request’, ‘false’);

if (useLayouts == ‘true’)
answer = g_uri.toString(‘’);
else if (checkOutForm == ‘com.glideapp.servicecatalog_checkout_view’)
answer = g_uri.toString(‘’);



So looking at this what’s it doing? It first reads the sysparm_view parameter. If the view is empty and the user has no roles, it automatically sets the view to ‘ess’.

It then checks if the view is either ess or checkout and if so, gets the sys_id parameter using g_uri.get() and then sets some additional URL parameters using g_uri.set().

Finally, it sets the result to the global ‘answer’ variable which is used as the redirection url.

So adding two log statements, one right at the beginning logging g_uri.toString() and one right at the end using answer. What we see is this

Initial URL:

Final URL:

I’ve highlighted the parts that have been dynamically changed in this script.

So why am I so excited about this? Well, there’s been loads of times where I’ve wanted to force a form view based on particular conditions.

Using the View Rules table, you could only do this using field values.

Using a global business rule, you could only do this using user roles.

But with this, you can do it using the user’s roles (or lack of) plus field values (the ‘current’ GlideRecord variable is available to use in the code) plus the request URL parameters plus anything else you want to use in the system (system properties or configuration tables for example).

Hopefully you’ll find some good uses for this going forward


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s