ServiceNow @ NC State: Developer’s Guide

Table of Contents

Introduction

About Key Words

Acronyms

Contacts

Rules for admin access

Best Practices

Email Notifications

User Accounts

Roles

Development Procedure

Environment Details

Introduction

As the ServiceNow development environment is a shared resource, used by all campus ServiceNow developers, some rules and standard practices are required to ensure fair access and promote harmony among the developer community.

This document is intended to serve as a living guide that includes rules which must be followed, best practices, helpful tips, common pitfalls, and other information of relevance to active ServiceNow developers at NC State.

About Key Words

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”,  “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

Acronyms

OOB Out-of-box; shorthand for objects provided by the vendor (usually in an unmodified state)

Contacts

For suggestions to this document or questions regarding its content, please contact Mike Donathan.

[back to top]

Rules for admin access

There are ground rules and best practices for having an admin account in the ServiceNow dev instance. Not following these rules may lead to revocation of the admin account.

Rules:

  1. ServiceNow Certified System Administrator certification is required to obtain developer access. Initial requests for a developer access account require a stated business case.
  2. Don’t be bad.
    1. Examples of being bad:
      1. Modifying/using another admin user’s account.
      2. Modifying records/settings/files that belong to someone else (i.e. don’t modify others’ applications without their knowledge and permission.)
      3. Impersonating another user’s admin account.
  3. Update sets should be broken down into logical problem and timeline pieces (put changes together that make sense to always be together.)
  4. Always use the correct update set! Things in Default will not be saved during a system update. Try to avoid using Default; if your change should not be persistent you should use a personal dev instance or a demo instance (developer.servicenow.com and demo###.service-now.com/login.do where ### is 001-025)
  5. Update sets must be named using this format:  initials-date of completion-topic
  6. Don’t move update records between update sets manually (or via scripting) — contact Mike Donathan.
  7. Review the changes listed in an update set BEFORE marking it completed, to ensure you haven’t accidentally changed something major without realizing it.
  8. Don’t re-open a completed update set unless you check with Mike Donathan.
  9. Provide a clear description of your update set’s purpose; if you are modifying a high access (incident/knowledge/cmdb) area, provide extra detail on how/why.
  10. Never impersonate another admin user’s account (see rule 1, but very clear on this one)
  11. When in doubt if you should do something, stop and ask!

[back to top]

Best Practices

There are a number of best practices for developing in ServiceNow that should be followed (major pitfalls and how to avoid them). This list IS NOT exhaustive, but a starting point.

Email Notifications

Non-OOB email notifications must have a weight and priority set.

If the notification’s table has other notifications that may also fire (e.g. if your notification is on the Incident table), the notification must also have filter conditions which must be as narrowly tailored as practicable to meet your needs.

User Accounts

Standard (non-privileged) user accounts are created automatically as part of the campus data import process that takes place overnight. If a service account is needed (e.g. for external application integration, or some automated process), that may be created through the standard ServiceNow interface (System Security > Users).

Service accounts must have the attribute “Internal integration user” set to true (check the box).

Standard/non-privileged accounts for end users must not be created through the standard ServiceNow interface. Instead, use the standard campus process for creation of computing accounts. Within 48 hours of campus account creation, the user account should be created in ServiceNow.

Roles

Roles control access to features and capabilities in applications and modules. Adding roles to users or groups may require additional licensing cost from ServiceNow. The department a developer is working for will be responsible for purchasing required licenses.

[back to top]

Development and Testing Logistics

Changes to the system are first developed in the dev environment, where the changes are stored in update sets (see rule #2 above). Once development is complete, developers can request their update set(s) be moved into the test environment for user testing.

Once the updates have been evaluated in the test environment to the developer’s content, developers can then request their update set(s) be moved into the production environment for use by normal users of the system.

Any ‘breaking’ bugs should be resolved before moving update sets into the production environment. Production should never be used for identifying and quantifying bugs which also exist in the test environment.

Testing Best Practices

Before releasing your changes to a test group beyond the developers, ensure your test group has been assigned the correct roles to access the application or module affected by the changes. This is especially important when introducing new features or permissions never before seen by your test group.

Update Set Review

Before update sets are pushed to the next environment (dev → test → production), they are reviewed by ServiceNow group staff for adherence to ServiceNow best practices and existing rules, as well as to ensure your changes don’t negatively impact other areas of the system.

Some update sets will require more review than others; small update sets relating only to a custom application will be reviewed less closely than large update sets and those which affect core business areas of the system (e.g. Incident).

Schedule

Update sets will be moved on a regular basis, according to a set schedule:

Dev to Test

Schedule: every Monday, Wednesday, Friday.

Request deadline: Noon, previous business day.

Test to Production

Schedule: every Tuesday.

Request deadline: Noon, Friday prior.

Emergency fixes / urgent patches

Emergency fixes will be moved on demand, pending staff availability and review.

Changes to this schedule will be made for holidays and other disruptions to staff availability (e.g. conference travel). The schedule will be maintained in Google Calendar.

Developers who routinely submit update sets which require additional review (e.g. large sets or those which impact core system areas) may be asked to follow an earlier request deadline to ensure changes can be adequately reviewed before deployment to the next environment.

[back to top]

Environment Details

Development – ncsudev.service-now.com

Primarily used by ServiceNow developers for development of all system changes.

Testing – ncsutst.service-now.com

Primarily used by ServiceNow developers and their application/feature testers to test and evaluate system changes to ensure the desired result.

QA – ncsuqa.service-now.com

Primarily used by the ServiceNow team for an additional testing environment. Mostly for plugins, full upgrades, etc. Administrator access is restricted to only members of the ServiceNow team.

Production – ncsu.service-now.com

The “live” production environment used by campus. Any ‘breaking’ bugs must be resolved before update sets will be moved into production.

To log in with your administrator account in the development environment, you must use this URL: https://ncsudev.service-now.com/login.do — your admin credentials WILL NOT work on the Shibboleth login page.

[back to top]