Image Removed

Core Tables
The ServiceNow platform consists of two core tables Task (task) and Configuration Item (cmdb_ci).
A table can "extend" another table. A table that extends another table is called a child class, and the table it extends is the parent class. If a table is extended, but itself is not an extended table, it is then called a base class. Therefore, the Task table and the Configuration Item table are examples of base classes.
Modifications made to a base table will be applied to all child tables. Be sure that the changes being made should apply to all of the child tables. Adding fields is a low-impact change, because the field can be hidden on tables that do not need it; however, deleting fields may cause unwanted data loss if the field is being used across tables.
Task Fields
The task table has many important fields that are used across extended tables, see the ServiceNow Wiki for specifics on each. A few key fields are:
Active (active): Boolean – Determines whether the task has work to be done. Useful for filtering out tasks which are complete. The business rule task reopener sets the active flag to True if the state (see state below) is changed from Closed Skipped, Closed Incomplete, or Closed Complete to any other state.
State (state): Choice integer – A list of selections for the status of the task: Pending, Open, Work in Progress, Closed Complete, Closed Incomplete, and Closed Skipped. It is critical to NEVER modify the number value for these choices. The system makes use of them in many places, and this could cause many issues. To add values specific to process or table, use the TaskStateUtil overrides, see ServiceNow Wiki.
Number (number): String – A unique identifying number for the task, used as the display value of the task. This number is human friendly and different than the sys_id. Numbers are generated automatically when the task is created. To modify the behavior of numbers modify the Number Maintenance for the table in question.

Core Data
Core data refers to a set of data required by the system in order for it to function properly. Core data could be fed into ServiceNow via an external system integration, or ServiceNow may serve as the system of record for the data. Some examples of core data are as follows (User demographic data, User authentication, Groups, Group membership, Departments, Locations, Location hierarchy, Companies, Symptoms, Schedules, Configuration Items, Assets, and Cost Centers).
Groups and Roles
Group: A group is a collection of users who share a common purpose such as approving change requests, resolving certain incidents, etc. Users can belong to one or more groups.
Roles: A role is a persona or ability that is assigned to a group such as report_writer which gives the user an ability to write reports. Each role grants certain permission to a certain parts of the system. A single group can have many roles. Additionally, a role can consist of many other roles. When the parent role is given, all the child roles are inherited along with a parent.
ServiceNow Roles must always and only be granted to groups. Users are then added to groups and inherit roles.
Integrations
Integrations that feed Core Data into the system must set a "Source" field. Out of box the Task Table (task) contains two fields, correlation_id and correlation_display. The Configuration Item (cmdb_ci) table contains a similar field discovery_source.

...

