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 

[Simon Christens]

Hi David,

Most of the challenges you got now will be the same in a Domain separated instance - Every company specific change needs to be done in the company domain. - And ultimately maintenance will take more time the more changes the different companies asks for.

My personal experience is that developing in a domain separated instance typically adds +50% development time.

In case you want them completely separated from each other on a table basis - What Robert suggests - making custom applications for each of the companies could be something to look into.

And as stated earlier - you need to be very careful going into the "Domain separated" way as there is no point of return once activated.

I don't know if you plan to onboard more and more companies or if its more or less a fixed amount already onboarded and also on the cost - if the companies pays for "new features" they asks for (economics which could also impact the decision on which way to move forward)

[Mathew Hillyard]

@robertwilson that would satisfy the need to separate logic but the challenge will be that these companies are using the same tables, in the global scope - incidents, problems, changes etc. - and to replicate the desired behaviour with scoped applications would require custom versions of those tables. If two companies require different logic against an Incident then you need two sets of logic, whether all in one scope, or in custom apps.

@David Watkins if your separate companies are customers, or you are a group with distinct and separate sub companies, then domain separation might be the only answer, with the significant caveats mentioned above. It's also worth mentioning that the development issues you mention (having to create separate flows, UI policies etc) apply to Domain Separation as well - developers often mix up the domain scope and create a development object in the wrong scope, visibility of records in a domain hierarchy with visibility groups etc can become a headache - so either way I don't know of a solution to have process and development separation what doesn't involve significant overhead - which is why I advise (non-MSP) customers against it. Maybe a touch flippant, but you either go for the complexity if you really need it, or you keep it simple!

[David Watkins]

thanks everyone for input and suggestions, certainly some thiking to be done in terms of what is best , technicaly and finanacially.

[Shannon Lake]

David,
I thought I would share a new set of features we have been discussing with our customers who are dealing with similar issues. I see customers frustrated because of challenges with managing multiple entities in a single instance. It’s a lot time and complexity to develop and maintain duplicating scripts, flows, and UI policies.
I might have a solution that could save you a ton of time and hassle: ServiceNow's Data Filtration feature. 
We were so excited that we created a quick 20ish-minute overview, demo, and business case here: https://ctek.events/df
Want to chat more about how this might work for your specific setup? Feel free to reach out.
-Shannon

[Mathew Hillyard]

Hi @Shannon Lake,

Data Filtration is a simpler (albeit post-query) way to enable separation of read access to data but ACLs will still be required for other forms of access, and it does not cater for process separation, which is a key requirement from the original post. 

Hope this helps!