Day 21: DDIS - Client Scripts with empty script field

in

Scan Check Type: Table Check [sys_script_client]

Code elements with empty script fields are useless.

Remove the Client Script or implement its logic.

This scan was developed using a table check with condition to identify any client script records with a hardcoded script ISEMPTY. This condition was hardcoded using an XML import to manually override the condition field, which doesn’t normally allow you to select ISEMPTY for a script field type. This rule is inspired by a QualityClouds check.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 21 scan_table_check_9bfbd80d2f7711107caa93acf699b616.xml

Day 20: DDIS - UI Policy Actions without field effects

in

Scan Check Type: Table Check [sys_ui_policy_action]

UI Policy Actions should contain at least a single action, such as mandatory, visible, read only, or clear the field value.

Update the UI Policy Action to have at least one action, or delete the record.

This scan was developed using a table check with condition to identify any UI Policy Action records with mandatory, visible, read only set to Leave alone, or Clear the field value is false. This rule is inspired by a QualityClouds check, but the core intention of the QC check is to check for conflicting mandatory and disabled/visible (since those should not be used at the same time). However there is already an existing Instance Troubleshooter check for that (Invalid UI policy configurations), so mine covers the other case for unconfigured records.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 20 scan_table_check_b06910892f7711107caa93acf699b654.xml

Day 19: DDIS - Application Menu Names are too long

in

Scan Check Type: Table Check [sys_app_application]

Long Application menu titles get truncated, as well as clutter the form UI, causing a bad user experience. Application menus should have shorter titles.

Reword, shorten and/or abbreviate the Application Menu title to be a smaller descriptive title for the application or module, and move the detailed name to the hint.

This scan was developed using a table check with scripted condition to identify any Application Menu records with a title longer than or equal to 30 characters. I don’t know that this rule is currently a part of any other sources, but it’s a rule I came up with as a user experience best practice.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 19 scan_table_check_c97690452f7711107caa93acf699b673.xml

Day 18: DDIS - UI Action names are too long

in

Scan Check Type: Table Check [sys_ui_action]

Long UI action names get truncated, as well as clutter the form UI, causing a bad user experience. UI Action should be short action verbs to describe an action.

Reword, shorten and/or abbreviate the UI action name to be a smaller descriptive name, and move the detailed action name to the hover tooltip.

This scan was developed using a table check with condition to identify any UI action records with a name value longer than or equal to 20 characters. This rule is inspired by a ServiceNow Health Scan check.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 18 scan_table_check_026fc88d2f3711107caa93acf699b6c1.xml

Day 17: DDIS - Transform Maps with "Run business rules" option enabled

in

Scan Check Type: Table Check [sys_transform_map]

Enabling the execution of business rules in transform maps may cause the transform to take longer than expected, or cause the instance to slow down.

Unless you absolutely need business rules to run during the transform, un-check the Run business rules checkbox on the Table Transform Map when transforming large amounts of data. Typically any business rules can be re-written within a transform map script, and better optimized for mass uploads as well.

This scan was developed using a table check with condition to identify any transform map records with an run business rules is true. This check is inspired by a QualityClouds rule.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 17 scan_table_check_d71458ec2fab11107caa93acf699b63a.xml

Day 16: DDIS - JDBC Data Sources with "Use last run datetime" option unchecked

in

Scan Check Type: Table Check [sys_data_source]

Repeatedly importing data that has not changed leads to many skipped rows and unnecessarily bounds system resources.

Ensure that each import is not importing all records every time by using the "Use Last Run Datetime" option. If you are running a JDBC import, use the last run datetime option in your import set Data Source. For a type of File import, be sure that whatever is generating your files is only adding data that is new, or has been changed.

This scan was developed using a table check with condition to identify any data source records of type JDBC with a use last run datetime is False. This rule is defined both in ServiceNow’s Health Scan and in QualityClouds checks.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 16 scan_table_check_bd93dcac2fab11107caa93acf699b6a0.xml

Day 15: DDIS - Client Scripts without function

in

Scan Check Type: Table Check [sys_script_client]

Client scripts without a function cause issues with variable scope. When code is not enclosed in a function, variables and other objects are available and shared to all other client-side scripts.

Ensure that all code is wrapped in a function.

This scan was developed using a table check with condition to identify any client script records that don’t contain the function. This check is inspired by QualityClouds check for the same, but it operates slightly differently from their check, which does closer to a startsWith operation. The problem is that there are multiple ways to define client script functions. It is best practice that all of the client script code is wrapped into a function, but that is somewhat harder to verify and check.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 15 scan_table_check_1a13146c2fab11107caa93acf699b69e.xml

Day 14: DDIS - Notifications without a category

in

Scan Check Type: Table Check [sysevent_email_action]

Users manage their subscriptions via the category breakdown. If no category is selected then users cannot properly manage the subscriptions for the notification.

Select a category for each notification and do not leave the field blank.

This scan was developed using a table check with condition to identify any notification records that are missing a category, or are placed in the Uncategorized section. This check is inspired by a ServiceNow HealthScan rule.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 14 scan_table_check_65e2479f2f1311107caa93acf699b64d.xml

Day 13: DDIS - Too many fields in a Form Section

in

Scan Check Type: Script Only Check

Too many fields on forms impact the service experience and leave users frustrated. Performance and ease of management is also impacted.

Try to reduce the complexity of the given form to fewer than 30 fields. Use views, or calculate fields automatically.

This scan was developed using a script only check with condition to identify any UI sections with more than 29 element records. This rule is inspired by a Quality Cloud check. I would like to eventually also devise a check to count total form fields, but it is a bit more complex since you would have to group UI elements under UI sections under views to get that number.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 13 scan_script_only_check_3dd9472f2f8b59107caa93acf699b6c5.xml

Day 12: DDIS - Synchronous AJAX call getReference in client scripts

in

Scan Check Type: Script Only Check

Code that uses synchronous AJAX feels very slow. It is detrimental to the user experience.

For data that can change during the user experience, replace g_form.getReference with GlideAjax, a callback function, and a custom function in a Script Include that returns only the needed information. For data that remains the same after the form loads and can be determined before the form loads, replace g_form.getReference with a Display Business Rule and g_scratchpad.

This scan was developed using a script only check with conditions to identify custom client scripts that use the getReference function. There is a very similar script that is in the Example Instance Checks GitLab project, “Using Synchronous AJAX calls in client script”. However that check only gets for getXMLWait in types of onLoad or onChange, which doesn’t cover the full range of functions like getReference. This check is also found in the QualityClouds product.

Download and import the XML to check it out in your instance! At the end of the month I will be bundling all the checks together.

Day 12 scan_script_only_check_f9434b272f8b59107caa93acf699b655.xml