Introduction

This article is intended for ServiceNow application developers, citizen developers, power users, process owners and interested members of the technical community across campus. It contains management standards, guiding principles and best practices governing the NC State ServiceNow platform.

In This Article

• Guiding Principles
• Key Roles
• Instances & Access
• Platform Support Procedures
• Change & Release Management
• Developer Tips and Guidelines
• Testing and Quality Assurance
• Rate This Article
• Related Documentation

Guiding Principles

The ServiceNow platform is a resource used for business process automaton and is available for use across campus as an 'enterprise class' solution.  The platform is designed to be robust and scalable in balance with maintaining high-quality, secure data and supporting maximum use and value. 

Overarching principles for the platform are as follows:

• Think and do putting the user experience first
• Challenge the status quo
• Seek the quickest path to value within acceptable risk
• Out of the box first

Back to the top

Key Roles

This table includes roles relevant to platform management and governance.  It is not a complete list of roles and responsibilities.

Back to the top

Instances & Access

NC State leverages 3 primary and 2 supplementary instances. The primary stack includes development, test and production instances.  The supplementary stack includes sandbox and edge instances.

Key Considerations:

• Including fewer instances streamlines the code promotion, cloning and environment maintenance process.
• The developer's quality assurance testing must occur in the development instance, which could be affected by active development.
• Any requests for advanced testing requirements or parallel development streams must be reviewed and approved.

Note:  A 'Personal Development Instance' (PDI) is a ServiceNow-owned and managed environment intended for a developer's personal use for testing, demonstrations, proof of concept, experimentation or learning the platform.  These environments are encouraged but not supported by the NC State ServiceNow Development team.

Access

This section defines the instance management standards to support users in the following ways:

• Reduce risk by using a defined process and within predefined maintenance windows.
• Reduce the mean time to resolve (MTTR) incidents or outages by clearly defining support procedures and teams.
• Prevent incidents and outages by defining the process to modify system properties or enable plugins.

All NC State Unity ID holders can log into the NC State ServiceNow environments. 

Access is available in each instance to all modules including ITSM, HR Case Management, Global Risk and Compliance, IT Operations Management, as well as custom applications. 

**If the ServiceNow Certified Systems Administrator certificate or higher level CIS certifications are not available, an exception must be requested. The request for exception must include a summary of the developer's equivalent skills and experience (attached to the access request). 

Advanced Permissions

Administrative Access to the Sandbox Environment: Intended for use in performing proof of concept and testing upgrades without affecting the development cycle. 

Impersonation Access: Allow you to impersonate other users to facilitate testing. “Impersonation rights" extends access to a broader data set, therefore, a business case is required. (Available for development, test and sandbox environments.)

How to Request Access 

Requests for access can be made from the OIT Service Portal for the ServiceNow Service Offering. Please provide business case for all requests.

Back to the top

Application Configuration Management for ServiceNow

The ServiceNow platform is managed in the Configuration Management Database (CMDB).

Each ServiceNow custom scoped application and top-level module is managed as an individual configuration item in the CMDB and has a named owner.

The base information currently tracked in the CMDB is as follows

Platform Support Procedures

NC States ServiceNow platform technical support is centralized under OIT.  The support team is comprised of trained systems administrators with product knowledge and real-world experience. The team strives to help the user community resolve issues as quickly as possible.

ServiceNow application support services include access provisioning, patch management, plug in updates, release management, cloning, security audits and other system administration duties. Service offerings are available in the ServiceNow Service Portfolio located on the OIT Service Portal. 

How to Engage Support

The pathway for developer/technical support for the ServiceNow platform is as follows:

Clearly identify the issue, problem or question. 

View the ServiceNow Product Documentation

Search the ServiceNow Community. You must create an account in the ServiceNow Community in order to post.

Search the NC State Knowledge Bases or search the ServiceNow Knowledge Bases for known errors, useful solutions, and troubleshooting tips. 

Developers and IT professionals with a ServiceNow ITIL license can open a ticket directly using the SERVICENOW assignment group for core platform support or OIT_CMDB_MGMT assignment group for configuration management support. (Provide clear problem statement with screen shots and instructions for recreating the issue.)

If the issue is believed to be within the scope of the ServiceNow vendor, designated NC State ServiceNow subject matter experts will open a case using the online Technical Support system in the Now Support (HI) portal  

Hours of Operation

All support tools and materials are available 24 hours a day. 

The NC State technical support team is available Monday thru Friday 7 AM to 5 PM eastern excluding campus holidays.

Service level commitments for the ServiceNow platform are under development. 

Back to the top

Availability & Maintenance

