years ago when I was an admin first being introduced to ServiceNow, I remember being blown away by how simple it was to personalize forms, add fields, and design custom form views. Custom views are very easy to make, but I’m always hesitant to recommend them due to the unintended complexity they can cause. The biggest issue with the ‘view’ concept in ServiceNow is that the system insists on forcing that form view onto every record referenced from within it. This issue exists in every ServiceNow instance today. In this article, I’ll explain why this can be a huge problem, and finally, a good way to break the ServiceNow form view inheritance cycle!

ServiceNow Form View Inheritance

The problem:

Here’s an example that most likely exists in your system (and certainly does in ServiceNow demo systems) to help illustrate the problem. If you go to your system and open an emergency change record, you’ll probably notice that it displays the ‘Emergency’ view in the top-left corner of the change form. That’s great, but when you click the reference icon for the ‘Requested by’ or ‘Assigned to’ fields, you’ll see that the system applies that view name (even though it doesn’t exist for that table) to the referenced record form. Then if you click on the ‘Company’ or ‘Department’ referenced record on the user form, you’ll notice that the ‘Emergency’ view name is carried over there as well!

It’s important to note, that the system is not actually creating new views as this happens. It’s simply cascading the previous form view to any other record you navigate to. The label of ‘Emergency’ is actually the smaller, cosmetic-only, issue. The larger issue is when you decide personalize that user or department form as an admin. You’ll most likely end up creating a brand-new view named ‘Emergency’ that applies to your user table! Now you’ve got an extra view and your changes won’t show up in the right place anyway because you meant to customize the ‘Default’ view instead…and you better hope nobody decides to reference that new, garbage view in a module or list definition and have it end up propagating the problem even further.

So, in short, this is a HUGE problem, and one that I’ve struggled with for the past 6+ years. It’s one ‘feature’ of ServiceNow that I’ve never understood, and this alone always makes me very hesitant to recommend the use of views to any of my clients. Fortunately there are a couple of things you can do to work around this…one that’s been around for as long as views have, and one that I came up with yesterday that easily allows you to override view inheritance for any table in the system.

Option 1: View rules

I’m a big fan of view rules and I’ve used them (primarily in change management) for a long time. They allow you to force a particular view on a particular table, for a particular subset of records. To use the change example again, you could set up a view rule to force the Default, Emergency, and Routine form views to display Comprehensive, Emergency, and Routine changes in their own respective views with their own sets of fields and related lists.

This is extremely handy, and can help break view inheritance because it forces a particular view for records in a table. The downside of this is that it’s not really practical to set up a view rule for every record table referenced from the change table just so you can overcome this problem. You could end up with a separate view rule for hundreds of tables!

Option 2: A better way…

Shown below is an example script that we’ve started using at Crossfuze in our Change turnkey product. This script runs on load of a particular table (Change request for example) and manipulates the form to remove any trace of a given view from the reference or related list links. A single client script can solve this issue for you on any table where you choose to set up custom views!

‘Override view inheritance’ Client Script
Name: Override view inheritance
Table: Change request [change_request]
Type: OnLoad

function onLoad() {
    //Override all non-default change view inheritance for records referenced on change
    overrideViewInheritance('routineChange', '');
    overrideViewInheritance('emergencyChange', '');

function overrideViewInheritance(oldView, newView) {
        //Override reference field link view inheritance
        if($('sysparm_view').value == oldView){
            $('sysparm_view').value = newView;
        //Override related list link view inheritance
        $('related_lists_wrapper').select('a.linked').each(function(elmt) {
            elmt.href = elmt.href.gsub('sysparm_view=' + oldView,'sysparm_view=' + newView);