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 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.

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.

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');

        else

                  g_uri.set('sysparm_view', '');

}

answer =   g_uri.toString('hr_case.do');

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()) {

                  g_url.set('sysparm_view'),'ess');

                  answer = g_url.toString('hr_case.do');

        }

}

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