Skip navigation

Developer Community

2 Posts authored by: Jordan van't Hof Employee

ServiceNow offers a number of ways to control what and how a user views data in forms and lists. This can be based on roles/groups the user has or is in, or the type of record being viewed. I will go through View Rules and Navigation Handlers in this blogpost, as well as a scenario that may arise causing your View Rules not be be applied. You can control the view applied via a global Business Rule; however, this is not supported by ServiceNow support.


View Rules

View Rules are a simple condition based method to determine which View a user will be presented with when viewing a form or list. If the user has the ability to switch Views, normally the View they select will then be saved and used for each subsequent visit to a record on that table. A View Rule will override the User Preference and always forces the same View of the form or list.


view rules.jpg


You can specify the device for this to run on (browser/mobile etc) and the desired View among other options. Starting with Geneva scripts can also be used in View Rules.


Navigation Handlers

A Navigation Handler is a scripted View Rule essentially and is run each time data from the specified table is requested in the form view. The scripts are typically in the form below and are fairly self explanatory in checking for a role and specifying the view:

var gr = new GlideRecord(hr.TABLE_CASE);
if (gr.get(g_uri.get('sys_id'))) {
     if (!gs.getUser().hasRoles()) 
          g_uri.set('sysparm_view', 'ess');
          g_uri.set('sysparm_view', '');

answer =  g_uri.toString('');

The script above will force the ESS view for users with no roles, and use the default view for all other users. This example is taken from an out of the box Navigation Handler installed with the HR Plugin.


View Rules vs. Navigation Handlers, which takes precedence?

The order in which View Rules and Navigation Handlers are applied is controlled by a system property that was introduced in Dublin. The system property is: glide.ui.view_rule.check_after_nav_handler


The type is "true/false" and must be set to value "true" to process View Rules AFTER Navigation Handlers. If it is set to false, then Navigation Handlers will take precedence over View Rules. If this system property does not exist in your instance, then regardless of View Rules for the table in question, the Navigation Handler will always take precedence.


There is a further caveat with this system property, in that it will only override the Navigation Handler if the Navigation Handler scripted function does not return an answer. In the example script above, the property will have no effect as the Navigation Handler will always return an answer due to the "answer" line being outside the if statement.


To force the Navigation Handler Script above to honour View Rules for the table you will need to add the property above (and set it to true) and also update the code to only return an answer when the view needs to be changed/forced:

var gr = new GlideRecord(hr.TABLE_CASE);
if (gr.get(g_url.get('sys_id'))) {
     if (!gs.getUser().hasRoles()) {
          answer = g_url.toString('');


The order in which the View Rules and Navigation Handlers are executed depends on the system property and the structure of the Navigation Handler script. View Rules will be applied when the system property (glide.ui.view_rule.check_after_nav_handler) is false and the Navigation Handler script does not return an answer. The Navigation Handler will take precedence if the script returns an answer or if the system property (glide.ui.view_rule.check_after_nav_handler) is set to false.



In the case that you run into View Rules not being followed for individual records on the Request [sc_request] table, see View Rules are not followed for individual records on the Request [sc_request] table (KB0522746).

If you've ever run into trouble creating any client side scripts in your ServiceNow instance (Client Scripts/UI Policies etc.) you may find the following tool very useful. It's known as the Javascript Executor and is one of the ServiceNow support team's first points of call when investigating any client side issues or questions that our customers may raise.


It's important to note that this will only work for Client Side scripting; any server side code will not execute and must be executed in "Scripts - Background." This module is only available to users elevated to security admin level.


There is a Javascript executor built into your browsers, but the benefits of using the ServiceNow Javascript Executor is that the last executed code is still in the window so it can be modified to correct errors and test again immediately. Also, the Javascript Editor works on the main content frame, so for forms within iFrames (ie the console javascript editor works on the top frame so it cannot interact with iframe forms resulting in errors like "g_form.field is undefined."


If you have a large client script that is not working correctly, you can segment it into parts and test each portion in the Javascript Executor to find where the error in logic is.


There are two modes to the Javascript Executor:

1. The Javascript Executor

2. The environment variable browser



The Javascript Executor

To open the Javascript Executor you must be an administrator and simultaneously press "Alt+Ctrl+Shift+j" in a window within your ServiceNow instance to see the popup below:

javascript executor.jpg


Example of opening the Javascript executor on your ServiceNow instance:

1. Open an Incident form

2. Press "Alt+Ctrl+Shift+j" to open the Javascript Executor

3. Paste the following code in place of the "Type JavaScript here" text:

var id = '62826bf03710200044e0bfc8bcbe5df1';
var name = 'Abel Tutorer';
g_form.setValue('assigned_to', id, name);

4. Click "Run my code"


You will see that the assignee on the Incident form has become "Abel Tutorer" - I have deliberately used a bogus sys_id and username to prevent the form being accidentally submitted with the wrong user details.


If the code you execute in the Javascript Executor does not work, you can use the developer tools console as a back up. The Javascript Executor tests client side scripts on the fly with immediate results when combined with the developer tools of the browser of your choice in real time. Open the developer tools console to see if errors appear and you can debug as necessary to ensure your code works as desired. You can use the ServiceNow debug console ( Using the JavaScript debug window ) or the browser's javascript console to display all client side errors.



Using the Variable Browser

To access the Variable Browser you must be an admin user and have the Javascript Executor window open. In the Javascript Executor window, click the dropdown menu on the bottom left to select "Browse vars".

browser vars.jpg


"Browse vars" shows all available browser environment variables on the current form and their current value if it has been set. For example, I found the title attribute via "Browse vars." It was set to "ServiceNow" and the element was "document['title']." If I want to change this on a page, using a client script,  I could test the following javascript in the "Javascript Executor" to change this on the fly before implementing the code in my script:


document.title = "ServiceNow Rocks!!";


Now, when I use browse vars after running that code you can see the updated page title variable. The beauty of running this in the Javascript Executor is that no change is permanent, so refreshing the page will return the title value to the original value. A simple example purely to illustrate the types of variables you can interact within your client side scripts and how you can test snippets to ensure they work before applying to larger client scripts.


If there is any error in the code, using the browsers developer tools console you will see something similar to the below:

Uncaught ReferenceError: title is not defined

The above error was from my trying to update the title variable as below (which is incorrect):

document['title'].value="This will produce an error";



While my examples above are trivial fiddles, this is a very powerful tool and is invaluable for quickly creating and debugging your client side code. We always recommend to test in sub prod environments and this is no exception as with all client scripts within ServiceNow you have an interface that can cause plenty of trouble which is why it is locked down to administrators. Please feel free to ask any further questions here about this great little tool and I will be happy to assist.


For more debugging and troubleshooting information see:

Using Chrome to Debug Client Side Errors

Debugging the Mobile UI from your Desktop

Strategies to isolate and debug an issue

Debugging SAML in ServiceNow and ADFS 2.0




Filter Blog

By date: By tag: