6+
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!
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!
Name: Override view inheritance
Table: Change request [change_request]
Type: OnLoad
Script:
//Override all non-default change view inheritance for records referenced on change
overrideViewInheritance('routineChange', '');
overrideViewInheritance('emergencyChange', '');
}
function overrideViewInheritance(oldView, newView) {
try{
//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);
});
}catch(e){}
}
Hi Mark – Is it possible to overwrite the view rule by any chance?
There isn’t any way I’m aware of to override a view rule.
Hi Mark,
it’s been a while since you left this post however was hoping you could help me. I’m really not an expert in dev but would like to reuse your script in order to be able to open the sys_popup view instead of the default view when opening the record using the reference icon (to be able to apply certain rules on this view only).
I just made a try of your script with the incident table but it seems that by default the sysparm doesn’t appear in the URL meaning that the gsub doesn’t replace it with the new syspam_view value.
Would you be able to help me here ?
Thanks in advance
Agathe
Hey Agathe, the reference icon popup is controlled by a ‘sys_popup’ view that you can create or modify for each table. In absence of a ‘sys_popup’ view, the first form section of the default view is used. In order to create or modify the ‘sys_popup’ view for a table you can follow the instructions in the ServiceNow documentation. There’s no ability to modify the popup view conditionally however.
https://docs.servicenow.com/administer/field_administration/task/t_FieldsDisplayed.html
Hi Mark,
Is it possible to hide Advanced view from ITIL users? If yes, please be kind to help me with the steps.
There are ways to do this. This community post shows a couple of solutions.
https://community.servicenow.com/thread/178345
Hi Mark,
I’m using switchView onLoad to set the form view based on a field on the form but when i return to the list view for the table it is retaining the form view. Is there a way to revert to default when leaving the form or should i just use a view rule instead?
Dave
Hi Mark
I can’t seem to get your solution to work. I have 2 views on Problem Task and the view is retained when clicking on the parent reference field and return to the Problem. This in turn causes the view to be retained when creating the next problem task. Your solution seemed ideal to remove the view from Problem. I’ve added debugging into your code so I can see that I’ve matched the view names and it has cleared sysparm_view, but nothing happens on the form. What am I missing?
Thanks
Tony
An update on my previous comment. I was running the script on the problem table not the problem_task table. Once I switched to the right table it worked like a charm. Whoops.