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!

function onLoad() {
//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){}
}

The post Overriding ServiceNow Form View Inheritance appeared first on ServiceNow Guru.

Form – ‘sys_ui_form’:

Container for multiple form sections. A form section only exists if a table has a view that includes multiple form sections (sections). Each form record must be associated with a corresponding view record (even if the view is the default view). It is possible to have multiple form records for a particular table, each associated with a different view and sections.

–Navigation:

System UI -> Forms (or type ‘sys_ui_form.list’ in your left nav filter)

–Usage:

Forms should only be created by personalizing a form and creating a second form section for a view. The only reason to modify a form record directly would be to change the view that the form is associated with. Form records can be useful for navigation purposes when you want to see what form sections are part of a given multi-section form. The ‘Form Sections’ related list on the ‘Forms’ default view is also the best place to change the ordering of form sections on a given form.

Form Section (Section) – ‘sys_ui_section’:

This table is called ‘Form Section’, but it might be clearer to think of it just as ‘Section’. A section is collection of form section elements (fields, splits, annotations, and formatters) displayed on a form. Each section record must be associated with a corresponding view record (even if the view is the default view).

–Navigation:

System UI -> Forms (or type ‘sys_ui_section.list’ in your left nav filter)

–Usage:

Sections should only be created through the ‘Personalize Form’ UI. You may need to access these records directly if you want to see what elements are part of a particular form section or if you want to see if the form section is part of a multi-section form. You can also change the view a form section is related to or the caption for a section from the form section record. Section records are really the one place where forms, sections, and views are all linked together. As such, they are usually my starting point for navigation when I’m trying to modify something form-related that can’t be changed through the ‘Personalize Form’ UI.

Form-Section (m2m relationship table) – ‘sys_ui_form_section’:

Probably the most confusing of the bunch until you learn what it is. Contrary to what the label leads you to believe, this is not a form section at all! The ‘Form Section’ table is just a many-to-many relationship table that links forms and form sections (sections) together. This link is only created when you create a multi-section form.

–Navigation:

Type ‘sys_ui_form_section.list’ in your left nav filter (or view the ‘Form Sections’ related list on any Form or Section record)

–Usage:

If you’ve ever had a form section “disappear” on a multi-section form then this was probably your problem. The fix for those issues is typically just to create a new relationship record between the form and section in this table. You can also modify the ordering of form sections on a multi-section form by modifying the ‘Position’ field on these records.

The out-of-box Change Request form for the default view shows how all of these elements link together.

View – ‘sys_ui_view’:

Container for forms, form sections, lists, and related lists (all of which can come from various tables). A single view name can be used across many tables. For example, the ‘ess’ (Self-service) view is used by form sections on the Incident, User, and Request tables (among others) out of box.

–Navigation:

System UI -> Views (or type ‘sys_ui_view.list’ in your left nav filter)

–Usage:

Views should always be created through the ‘Personalize Form’ or ‘Personalize List’ UI. The only reason you would need to modify a view record is if you want to change the name of the view. Since views can apply to multiple tables, forms, lists, and related lists there’s a lot of information contained underneath a view record typically. It can be useful as a reference to see how all of the pieces fit together though. One thing to keep in mind when working with view records or references is that the majority of the forms and form sections in the system relate to the ‘Default’ view.

The post What you may not know about Forms, Form Sections, and Views appeared first on ServiceNow Guru.

—View Rules
—Restricting Form Views by Role

Neither of these methods work if you need to change the view of a form from a client script or a UI action. In order to do that, you can call the ‘switchView’ function as follows…

switchView(type,table,view);

The table and view parameters should be self explanatory. The ‘type’ parameter is either ‘list’ (to redirect to a list view) or ‘section’ (to change to a form view). Here’s an example client script that shows how you could use ‘switchView’ to change the incident form view to ‘ess’ if the ‘Category’ field changed to a value of ‘hardware’.

function onChange(control, oldValue, newValue, isLoading) {
   //If the page isn't loading
   if(!isLoading){
      //If the new value isn't blank
      if(newValue != ''){
         //Change to the 'ess' view if the Category is 'Hardware'
         if(newValue == 'hardware'){
            switchView('section','incident','ess');
         }
      }
   }
}

The post Change Form View Client Script appeared first on ServiceNow Guru.

But what if you would rather use the standard ‘ess’ view that is similar to the rest of the forms in the system? Something like this…?

While this isn’t a typical modification, this article shows how you could accomplish it.

1Navigate to the ‘Navigation Handlers’ table by using the following URL (‘https://your-instance-name/sys_navigator_list.do’) or by typing ‘sys_navigator.list’ in the left navigation search bar.

2Open the ‘sc_request’ record and change the ‘Table’ field value to ‘–None–‘. This effectively disables the navigation handler that overrides the ‘ess’ view for the ‘sc_request’ table.

Next, you need to force the standard ‘ess’ view when a user sees the request record immediately after submitting a request.

3Open the ‘com.glideapp.servicecatalog_checkout_view’ (‘com_glideapp.servicecatalog_checkout_view_v2’ for newer instances) UI page under ‘System UI -> UI pages’ and change the name to ‘com.glideapp.servicecatalog_checkout_view-OLD’ (‘com_glideapp.servicecatalog_checkout_view_v2-OLD’ for newer instances)

4Create a new UI page with the following settings…

<!--?xml version='1.0' encoding='utf-8' ?-->


var item_id = '${sysparm_sys_id}';
var item_table = 'sc_request';var sc_req_item = new GlideRecordSecure('sc_req_item');
sc_req_item.addQuery('request', '${sysparm_sys_id}');
sc_req_item.query();
if(sc_req_item.getRowCount() == 1){
sc_req_item.next();
item_table = 'sc_req_item';
item_id = sc_req_item.sys_id;
}

<script language='javascript'>
        addLoadEvent(overrideView);
        function overrideView() {    
            var url = '$[item_table]' + '.do?sys_id=' + '$[item_id]' + '$[AMP]sysparm_view=ess';
            window.location = url;
        }  
    </script>

5Verify the security for all of the elements and related lists on the new form. Since this view is not designed for use by ‘ess’ users out-of-box, you’ll need to make sure that the security on the request and request item tables meets the needs of your organization.

Overriding the Request Item (sc_req_item) ess viewThe default behavior for users with no role is to force the ‘ess’ view for the Request Item table. If you find it necessary to override the ess view for the Request Item table you can modify or disable the ‘Catalog Scripts’ AJAX Script record. You can find this record by navigating to ‘System Definition -> AJAX Scripts’ if that module is active in your instance or you can enter ‘sys_script_ajax.list’ in your left navigation filter to navigate directly to the list without a module.

The post Overriding the ess Checkout View for Catalog Requests appeared first on ServiceNow Guru.