ServiceNow Developement Guidelines & Technical Best Practices

 Update Set

Best Practice	Compliance(Yes/No/NA)
Update set names as per below guidelines (<Developer Name>_ <Story #> _ <Description>_<Version>) Example : David_STRY0001_IncidentImplementation_V1.0.
Each update set to have maximum of 100 updates.
Specify Update set order
Never Delete Updates, Instead Move Them to Default
Export the update set xml and keep in central repository.
Use update source to transfer the update set to destination instance.
Promote Changes after working hours or on Weekends

 

CMDB Best Practice :

Best Practice	Compliance(Yes/No/NA)
CI Name must be unique and that doesn’t change over time.CI name should be unique so it can be differentiated from other CI’s and it must not change so the CI can be tracked over time.
It is bad idea to use an IP or MAC address as CI name since this may change easily over time.
CI Must have relationship
CI’s and Assets are related but they are not same.
Don’t create CI’s for things you cant configure or monitor. CMDB is there to help you deliver digital services it isn’t a data centre.

 

 

End User form related best practices

 

Best Practice	Compliance(Yes/No/NA)
All fields in end user related forms have to be prefilled with existing and relevant information. The rule is that the end user should not enter information which is available in ServiceNow tables.

 

Domain

Best Practice	Compliance(Yes/No/NA)
Peer review to randomly check if code is committed to right domain.
Any OOB code was modified. Avoid this.
Notification should be global domain unless it’s for a specific customer. In this case, the condition should be set appropriately.
Workflows must be in global domain. If this is Customer specific workflow then Company should be used in condition builder.
Groups should be created in global domain. Together with setup of roles necessary for a group, Visibility to particular customer domains should be specified (Visibility Domains related list on Group form).

 

Manual Activity

Best Practice	Compliance(Yes/No/NA)
Data import, like initial import of domains, Users, Configuration Items, Groups etc.
Domain records to be migrated to destination instance before everything else.
Referenced tables should be imported before rest of the tables.
System properties which are specific for the instance or can be different on other instances, like debug level of scripts, integrations related settings (soap endpoints etc.)/properties
Referenced tables should be imported before rest of the tables.

 

Logging

Best Practice	Compliance(Yes/No/NA)
Each logging entry should be easily assignable to responsible code (i.e. script name prefix)
„Non Error Loggings“ (debug messages) must be switched off or commented when a new functionality is completed, just to avoid unneeded log entries on target (non- development) instances
On CAT and PROD systems only error loggings are permitted. Other loggings have to be discussed with the system architects.
System performance Performance critical tasks like mass data loading must be coordinated with administration of the instance (Global Team on DEV)

 

Business Rules Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Prevent Recursive Business Rules(Do not use current.update() in a Business Rule script)
Enclose Code in Functions
Use Script Includes Instead of Global Business Rules
Use Conditions in Business Rules

 

 

Client Script Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Restrict List Editing - If UI Policies or Client    Scripts are used
Minimize Server Lookups Userg_scratchpad, Async GlideAjax & getReference
Use UI Policies Instead of Client Scripts
Avoid Global Client Scripts
Avoid DOM Manipulation
Enclose Code in Functions
Run Only Necessary Scripts - use appropriate 'if' conditions
Add the isLoading Check (onChange Scripts Only)
Add the newValue Check
Add the newValue != oldValue check
Bury the GlideAjax Call

 

Coding Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Make code Easy to Read.
Use Descriptive Variable and Function Names-Meaningful names for functions and variables better indicate readers the purpose of code.
Construct reusable functions-This improves the quality of code, saves you the trouble of searching through multiple blocks of similar code when problem arises and makes code easier to maintain.
Use variables to Store Function Results.
Use immediately Invoked Function Expressions-This is used to run the script in a single context such as a transform map script.
Avoid Complex GlideRecord Queries.
Do not Use Hard-Coded values in scripts,they can lead to unpredictable results and can be difficult to track down later.
Avoid Dot-Walking to the sys_id of a reference field.
Avoid Complex Queries on Large Data Sets.
Avoid Dynamic JEXL Expressions in an Evaluate.

 

Commenting Your Work

 

Best Practice	Compliance(Yes/No/NA)
Comment your code that will be useful to anyone who needs to update the script later.
Make Comments Helpful by clearly describing the purpose of functions and all inputs and outputs.
Add Descriptions to Records that will help to understand the contents of a record.

 

Exporting and Importing XML Files

 

Best Practice	Compliance(Yes/No/NA)
Exporting a Single Record is often useful.
Exporting Multiple Records.
Import Records as XML Data.

 

Update Sets Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Follow Update Source Requirements-Create only one update source record per instance source to avoid transfer errors.
Define naming Standards-This makes it easy to coordinate changes from multiple developers or when applying changes from one instance to another one.
Provide Helpful Descriptions.
Organize Update Sets-Create Update sets based on process,stream,or application.This allows changes to be promoted and tested within the same release or sprint with minimal conflict.
Merge Update Sets-This reduces the number of times you have to preview and commit update sets.
Clean Up Previously Merged Update Sets.
Remove Debugging Code.
Ensure Updates Are Instance Independent.

 

Debugging Tools Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Debugging can provide information to help you understand system processes.
Debug Log helps you avoid alternating between the record you are trying to debug and the log output.
Debug Business Rule displays messages that indicate which business rules are being run and when they are started.
Debug Security Rules places a debug icon to see if there are any messages for the associated element.
Stop Debugging disables all debugging processes.
Recommended way to debug server-side scripts is to use gs.print statements controlled by system properties.
Check the browser's console log for additional debugging information. These logs can help spped up development and troubleshooting processes by locating undefined objects.
Before closing update set or complete testing of the production instance,be sure to disable all server-side debugging to save log space in production.

 

Import Set Performance Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Avoid running business rules during a transform unless you want all insert and update business rules, notifications and workflows to run.
Avoid writing complicated scripts that use Glide Record queries. Use base system functionality whenever possible instead of writing custom scripts.
On import set tables with large amounts of data being processes, limit the number of transform maps to 1.
For a JDBC import, use the Use last run date time option in your import set Data Source. For a File type import, be sure that whatever is generating your files is only adding data that is new, or has been changed.
Coalesce on a unique field and a field that is already indexed.
Stagger your imports so they do not overlap.
Verify the Import Set Deleter job is running. If the import sets are not cleaned on a regular basis the table fills causing imports to stop.
Truncate the import table before importing with a new column.
Break a very large data set into multiple,smaller for faster results.

 

 

 

 

 

 

Logs and Queues Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Review queues and logs frequently throughout the development process to ensure correct operation. Waiting until development is complete makes diagnosis and correction more difficult.
Diagnose potential performance issues by reviewing the Slow SQL Statements.
Check the size of log files regularly. If a log file you have been checking suddenly increases in size, there may be excessive errors, debugging may be enabled, or a new plugin may have been activated.
View Log detail and search for messages which may indicate potential issues, determine the root cause of the issue, such as poorly performing script, and correct it.
Periodic review of the External Communication Channel can help determine if problems exist with the instance or MID Server.
Periodically review the events log to determine which events are taking longest to process.
Remove unused events this can improve overall system performance.

 

Patches Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Create Plan to Validate Critical Functionality.
Before patching production instances, patch and validate sub-production instances.

 

 

 

 

 

 

 

 

 

Web Service Integrations Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Client Connection Setting Recommendations should be taken care of to ensure acceptable performance.
It's recommended that whenever a SOAP Request is executed, that you evaluate if it is necessary to get an instant response back.
Enable compression of HTTP messages. This is the default behavior with the latest, robust SOAP libraries, but make sure to verify it.
Test new applications carefully.  1. Examine wire-level traffic for anomalies and to verify correct and efficient behavior.   2. Test with large datasets of the kind that will be encountered in production, rather than relatively tiny test data sets.
Use Version-Specific REST APIs.
After upgrading, pull new WSDLs using any client applications that access the instance through SOAP and rebuild the stubs. This action updates the client application to use the upgraded WSDL.

 

ODBC Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Perform SOAP Load Testing.
Avoid using joins as they can impact performance.
Use WHERE Clauses in Queries Efficiently.
Consistent Use of Time zones in Queries-It is important to ensure that both the client and users be set to the same time zone in order to avoid time lapses.
Avoid views that reference themselves. This can cause the queries to loop and create stack overflows.
Avoid Number Precision Errors.
Avoid Select Top N Statements. This may impact instance performance.
Avoid using the dateadd and datediff statements when the result cannot be transformed to a literal value in the where clause.
Establish a connection to the instance before performing any queries and reuse this connection for all of the queries.

 

System Performance Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Monitor Response Times to maintain good performance levels on the application server.
Remove unused inactivity monitors as they can produce large numbers of unanswered events can adversely impact the performance of the event processing engine.
Adjust the Auto-Complete Wait Time.
Check the SLA Trace level, it controls the number of messages sent to the system log.
Monitor the processing duration of Scheduled Jobs to keep track of system performance and to screen for issues.
Avoid modifying the default system User Preference named rowcount as it will slow down list viewing and has the potential to become a scalability and performance issue.
Configure the Browser to accept compressed data from an application server to speed the performance.

 

System Properties Best Practices

 

Best Practice	Compliance(Yes/No/NA)
Define a Naming Convention for System Properties. This makes it easier to filter lists of properties.
Create New Properties and then add related properties to categories.
Create Properties Page this makes it easy to access system properties.
Use Properties in Server-Side Scripts, properties make it easy to change the behaviour of the system.