New Instance Checklist
There is often a tremendous gap in the planning and implementation of a new ServiceNow instance. Whether you are setting up the first instance for your organization or the seventh, this is a helpful guide to make sure you check all the boxes.
Provisioning - How do you get a new instance?
New ServiceNow instances are generally bought through a contract/purchase order, and are denoted as being a production or sub-production instance. Also the instance availability SLA and sizing (at least initially) are determined at this step. If the instance is a net new instance, once provisioned the denoted administrator on the account will receive the account password.
New instances could also be zBooted (aka wiped) ServiceNow instances, which are reverted back to OOB. To request a zBoot, you submit an automated form on ServiceNow Support (HI) site. It is strongly recommended to zBoot with Demo data enabled. You can always submit a request to remove the demo data at a later time. To zBoot a new production instance, a HI case is required as it is a manual request. As part of the zBoot completion the denoted administrator on the account will receive the account password.
Change Default Login Credentials - Sounds obvious, but so many people skip this step. The password should be changed to a new lengthy complex password, and store this in your companies secure credential vault. Either a software vault or physical vault for a rainy day.
Setup
Instance Naming - A short thoughtful name should be defined and should represent the purpose of the Instance. ServiceNow best practice is not name instances exactly as the company name. Once a name has been selected and accepted, one of the HI Account Admins for should submit an Instance Rename request. Be aware that changing an instance name can break the SSO configuration, MID Servers, and REST consumers, and email of that instance. There are also a number of rules around instance names, review KB0550841 for more info.
Process Usage - Define and document what use cases this environment will solve. Is is a production, qa, test, dev, sandbox, lab, poc, etc? What are the rules around moving code? Who is allowed to have admin in this environment? Who is going to support the environment? You need to have all these questions answered and be able to clearly describe the scope of use.
Cloning - This may not immediately apply, but if you plan to clone from an existing instance onto this new instance, it speeds up a ton of configuration steps. Define if this environment will be a clone source or target or never touched by a clone. Also consider what the cadence for the clone should be (quarterly, twice yearly, etc).
Firewall/Network Whitelisting - To even access your instance, your IT team needs to whitelist it the instance name, or the entire *.service-now.com domain. It’s also strongly advised that you do the reverse, and whitelist your network from ServiceNow via the IP Address Access Control.
Authentication Approach (SSO, MFA, Local Login, etc) - Decide how users are going to authenticate, and if you are going to allow more than one option. Many organizations I have seen stick primarily to using SSO as it provides the best user experience. You likely will have to coordinate with your infosec team to set this up properly.
Branding - Based on the name and usage, you may want to consider to set the browser title property and the banner header property to denote the instance. For UI16 you may also want to set a different default theme so users can clearly distinguish (hopefully next experience UI comes out with more themes soon).
Development Group - Define what your admin group and developer group is going to be, and setup those accesses. Setting up a new instance doesn’t have to be a solo gig!
Remote Sources - As part of your process, define what instance you are going to allow code movement from. Example for a QA instance you may only allow update sets from Test and Dev.
MID Server - As part of this new instance, you need to decide if you need MID servers for what your use cases are. Do you need to support integrationhub, discovery, orchestration? Also determine the specs and how many. For subprod environments like Test, Sandbox, you may only need a couple MID servers, and in some cases just a single server will do.
LDAP? - I added a question mark because depending on the authentication approach you may not authenticate/load users from Active Directory. Many companies use Active Directory, and then consume Active Directory data into ServiceNow to load the users.
User Setup - Besides LDAP, you might consider doing an initial load of users manually via XML from another instance, using an excel spreadsheet with a transform map, or set them up manually. It really all depends the usage strategy. It is also strongly advised you set up some local system accounts, such as admin, integration users, mid server users, backup admin account, etc.
Email Configuration - OOB ServiceNow comes configured with their own email server capabilities. You can use and enable theirs, and verify it passes through to your network with a whitelist, or hook it up to your own email server. There is an email diagnostics page you can check for the current status.
Install Plugins - Regardless what use cases you defined, chances are high you are going to need to install a list of plugins and apps from the store. To pull a list of plugins from the instance you can reference sys_plugins.list and sys_scope.list. Some plugins require manual requests through ServiceNow Support such as Application Insights has to be manually requested.
Security Center Checklist, Instance Scan and Health Scan - Wrapping it all up, you should step through ServiceNow’s Instance Security Center capability, and lock down the properties in your instance as best you can. ServiceNow also provides a suite of Instance Scan checks you can run as part of that. Additionally ServiceNow has a more detailed paid service, called Health Scan, and that can show many more additional findings related to security.
Final Remarks
Setting up a new instance can be a hassle, and also be a multi-month process to get all the capabilities spun up. At the end though, it’s very rewarding knowing all the interworkings of the instance.