Is ServiceNow Multi or Single Tenant?

[lrguerino]

Hi guys, I'm new in the ServiceNow community. I'm going to do the Implementation Specialist Certification soon. I was taking a look at the Blueprint and came across with this question: ServiceNow provides customers with a dedicated database, application and data isolation using which one of the following models? A. Single-tenant B. Multi-tenant C. Hybrid-Cloud D. Domain Separation Reading the wiki you can't really tell which one is correct. Do you guys know what is the best and correct anwser here? Best regards Luca

[dhoffman]

I think it's Single Tenant, given the wording of the question - "...dedicated database, application and data isolation."

Quoting from an actual ServiceNow Proposal to a customer:

Software as a Service:

         o SSAE16 type II or better datacenters

         o 3 instances provided for Production and Test/Dev

                   • Prod

                   • Test

                   • Dev

         o Real-time data replication, high availability and nightly disaster recovery backups of production instance

         o Single tenant hosted infrastructure

         o 24x7 phone and online support

[Deepak Ingale1]

Hello Luca,

Servicenow Provides domain separation for multiple clients.

There is a single database and instance shared for all clients you will have in a domain separated environment.

Database wll be shared but It will provide you the result of domain to which you are logged in only. There is a division of data domainwise when your query comes from database. It is separate at application level.

Database and Exchange server is in premise of ServiceNow only.

[nk_dubey1]

Question have one key world "Data Isolation". How can you isolate data with Single tenant model.

I think the answer should be Multi-tenant.

Regards,

ND

[Michael Kaufman]

ServiceNow is single tenant.   A company has their own dedicated database, application and data isolation in each ServiceNow instance.   That is the answer the question is looking for.

However when a Managed Service Provider (MSP) shares ServiceNow with multiple clients using domain separation, ServiceNow is multi-tenant.   That situation didn't exist that often when that question first appeared on certification exams.

The question is now old, ServiceNow refers to themselves as "multi-instance".   Dan McGee said so during his keynote at K15. He talks all about tenancy.

Keynote Day 3

I have some more practice tests on my blog that you might be interested in. ServiceNow Practice Test 1 — ServiceNow ELITE.com

Mike

[robbika]

I don't think this depends on the definitions.

What domain separation give you is data separation and process separation but there are still caveats.

- global settings are for all

- the catalog is not domain separated

- the self-service portal is not domain separated

- many applications, such as release management and so on are not fully 'domain aware'

So for example, let's say that one company wants to automatically close resolved incidents after 5 days and another wants to do it for 9 days. This is a global setting. You would need to rewrite the business rule to cope with that difference, and that is simple example. For the self-service portal, the current recommended advice is to create a portal per customer. Crazy on maintenance.

Also yes you can create a workflow per catalog item per customer. Again, crazy maintenance!

Then you have the issue of the customer wanting to be their own service desk, or make their own customisations, and so on.

I think at best a domain separated instance works for a very strict MSP environment when basically all the processes are shared over all the companies, the companies don't do any of their own admin, and they are restricted to using just the service desk modules (incident, request, problem, change). Even the knowledge base has issues with domain separation.

Tricky things happen when customers read the wiki and want to use release management or project management, or want to be their own service desk but sometimes want to assign tickets back to the MSP, or want their own customised process, and so on. You quickly find out the limitations of ServiceNow with Domain Separation.

Then when you make any changes to anything in the system you need to test all the variations. It becomes a maintenance nightmare fast.

A further case is integrations. For example, many customers have SCCM but the SCCM module is not domain aware. You can only have one SCCM integration.

LDAP is also not domain aware, but you can have multiple LDAP connections and then tweak the transform maps to include companies and domains.

MID Server connections are not domain aware.

SOAP is not domain aware. The recommendation here is to have a different user in a domain per SOAP connecting customer, but that starts to stack up licences.

And licenses is another thing. If your customers are more than dumb end users with no roles, then they will need licenses, which becomes expensive fast.

So keep your eyes open to the limitations, because they are not written down anywhere.