Domain seperation : pros vs cons

[IceIronDragon]

USe case :  we are setting up instance for government.

It would have two types of users : Givornment and students 

Very limited users and usage and modules.

Problem statement : We wanted to know if tomorrow we would have to onboard another government initiative with a seperate identity does domain seperation work or should we go wtih seperate instance.

Summary : if some one can provide some of the pros andd cons they have expirienced with domain seperation.

[ersureshbe]

Hi, Domain separation supports for your problem statement. No new instance is required. Use your instance as Managed Service Provider with the help of domain separation

Regards,

Suresh.

[IceIronDragon]

Summary : if some one can provide some of the pros andd cons they have expirienced with domain seperation.

[-O-]

Domain separation provides for two major needs:

- separation of processes where there is a master process at the top and it is inherited by all domains below it, but which can be overridden in lower domains

- separation of data where visibility is inherited the other way: all data in domains under a certain domain are visible to that certain domain, but not the other way around: data in upper domains is not visible to domain under it.

Of course there are nuances to this, like visibility domains, where data visibility behaves differently, but those are details.

So if you need to support any of the above mentioned two scenarios, than domain separation might be the solution. E.g. if those two government bodies must separate data and its visibility throughout, than you should go for domain separated instances. The DB of citizens could reside in an upper domain, visible to both bodies, but in lower domains, one for each body, those bodies could maintain own data about those citizens, without any being able to see the other's data. In this case your company would reside in a separate MSP domain and would have visibility into both domains for the purpose of supporting SN for the government bodies. Or you could go with two instances - but this might not be that easy on the end-users, the citizens (which would need to use two different sites as they need to access services of one or the other government body).

[Ryan Duce]

If you make the decision to use domain separation, it must be the first decision you make. You can't enable domain separation on an instance that is already productionised.

If you already have a live production instance and want another tenant, you need to either replatform to a domain-separated instance and build your customisations on top of domain separation, or add a new instance for the managed customer that wants its data segregated.

However, whether or not you need domain separation depends on which products you have.

If you are using CSM, the base product provides for data segregation by account and contact very effectively without the need for domain separation, so I wouldn't recommend using it.

If you are doing ITSM (with backend fulfillers having full ITIL access to the processes) then domain separation can effectively segment this, if you make the decision early in a new deployment or re-platform in an already live deployment.

Also think about roadmap. If you can see now that more government entities will want to onboard to your instance and will want categorically separate tenants that are logically separated, it's better to adopt domain separation now than wait a few years and then re-platform.