Day 31: DDIS Final and Lessons Learned

Diving into ServiceNow’s instance scan has definitely grown my thinking. This has been a fun project overall. For the finale I am bundling several extra checks I have developed, as well as some lessons learned and thoughts about Instance Scan.

Lessons Learned

1. It’s hard to check for properties if the exist and if they have a certain value within the same check. Might need to create a custom filter script to perform this check in a repeatable fashion. The other issue is - how can you create and link a finding if there is no relevant matching record? Would be nice to have a sort of best practice for how to handle this situation.

2. Script only checks have a major weakness where they don’t scale past 10k elements. GlideRecord just kind of eventually shuts down and doesn’t loop for that many elements. There should be some built in checks for scalability to check for those large tables, that if there are more than 10k records to break it through in 10k chunks. GlideAggregate doesn’t scale past 100k elements typically either, but there shouldn’t be many config tables with more thank 100k records…

3. Denoting multiple different kinds of client scripts vs server scripts. For example, with client scripts, we should check client scripts/catalog client scripts, portal client script, UI pages, UI macros, and more. Server side scripts should also check flow scripts actions, workflow scripts, etc. It would be very nice if there was an added capability for Instance Scan to toggle client/server side checks.

4. Similar to number 3, is that Script lint checks only apply to script fields, and not special places like Flow scripts which are not stored in a script field. Hopefully ServiceNow can fix this in a later update.

5. Don’t do an Insert and Stay on a Read Only OOB instance check… Because then the copy is also read only - and is especially hard to delete. I did find a workaround, where you to edit an XML, and manually trick a delete operation when loading an update set to delete it though.

Download Instance Scan Bundle Update Set

DecemberDailyInstanceScan v1 sys_remote_update_set_8ca37b9a2fc425107caa93acf699b665.xml

Includes all 37 developed checks:

• 11 Managability

• 11 Performance

• 5 Security

• 10 User Experience

Day 30: DDIS - Workflows with Notification Activities

Scan Check Type: Script Only Check

The use of notification activities introduces unnecessary rigidity in your workflow management and maintenance. Notifications used within workflows cannot have templates, and subscriptions cannot be managed consistently.

De-couple workflows from notifications by raising events from your workflows, and triggering nofifications from these events.

This scan was developed using a script only check with condition to identify any workflow activity records with an definition as Notification, and related workflow version is active. This rule is inspired by a QualityClouds check, and is also very similar to the check “avoid workflows with too many activities”.

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 30 scan_script_only_check_1a8a63da2fc425107caa93acf699b6ab.xml

Day 29: DDIS - Notification configured without a template

Scan Check Type: Table Check [sys_email_action]

Notifications should have a standardized template selected on them which has the relevant content, style and branding elements to have a consistent user experience.

Select an existing template which has the relevant branding, or create one to be used.

This scan was developed using a table check with condition to identify any Notification records which are configured without using an email template record. I don’t know that this rule is currently a part of any other sources, it is a notification management and user experience (branding) best practice 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 29 scan_table_check_765439d52fb311107caa93acf699b6cb.xml

Day 28: DDIS - GlideRecord API usage in REST Web Service

Scan Check Type: Table Check [sys_ws_operation]

Scripted REST APIs should use the GlideRecordSecure API. This API ensures that access controls defined on the underlying data are applied for the requesting user.

Ensure that all REST API Resources use GlideRecordSecure methods, instead of GlideRecord methods.

This scan was developed using a table check with condition to identify any Scripted REST Resource records which contain a reference the a GlideRecord. 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 28 scan_table_check_a013bd152fb311107caa93acf699b6a2.xml

Day 27: DDIS - Debugging properties shouldn't be left enabled

Scan Check Type: Table Check [sys_properties]

Having debugging enabled unnecessarily can cause performance issues and possibly leak data.

If not actively debugging, disable all debug system properties.

This scan was developed using a table check with condition to identify any Property records with a value set to debug. This rule is both inspired by QualityClouds check, and is very similar to an Instance Troubleshooter check, which also checks for some specific debug properties. This one fills a slightly different niche for checking all properties set with a value of ‘debug’.

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 27 scan_table_check_0900b1d12fb311107caa93acf699b641.xml

Day 26: DDIS - Client UI Actions using GlideRecord

Scan Check Type: Table Check [sys_ui_action]

The client side GlideRecord object is often inefficient, because it returns lots of unnecessary data. GlideRecord and g_form.getReference are both involved.

Use client data as much as possible to eliminate the need for time-consuming server lookups. The top ways to get information from the server are g_scratchpad, and asynchronous GlideAjax lookup.

This scan was developed using a table check with condition to identify any UI action records that are marked client side, active, and contain GlideRecord or GetReference. 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 26 scan_table_check_da7e6ddd2f7311107caa93acf699b66c.xml

Day 25: DDIS - Avoid use of client side alert

Scan Check Type: Table Check [sys_script_client]

Usage of alerts, is an industry design and user experience bad practice. Alerts frustrate users over additional clicks, and interrupt the flow of work.

Remove the usage of alert, and use functions like g_form.addInfoMessage instead.

This scan was developed using a table check with condition to identify any client script records with a script containing alert(. I don’t know that this rule is currently a part of any other sources, but I know it is an industry best practice to not use alert statements in Javascript anymore, and is publicly frowned upon. I also considered adding conditions for confirm and prompt, but I believe for some types of actions like for deleting records/data, it is important to have an additional UI confirmation (even through it could be handled properly with modal… but I digress).

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 25 scan_table_check_795829152f7311107caa93acf699b6e9.xml

Day 24: DDIS - Avoid workflows with too many activities

Scan Check Type: Script Only Check

Complex workflows are hard to manage and debug.

Using sub-flows can drastically reduce complexity and allow you to create more modular workflows. Consider dropping below 30 activities.

This scan was developed using a script only check which loops through wf_activity instances groups by workflow version (so we know how many activities are in a workflow), and then if the count is 50 or higher the check creates a finding. This rule is inspired by a QualityClouds live check. I know most development should be moving to flow designer, so workflow rules may not be as relevant, but from a maintaining legacy code perspective, I think it is still good to have the context.

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 24 scan_script_only_check_04afd9912f7311107caa93acf699b6ea.xml

Day 23: DDIS - Synchronous Business Rules making SOAP or REST calls

Scan Check Type: Table Check [sys_script]

Making a call to an external system from a synchronous Business Rule may result in poor user experience.

Use an asynchronous Business Rule instead. Consider using Integration Hub.

This scan was developed using a table check with condition to identify any Business Rule records that are not async, and contain and instance of restmessage, soapmessage, GlideInternalSoapClient, SOAPRequest, or GlideHTTPRequest. This rule is inspired from the QualityClouds check - but I believe my rule checks for a more verbose list of APIs than the QC 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 23 scan_table_check_b4f699192f3311107caa93acf699b644.xml

Day 22: DDIS - Unused Catalog Items

Scan Check Type: Script Only Check

The Service Catalog should be consistently maintained and checked for any items that are not being used. This provides a top notch user experience by removing any excess clutter in the Service Catalog.

Review the catalog item, consider combining it with another catalog item, or retiring it altogether if it is no longer needed.

This custom script only scan was developed to query the active catalog items, loop through them, and check for how many catalog items were submitted from each. If there were less than 5 requested item submissions for that catalog then it creates a finding for that record. This is a custom rule that I developed, that I am not aware of being defined in any other rulesets. Note: This rule will trigger off a number of the demo data catalog items that are generated by default in an instance.

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 22 scan_script_only_check_95dd90cd2f7711107caa93acf699b68b.xml