Data Separation and or Domian Separation

[David Watkins]

Looking to get some advise. We have a Servicenow instance. Currenlty we have number of services 5 x  who use the same tables , Incidents, Change, Requests etc and we use the company field as a separater, this works at a level for end users and permissioons to only view this data. Where we have a problem is the continual issues around devlopments, factoring in each of these companies and making sure we done allow them to see other data. I would like to remove 1 x compnay and all data and config into a either domain separated part of the instance or another solutiojn, where we can move without to much issues and then have a secured part, and stary to remove the polices around company to allow us to develop and only worry about our own tables 

[Mathew Hillyard]

Hi @David Watkins 

The use case for Domain Separation is primarily for managed service providers, where you require both data and process separation. It sounds like you're currently doing something like this, presumably with existing platform features (e.g ACLs, before query business rules, data separation).

Domain Separation will enable both data and process (business logic) separation and is a good candidate if the companies are customers who require data separation on the same database rather than a separate instance, and who are not concerned with data residency. However, Domain Separation is not something to be taken lightly - every single deployed product on the platform has its own level of Domain Separation support, and roadmaps for that support, plus working in a Domain Separated environment brings challenges both in use and in determining access to domains and exceptions (e.g. visibility groups). It is also not something you can enable for part of an instance - it's either on or off. And reverting back to a non-Domain Separated instance in future is extremely difficult, as is enabling it on an existing mature environment. There is also a not inconsiderable licence cost.

For your use case it's not clear why with just 5 companies you have a problem? In the baseline instance it is very common to grant access to a wide range of stakeholders based on the many features in the platform, and in even quite large instances this is the logical approach. I would go back to the processes and logic for each company and work out why each needs completely different approaches, or perhaps a review and consolidation of the read/write access would make things easier to manage all round. This would be my recommendation.

Hope this helps!

[David Watkins]

thanks very much for the response. 

for example, we have an incident table and all incidents are logged to this table. We have separate businesses who have different set of users who would log tickets, so we have used a script to allow users from each company (company field added to each table) to only see tickets where you are  a member of company A or B or C etc. So for ITIL users who are administering works ok as they only see there tickets based on this separation script, against all tables used. The main issue is when developing, if Compnay A wants changes , not same as company B, we end up having multiple scripts, flows, etc and always need to configure to exclude each company , so we have loads of duplication of flows, scripts, UI actions etc, that is becoming hard to manage and development takes longer. Any mistakes impact on each company as we using same tables. 

I except cost and implications around adding domian separation, so thanks for that.

I am investigating how i can remove using this complexity and have a situation where we can clone / separate for example Company A , where we not sharing same tables , have own and therefore can develop against just company A and have scripts only for Company A, without losing all work done in each table etc. 

Again thanks for response, hope explained more detail the poisition and welcome your knowledge and advise

[David Watkins]

thanks for the prompt response @Mathew Hillyard 

To clarify the position i bit clearer to ask for additional options.

We use same instance, we use same tables, we have a column in each table called company and in that a script runs for all users , either no licence or ITIL users who can only see what there user account's company they are set as as part of an import. So There is Company A, B, C etc. 

This works fine for a separation of what users can see and dont have any real problems.

The main issue we have is when is comes to development. 

if Company A want to have different values/configuration/automation/flows etc, we have to create separate UI Policy's, flows for each company an use the separator of company to deliver these. This takes alot more dev time to separate. If any mistakes or issues, it impact on each company. Or we have to spend dev time to hide values, columns etc. 

So my preference would be to have separate tables , therefore can dev only against the tables.

So if i wanted Company A to have own tables, move all config, data, flows etc, and somehow have it separated, then this would be a better solution long term, especially if they add another company to the mix, the dev of that takes ages., 

thanks in advance and thanks for responding

[robertwilson]

Could a solution be to implement a scoped app per company, encapsulating any company specific configuration, tables etc that way?