Few Essential ServiceNow Best Practices for Developers

[MURALIR20469232]

Hello community!

As developers, focusing on how we write scripts is crucial for performance, ease of debugging, and scalability. Here are a few core best practices from technical documentation that will assist us in writing cleaner, smarter, and more reliable code.

1. Business Rule (BR) Technical Best Practices

The timing and structure of your Business Rules are critical for performance:

• Know When to Run the Rule:
• display: Use to allow client-side scripts to access server-side data.
• before: Use to update information on the current object. Changes are automatically saved when all before BRs finish.
• after: Use to update information on related objects that need to be displayed immediately (e.g., GlideRecord queries).
• async: Use for updates on related objects that do not need to be displayed immediately, such as calculating metrics and SLAs.
• Use Conditions: Since BRs are evaluated whenever an insert, update, delete, or query occurs, always use conditions. Conditions are evaluated first, and they make debugging easier.
• Prevent Recursion: Do not use current.update() in a BR script. This method triggers BRs on the same table, potentially causing the rule to call itself repeatedly, leading to system performance issues.
• If you absolutely must prevent other BRs or related functions from running during a database access, use current.setWorkFlow(false).
• Keep Code in Functions: Ensure your code is enclosed in a function (advanced BRs do this by default). This prevents variables and objects from being exposed globally, which can lead to unexpected, difficult-to-troubleshoot consequences.
• Use Script Includes over Global BRs: Global Business Rules load on every system page, regardless of whether they are needed. Script Includes only load when called, making them the preferred, more efficient method.

2. General Scripting and Code Quality

Focus on readability and efficiency in your code:

• Code Readability: Comment your code, use white space, and write simple statements (JSON is straightforward and easy to understand).
• Reusable Functions: Construct reusable functions, ideally in a Script Include, instead of rewriting the same logic multiple times.
• Variables and Naming:
• Use descriptive variable and function names.
• Store function results in a descriptive variable instead of repeatedly calling the same function.
• Verify that variables and fields have a value before using them to avoid unpredictable results.
• Practice returning some type of value from functions to inform the calling code about execution status.
• Database Interaction:
• Avoid complex addQuery() statements; use addEncodedQuery() instead.
• Use GlideAggregate for simple record counting, as it is designed for mathematical queries, instead of using GlideRecord.
• Leverage the database’s power: use setLimit() if only a certain number of records are needed, rather than retrieving all records with a simple query().
• Avoid Pitfalls:
• Do not use hard-coded values in scripts. Use references or retrieve values using gs.getProperty().
• Avoid dot-walking to the sys_id of a reference field, as this triggers an additional database query, causing performance issues.
• Use getDisplayValue() effectively instead of relying on explicit field names for display values.
• Code in stages and test frequently. Try out new ideas in a Sandbox instance to avoid cluttering your development update sets.

3. Debugging Technical Best Practices

Debugging best practices are classified into Server-Side vs. Client-Side.

• Pre-Debugging: To remediate issues, the tester should provide the record worked on, the user ID, steps to reproduce, the expected result, and the actual result.
• Server-Side Debugging:
• Logging: The recommended method is to use gs.debug() statements controlled by system properties, allowing for independent debugging of Script Includes. Use gs.debug(), gs.info(), gs.warn(), and gs.error(), as these are available in both scoped applications and global scope.
• Tools: Use Debug Log to display logging statements and server error messages. Use Debug Business Rule to track which BRs are running, finishing, or being skipped (and why). Use Debug Security Rules to verify read and write access controlled by ACLs.
• Clean Up: Avoid using gs.log(), gs.print(), gs.addInfoMessage(), or gs.addErrorMessage() for primary debugging. Crucially, before closing out an update set, disable all server-side debugging by activating the Stop Debugging module (System Security) or setting debug system properties to false to save log space.
• Client-Side Debugging:
• Activate the JavaScript Log and Field Watcher (via the settings icon).
• Use jslog() statements in client scripts and UI policy scripts. Unlike server-side statements, jslog() statements do not consume disk space and can be safely left enabled, even in production.
• Avoid using alert() statements.

4. Update Set and Data Migration

A well-defined migration process is essential:

• Update Set Application Order: Always create an ordered list detailing how grouped update sets should be applied. For example, ensure the update set creating a table is committed before the update set modifying that table's layout.
• Additional Data Migration: The update set often does not capture data records (e.g., approval lookups). The migration procedure must include instructions and location details for manually exporting and importing this data using XML files.
• XML Data Transfer:
• This procedure often requires the admin role. Importing XML requires elevating privileges to security_admin.
• Exporting: You can export single records (e.g., a user, CI, or incident for diagnostics) or multiple records from a list view.
• Relations are Key: When exporting a record (e.g., a User), related records (such as groups or roles) are not exported. Since business rules do not run during an XML import, you must separately export related tables (like User Role: sys_user_has_role and Group Member: sys_user_grmember) if those relations are necessary.

By adhering to these practices, we can significantly improve the quality and maintainability of our ServiceNow implementations. Think of these best practices as a meticulously organized toolbox: knowing the exact purpose and time to use a before Business Rule or a gs.debug() statement saves time, reduces breakage, and ensures the whole system runs smoothly.

*************************************************************************************************************

If my post is useful, please indicate its helpfulness by selecting " Helpful." This action benefits both the community and me.

If you like to share any information, please comment in this post so that it will be useful for our community.

Additionally, if you feel that any corrections are necessary in the content, please provide your feedback so that I can make the updates.

Regards

Murali.K.V.R