Explain it to me like I'm 5: Multi-Tenancy

In the prehistoric days, when we wanted to use software, we had to boot it from a disk and run it on our own machines. But one day, someone decided to do the heavy lifting on the server side, enabling client machines to do the easy work. Software as a Service (SaaS) was born.

When you use software online, you are typically interacting with an "instance" of that software. An instance refers to a specific copy of a software application that is running on a cloud computing platform.

This instance can be accessed and used by multiple users over the internet, and can be scaled up or down as needed to meet the demands of the users. The cloud software instance is separate from the user's device, which means that the user does not need to install any software or maintain any hardware to access the software. Instead, the software is accessed through a web browser or a mobile app, and the data and processing power are stored on the cloud server.

At #ServiceNow each customer gets a distinct and separate instance that is run from one of the many global ServiceNow data centers. This instance has its own unique URL, such as customer.service-now.com for example. The customer is free to configure the software as much as needed, changing the table structure, forms, business logic, and the user interface. All users of that instance access it via web browser and are confined to the specific data access and functions defined by their particular role.

This instance is completely separate from other ServiceNow customer instances. No matter what one customer does to their instance, they cannot affect another customer.

However, when the ServiceNow customer is an IT service provider using the software to manage multiple customers, does the service provider need to set up separate ServiceNow instances for each client they provide service to? Not necessarily.

If the IT service provider is offering a standardized service to their clients, they can keep them separate in a single ServiceNow instance using a platform capability called Domain Separation. Domain Separation converts a standard ServiceNow instance into a Multi-Tenant instance, meaning multiple clients of the service provider can use the instance without affecting each other or accessing each other's data.

In a multi-tenant instance, not only can the data (such as IT incidents) be separated between clients, but business logic and processes can also be separated. For example, Client A could require a mandatory field on the incident form, while Client B does not. When a client user logs into the instance, their domain value is set in their user session and is used to determine which business logic is triggered, and is also automatically inserted into every query they make.

So, for example, if an IT user at Client A logs in and clicks "Open Incidents", ServiceNow automatically adds an additional parameter to the query sent to the database: 'where domain = Client A'. Every record in a domain-separated instance has a domain value. The only records returned from the database to the application layer will have the 'Client A' domain.

Business rules, workflows, UI rules can all be domain specific. The service provider can create different offerings where for example a premium service includes better Service Level Agreements (SLAs are specific agreements to respond to, or resolve issues within a specified time period). The service provider can also create custom business logic within a specific client domain (an extra approval level for example) that does not exist for other clients.

In the image above the 'global' domain is where all out-of-box business logic exists. All domains will experience this out-of-box behavior unless there is an override for a global rule within their specific domain or parent domain.

In the domain hierarchy above data flows up and process flows down. A user in the ACME domain sees all the records in that domain and children domains. The user in ACME has no access to records in sibling domains such as Initech, or parent domains such as Top. Any business logic or process defined in a domain applies to that domain and any children domains.

For example let's say the "Short Description" field on an incident form is mandatory in the out-of-box configuration, and the ACME client requests it to be optional, the global rule for that behavior is 'overridden' in the ACME domain. When a user logged in has the ACME domain in their session, the global rule for 'Short Description = Mandatory' will be ignored because the override rule will set it to be optional. This also applies to any children domains of ACME such as 'ACME EMEA'. When users from the other domains log in, their Short Description field will be mandatory because there is no override rule in their domain or parent domain.

This is an elegant way to separate data and process within a single instance of ServiceNow and provides economies of scale to both the service provider, who can manage many clients in a single instance, and to the client who does not need to purchase and install a separate ServiceNow instance to receive the benefits.

Domain separation has its limitations and is not always the right fit for this use case. The service provider is the only administrator. Clients only act as end users and cannot make configuration changes to their domain. The Service Provider needs to plan properly and be prepared to support any custom configurations they create for each of their clients.

A good analogy for multi-tenancy is living in a house vs an apartment building. The homeowner can do what they want to the house (in the absence of an intrusive HOA). They can make additions, paint it a new color, add a pool etc. They can configure the house how they wish. A person living in a 'multi-tenant' apartment building enjoys sharing the shared expenses for landscaping, pool cleaning etc, but cannot change much about their dwelling. Each has their benefits and drawbacks.

ServiceNow offers other solutions to streamline managed services such as Service Bridge and Instance Data Replication (IDR). These methods enable to Service Provider to work within their own instance while synchronizing data and process with their clients' instances.