The ServiceNow vendor has a blackout period that is typically the last 2 weeks of December.  The blackout includes any changes initiated by the vendor. 

Currently, NC State's freeze period is associated with the annual ServiceNow platform upgrade.  Dates are communicated within 6 months of the planned freeze.

Back to the top

Change & Release Management

The NC State ServiceNow production instance is governed by the NC State OIT change management process.  

All changes to the production instance require an approved change request.

The change initiator is responsible for creating the change request ticket and managing the change from ideation through implementation and validation.

Before moving into production, testing approval and sign-off by the primary stakeholder for the project must be obtained and attached to the change request. The primary stakeholder cannot be the developer as part of separation of duties best practice.

The change window for the ServiceNow platform is every Tuesday after business hours.

Enterprise maintenance windows that impact the instance are communicated ad hoc according to the NC State OIT change management process.

Back to the top

Release, Maintenance and Patching Schedules

The ServiceNow platform support team facilitates an ‘Agile Peer Review’ as part of Release and Deploy Processes for the ServiceNow platform.

Items in scope to this process include configuration changes, code changes, integrations, plug ins, system properties and other changes to the platform. Governance processes and approval requirements are under development.

Update sets are moved according to a set schedule:

MID Server Maintenance Schedule

MID Servers are managed by NC State's Hosted Services Team.  CLICK HERE for the maintenance schedule.

Back to the top

Developer Tips & Guidelines

Basic Rules for Developers

Manageability, performance, upgradability, security and UX considerations are top priorities for all developers.  As such, the following rules apply:

• Do not modify/use another admin user’s account
• Do not modify records/settings/files that belong to someone else without their knowledge and permission
• Do not make changes to another user’s update set
• Do not generate excessive system output (emails, SMS, and/or push notifications)
• Never impersonate another admin user's account
• Wherever possible, make things inactive rather than deleting 
• Globally-scoped functionality should never be modified without express, documented approval from the platform owner and the change advisory board.
• Plugins will not be installed in the Dev environment that has not been paid for or entitled (approved) for Production.

Update Sets

An update set is a group of configuration changes that can be moved from one instance to another. This feature allows administrators to group a series of changes into a named set and then move them as a unit to other systems for testing or deployment.

NC State developers are responsible for developing quality update sets according to standards and best practices set forth with each successive release:

SYSTEM UPDATE SETS PRODUCT DOCUMENTATION - Tokyo

NC State specific guidelines are as follows: 

Naming Convention:

[creator initials]-[date of start/completion]-[reference topic (inc/chg/etc)]

The environment should autofill the update set name with initials and date, so only the reference/topic/description should need to be added.

Key Considerations:

It is important to use the correct update set:

• Do not use the ‘Default’ update set because items in ‘Default’ will not be saved during a system update. Default is simply the starting point during creation of the update set.
• For any application (scoped or global), the default update set cannot be moved from one instance to another; you must have a specific update set.
• Unless your development work is intended for promotion to production, you should be working (exploring) in the NC State ServiceNow Sandbox, or using a personal developer instance (PDI).
• Do not move update records between update sets manually (or via scripting). Contact the NC State ServiceNow team for assistance.
• Review the changes listed in an update set before marking it complete to prevent errors or re-work.
• Do not reopen a completed update set. If a change is required, create a new update set and have the initial update set listed as the parent.

Email Notifications

Please reference the job aid for 'How to Create an Email Notification.' There are two types of system generated emails, ServiceNow standard Out-of-Box and NC State developed email notifications.

All email notifications must have weight and priority values defined.

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 set and must be as narrowly tailored as practicable to meet your needs.

To ensure compliance with campus branding requirements, all email notifications must adhere to the 'NC State ServiceNow System-Generated Email Notifications: Standard and Guidelines'. This document outlines the standard definition and provides instructions on how to create a notification in accordance with these guidelines.

User & Service Accounts

Standard (non-privileged) user accounts are created automatically as part of the campus data import process that takes place every 24 hours. Do not create a standard user account directly in ServiceNow.

If a service account is needed (e.g. for external application integration, or some automated process), it 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). 

Roles

The ServiceNow platform uses ‘roles’ to control access to features and capabilities in applications and modules. Adding a new role to a group may require additional licensing (costs). Contact the ServiceNow support team to identify cost implications.

Back to the top

Testing & Quality Assurance

The developer is responsible for the overall test plan and conduct testing whenever changes are made to the ServiceNow platform, including upgrades, patches, hot fixes or new releases, to validate applications being developed meet your requirements, needs, and expectations and to verify that the applications being developed conform to the specifications defined in user development stories.

View the ServiceNow testing best practices for guidance.

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.

Back to the top