• Be consistent with naming conventions - Script Includes and other classes use upper camel case (i.e. InboundActionInclude) where methods and variables use lower camel case (i.e. fixDuplicateImages).
• Name your variables/functions wisely - you should be able to read back your code and by looking at the variable names know what is going on (name your GlideRecord variables something like userRec instead of gr to denote that you are working with a user record, etc). Never use gr, gr1, gr2, etc
• When possible use uniquely named Functions or Self executing Anonymous functions - Business rules are evaluated in the global scope, if two rules contain the same function call, they could interfere.
• Wrap your scripts - In workflow run scripts and other areas, wrap your script in a function and call the function. This will prevent variables that exist in the system at the time of your function call from interacting with variables defined inside your function.
• Be consistent with formatting - There is nothing worse than code that is difficult to read because it is poorly formatted.
• Try to not use literals - Always try to store literal values in a custom system property or in another table instead of defining them in your code (i.e. hard coding an email address, category value, sys_id, etc). When you MUST use literals, define them as a variable (all caps) at the top of your code (i.e. var EMAIL_ADDRESS = user@mycompany.com). This makes it much easier to find all occurrences of literals when it comes time to update or debug.
• Comment - Describe what the code is doing and why it is being done one way instead of another so if someone has to debug or fix your code down the road they understand what is going on.
• Use toString() when pushing into arrays - When pushing items from a GlideRecord into an array remember to use toString() or + '' to force the value rather than a pointer. (i.e. array.push(userRec.name.toString()); or userRec.name +''.

Server Scripting Best Practices

• Avoid global business rules. Business Rules marked as running on Global are loaded and initialized at the beginning of EVERY interaction between a user and the platform since it ignores the condition field. Utilize script includes to define code that will be used repeatedly when possible, but if a global business rule is needed ALWAYS wrap the script in a function.
• Know when to run business rules.
  • Display business rules run just before the form is loaded. These are typically used for passing g_scratchpad information to client scripts. Display business rules are useful for sending information from the server to the client.
  • Before business rules run after the changes are submitted but before they are committed to the database. These are generally used to manipulate the current record, for example, when calculating a Risk field based on the Importance and Priority fields.
  • After and async business rules run in parallel. Both are used mainly to perform operations on other related records that are affected by the changes to the current record. The difference is that after business rules run immediately while async rules run in the background, allowing the user to carry on without having to wait for the business rule to complete.
• Timing of business rules is critical. To prevent upgrade issues, avoid modifying the base system business rules, and make sure the business rules run at the appropriate time.
• Whenever possible leverage the power of the database instead of using JavaScript. GlideRecords are other APIs are optimized to perform heavy lifting.(i.e. userRec.setLimit(1), rather than only using userRec.hasNext())
• Don't create single use script includes. Whenever possible try to bundle similar script include functionality into bundles. Try to make methods reusable and flexible so it can be used in many places. For example a script include named serviceCatalogAJAX could include all AJAX types of methods for the service catalog. This allows for easier maintenance.
• Don't use current.update() in Business Rules. When the value of a certain field on a table needs to be set when a record is inserted or updated, set that in a before business rule since this runs before any database activity. Using current.update() can cause recursion and a potential loop in the system.
• Use the JavaScript eval Function with CAUTION. Improper use of eval can cause vulnerabilities and injection of malicious code. Consider using a sandboxed or protected alternative. (i.e. GlideEvaluator.evaluateString("gs.log('Hello CPP, 'CPP');");
• Always use the 'source' argument when using gs.log(). The log function accepts two parameters (message, and source), whenever logging to the system use the source parameter. This prevents the standard Script Log from being overloaded with scripts. In addition this helps tracing in case of debugging and disabling log statements.
• Remember to remove your debugging statements prior to migrating business rules to production. Logging produces un-needed lines in the system log and volume could impact system performance.
• Use an Async business rule in lieu of an After rule whenever possible so that control is returned to the end-user as quickly as possible.( gs.log('Hello CPP, 'CPP') The user's transaction will "clock" while Before and After business rules process and can influence the end-user's perception of performance.
• Remove, comment out, or wrap calls to gs.log in a debug property so they can be disabled in production environments as it creates extra load on the database when inserting those log records.
• Keep business rules small and specific so that they are easy to use and debug.

...

• 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.

Knowledge Articles

• Knowledge articles must contain "meta" or keywords, since the system indexes the article bases on this field.
• The Text index property weight will be adjusted per field to properly meet the client's requirements.

Catalog Items

...

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.

...

• Use caution when using "Run business rules" on a transform map, depending on the data set size, this could cause the instance to perform poorly.
  • Consider using an onComplete transform script instead of business rules.
  • If you must use business rules, consider adding gs.isInteractive() to the condition field of specific business rules to prevent them from running during an import.
• Transform maps must always coalesce on indexed fields.When using JDBC imports, use the "Use last run datetime" option in the import set data source.
• When importing large sets of data ensure the "Import Set Deleter" job is running. The frequency may need to be adjusted.

...

• Service Accounts should have "web service" access only set on the User record.
• Follow naming convention: system s_application where application is the name of the system using this account to connect via web services, etc.
• Follow naming convention: system s_midserver where midserver is the name of the MID server.

...

• 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*

Functional Requirements – Duties of the Developer

If you are listed as the 'Tech' for any functional requirement, you are responsible to maintain that functional requirement record including:
Image Removed

...

1. Configuration – Minor tweaking (field creation/movement, etc.) needed to fulfill the requirement
2. Customization – A code or script is required in order to fulfill the requirement
3. Data – The requirement relies on a subset of data for fulfillment
4. Integration – Integration to another system is needed to fulfill the requirement
5. Notification – A notification is needed to fulfill the requirement
6. OOB – Out of box functionality covers the requirement and no further action is needed
7. Reporting – Report, dashboard, or gauge creation needed to fulfill the requirement
8. Security – ACL or role level restriction needed to fulfill requirement

...

Additional Resources

ServiceNow Wiki - http://wiki.servicenow.com/
ServiceNow Community - http://community.servicenow.com/
ServiceNow Developers - https://developer.servicenow.com/
HI Server (ServiceNow's support tool) - https://hi.ServiceNow.com/
ServiceNow Advanced User Group (SNAUG) - http://snaug.com/
ServiceNow Webinars - http://www.servicenow.com/video-webinars.do