...

• Avoid global client scripts. Global client scripts load on every page in the system causing delays and poor user experience. Leverage UI scripts and base table ([task], [cmdb_ci]) client scripts that can be inherited on child tables instead.
• Reduce the number of server lookups. Use client data as much as possible or build an object with a before display business rule, but when you MUST make a roundtrip call to the server utilize the g_form getReference method, GlideRecord, or GlideAjax when needed. ServiceNow recommends against using GlideRecord client side.
• Use g_scratchpad when leveraging data that is not on a form.
• Use UI polcies for date/time type conditions, instead of client scripts.
• Add conditions to client scripts. ServiceNow client script forms don't have a condition line, so all onLoad and onSubmit client scripts run every time. Add if statements in client scripts to verify code is only being run when needed.
• When using getReference(), always use a callback whenever possible. The getReference() method requires a server round trip and will halt processing, causing the end-user's browser to "hang" while they wait for the transaction to complete. Using a callback causes it to process asynchronously, so other activity/scripts will continue to execute until the reference is completed and the callback is invoked.  If you don't use a callback your script won't work on mobile or Service Portal.
• Avoid DOM manipulation in Client Scripts when possible. In general, when using DOM manipulation methods, you reference an element in the DOM by id or using a CSS selector. When referencing out-of-box DOM elements, there is a risk that the element ID or placement within the DOM could change thus causing the code to stop working and/or generate errors.
• When debugging use jslog() rather than console.log(), the platform locks this access to only administrators when the debugger is chosen from the UI. This eliminates the need to comment out debug lines for production instances.  jslog() doesn't work on Service Portal!

Workflow

• Check workflows back in periodically, never keep workflows checked out for extended periods of time.Always trigger Email notification events rather than hardcoding emails within the workflow.
• Always trigger Email notification events rather than hardcoding emails within the workflow.  This is mostly because notifications triggered in workflow can't be managed in notification preferences.
• Handle errors in automation first with retries and then with manual task creation.
• Make sure to handle the flow when catalog tasks are not closed complete.  Out of box a catalog task activity only has one condition 'always' which is almost 'always' not sufficient.

Catalog Items

• Catalog Items must have a name and short description specified, and they should never contain duplicate values. These values are used when searching the system.

...

• Leverage Notification scripts for redundant data entry. This allows for a single place to update/change data.
• Be careful with the ServiceNow WYSIWYG as it inserts breaks and extra markup.
• URLs in notifications must NEVER be hardcoded but utilize URI + URI_REF.
• Subjects will contain the Number triggering the notification.
• Reports can be attached to Notifications via mail script syntax.

...

• Do not delete update sets. If an update set is deleted, any updated records may be overwritten in the next update.
• Do not include the system_id field from the ldap_server_config record in an update set. An update set from a working configuration points to the wrong system_id node for the target instance and does not work.
• Do not back out or close the Default update set. This action causes damage to the system.
• Never change the update set field value (update_set) in a Customer Update record (sys_update_xml). If a customization is made in the wrong update set, take the following action:
  1. Switch to the desired update set.
  2. Modify the object (record) that was originally changed. You can make a trivial change, such as adding a field.
  3. Save the record.
  4. Back out the modification just performed, and then save the record again. This action ensures that the latest version of the object is included in the desired update set and prevents duplicate updates for the same object in a single update set.
     * Do not mark an update set as Complete until it is ready to migrate. Once an update set is complete, do not change it back to In progress. Instead, create another update set for the rest of the changes, and make sure to commit them together in the order that they were created. Naming conventions may help in this case (for example, Performance Enhancements and Performance Enhancements 2).

     * Do not manually merge updates into an update set. Always use the Merge Update Sets module. This tool compares duplicate files between update sets and selects the newest version.

• If a committed update set has a problem in the test instance, build the fix in another update set in the development instance. Commit this set to the test instance, and then make sure both sets are migrated to the production instance and committed in the order they were made.
• If Sets are merged, set completed update sets on the production instance to ignore. This state ensures the update set is not reapplied when cloning the instance.
• Keep a to-do list of manual changes and data loads that need to be completed after an update set is applied.
• Update sets cannot remove tables or change a column's data type if the change results in data loss. The target instance skips the update set and adds a log message if an incoming change would result in data loss. Perform these tasks manually on the target instance if they are crucial to the customization.

...

• Avoid GlideRecord queries in ACL Rules.
• Leverage Data Policy to enforce consistency. Data policies increase the security of UI policies by ensuring that data meets certain requirements regardless of whether the data comes from the UI form or another source, such as a web service, import set, or incoming mail. For example, use a data policy to ensure that incident records always have a short description and category even when the data comes from an integration. Data policies also prevent users from bypassing client-side policies.
• Limit the number of users with the Admin role. Limiting the number of users with the admin role is consistent with the principle of least privilege and helps ensure separation of duties.
• Create Multiple accounts for Administrators. Administrators should have both elevated privileges, and normal ITIL access. This maintains security and minimizes risk of accidental changes (particularly in production instances).
• Frequently Audit the role 'admin' to ensure only the proper people maintain this role. In addition, audit the 'CPP Consultant' group to maintain an up-to-date list of employees engaged in the project. 
• *https://hi.service-now.com/kb_view.do?sysparm_article=KB0536146*