Multi-Tenancy

[abhijats]

Hi Everyone,

I have read in wiki's 'Multi Tenancy and Domain Separation Options' article:

'....some global properties, some global data and some global processes are shared across all domains (for example, the option to have the system "Remember me" on the login page of the system is global and cannot be specified per domain). If complete and utter separation of all system properties is desired and no global reporting or global process is required, then separate instances of ServiceNow is an alternative option.'

I want to know what are those global properties, data or process for which Multi-tenancy can't be implemented and need to have a separate instance.

Please share knowledge.

[Pritam6]

Is this a general question or do you have specific requirements around domain separation that you are trying to answer?

[abhijats]

I want to understand what has to be keep in mind while implementing a domain separated instance, the properties or process that can't be domain separated.
what I know is system properties will be global.

[Pritam6]

The main separation is nicely documented by the ServiceNow wiki under tha sub-heading "How it works"...

"Data Separation: Out of box, Domains are based on the Group a user belongs to, though the Domain separator can be based on anything in the system including Company, Department, Location, a completely new table, etc. Any table that contains a Domain field will inherit data separation. Domain fields can be added to any desired table to extend data segregation throughout the system. Domains can be hierarchical, for example I might have a domain structure that looks like: Europe/Germany/Berlin. Those in Berlin can only see Berlin data. Those in Germany can see their data as well as Berlin's data, etc.

Process Separation: System Policy functions such as Assignment Rules, Approval Rules, SLA Management, Inactivity Monitors, Email Notifications, Business Rules, Client Scripts, UI Policy, UI Actions, etc. can be defined globally or specifically for a particular domain. For example, if I define a specific Assignment Rule for Germany (using my Domain hierarchy example above) then both Germany and Berlin will override any globally defined Assignment Rules.

UI Separation: Forms, Lists, Related Lists, Choice Lists, etc. can also be Domain specific. If a particular domain requires different fields on their Incident form, no problem. If they want a different list of categories and subcategories, choice lists can be domain specific as well. UI Policy, UI Actions and Client Scripts can also be domain specific, which provides UI flexibility by domain."

This really is what you should be keeping in mind when deciding whether domain separation is required.

Regarding what should be kept in mind while implementing / administering a domain separated instance, its complicated and ours has certainly been a learning experience. Sadly there is no best practice or guidelines from ServiceNow.

[LearnerSubho]

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.

Ref : Is ServiceNow Multi or Single Tenant?