ServiceNow operates using a single tenant architecture meaning that each customer gets their own copy or multiple copies of ServiceNow in the cloud.
These copies are known as ServiceNow instances. Users can access an instance via web browser using each instance’s unique URL such as https://companyname.service-now.com.
Each instance can run multiple applications side by side, so a single instance could potentially host an ITSM, HR, CSM, and Custom Apps all at the same base URL.
This allows ServiceNow to act as a single system of record for multiple business applications, enriching each application through the sharing of data.
For example, the HR application could kick off an Employee Onboarding Workflow which in turn creates a series of Requests in the ITSM application for setting up the new employee’s computer. For more info Servicenow online training
The single tenant architecture also means that each instance is isolated from every other ServiceNow instance. Isolating instances allows organizations to keep their data and processes separate.
Some organizations will use multiple instances to ensure processes with sensitive data are kept separate from more democratized processes.
Using Multiple Instances:
A more common way that organizations use multiple instances is to separate different environments for development purposes, most commonly:
- Development Instance (companynamedev.service-now.com)
- Test Instance (companynametest.service-now.com)
- Production Instance (companyname.service-now.com)
Or as they are more commonly called: dev, test, and prod. Notice in the sample URLs above, the dev and test instances are post-fixed with dev and test (companynamedev and companynametest).
This is most often how you will see the instance URLs represented with the production containing only the company name or instance name. Learn more from Servicenow Certification
Occasionally, you may come across organizations with only two or more than three instances and even encounter other identifiers such as QA, Staging, or Sandbox.
Using multiple instances in this way allows developers to work in non-prod instances and promote development work using a standardized process.
This ensures changes to the instance (like customizing forms or adding new code) can be thoroughly tested before promoting them into the prod environment.
In total, there are 6 ServiceNow instances. Each instance has a unique set of users who are authorized to use the instance, unique groups the users can be assigned to, and unique data stored in the other tables.
It has no impact on test or prod and no impact on the Dixie Rose Delivery Services Instances. Learn practical skills from Servicenow Developer Training
In fact, even if the same usernames exist in each instance, they are not guaranteed to have the same password. The user could (and for security reasons most likely should) set a different password in every instance.
Promoting and Cloning:
As a final note on instances, it is helpful to note that once Dixie Rose Deliveries has evaluated they have multiple options for bringing their dev and production instances back into sync with one another.
First, they could chose to install the ITBM Project Management application in Production and promote up any changes they made in ServiceNow. You may hear this referred to as promoting Update Sets.
Alternatively, they could decide that ITBM is a poor fit for their organization and instead choose to clone the production instance over the dev instance.
This in effect will make dev a carbon copy of prod, making it ready for further development and enhancement.
If you choose to pursue a career in ServiceNow Administration, Implementation, or Development, you will become more familiar with these topics.
Now that we have learned what a ServiceNow instance is, the next step is to get our own ServiceNow instance to explore!
To get in-depth knowledge, enroll for a live free demo on Servicenow Training
programming land 