Quick Wins for a Healthier ServiceNow Instance

[Swapna Abburi]

As part of your regular development and configuration practices in the ServiceNow platform, there are several simple quick fixes you can implement to enhance performance, manageability, and overall instance health. These small but effective actions can make a difference, especially while you're working on analyze complex or legacy issues in the background.

Quick Fix #1: Minimize Logging in Production

During development in sub-production environments, it's common to leave gs.log() statements for debugging purposes. However, these often get promoted to production without cleanup.

Excessive logging in production can clutter system logs and negatively impact performance, especially when these logs are triggered frequently.

To address this Comment out or remove unnecessary log lines.

• Identify scripts with active log statements in existing scripts; these could be in Script Includes, Business Rules, UI Actions, Client Scripts, Transform Scripts, etc.
• Use the Performance category findings in the Impact site to locate scripts contributing to log volume.

Quick Fix #2: Clean Up Inactive Catalog Item Dependencies

When legacy or outdated catalog items are deactivated, it's common to overlook the associated configurations such as Catalog Client Scripts and UI Policies—which remain active in the system. If these scripts were not built following best practices, they may impact your ServiceNow Health Scan results.

As a quick win:

• Identify catalog items that are no longer active.
• Review and deactivate any related client scripts and UI policies that are no longer needed.

Quick Fix #3: Configure When Related Lists Load on a Form

By default, ServiceNow does not specify when related lists should load on a form, which can lead to inconsistent performance especially on forms with many related lists. A simple yet effective optimization is to explicitly configure the related list loading behavior using a system preference.

You can set a system-wide default by creating a record in the "sys_user_preference" table with the following details:

• Name: glide.ui.related_list_timing
• System: true
• Value:
  • "default" – Loads with the form
  • "deferred" – Loads after the form
  • "ondemand" – Loads only when the user expands the related list

Recommended setting: Use "deferred" to load related lists after the form loads, which improves initial form load time without sacrificing usability. Users can still override this preference individually if needed, but setting a thoughtful default helps improve performance across the board.

Quick Fix #4: Categorize Custom Notifications Properly

Custom notifications are often created during development but left uncategorized, making them harder to manage and track over time. 

• Review records in the sysevent_email_action table (Email Notifications).
• Identify notifications where the Category field is "empty" or set to "Uncategorized".
• Update each with the appropriate category, such as IT Service Management, Assessment, SLA or any other relevant functional area.

Properly categorizing notifications contributes positively to the Manageability factor of health score.

Quick Fix #5: Avoid Publishing Reports Publicly

In ServiceNow, reports should not be published publicly unless absolutely necessary. If you want to share a report with all authenticated users, the correct approach is to set the sharing option to "Everyone" without publishing it.

• Query the sys_report table to find reports where:
  • IsPublished= true
  • Roles = public
  • Exclude reports of type "list", as they are typically not covered in the finding definition as ACLs are always applied.
• As a one-time fix, "remove the public" role and set "Is Published" to false for these reports.

Other Quick Wins with Minimal Analysis

In addition to the above, here are few other remediations you can implement with just a bit of analysis. These help improve various health scan factors such as performance, manageability and user experience:

1. Hardcoded Instance URLs in Scripts
   Instead of hard coding instance URLs, consider using gs.getProperty('glide.servlet.uri') or  use relative paths such as /incident.do
   

2. Duplicate Update Set Names
   Review and rename update sets with duplicate names.

3. Duplicate Script Includes
   Identify and consolidate duplicate Script Includes to reduce redundancy and potential conflicts.

4. Debug Properties Enabled in Production
   Disable debug properties in production to enhance performance.

5. Workflows Checked Out for a Long Time
   Review workflows that have been checked out for extended periods. Either publish or revert them to avoid blocking updates and ensure consistency.

6. Same Field Appearing Twice on a Form
   Audit form layouts to ensure no field is duplicated, which can confuse users and clutter the UI.

7. GlideRecord or GlideAggregate in Read ACL Scripts
   Avoid using heavy database operations like GlideRecord or GlideAggregate in ACL scripts, especially Read ACLs, as they can degrade performance.