Ask the Expert: Live Chat | Domain Separation

[ServiceNow]

ORIGINAL AIR DATE: Thursday, June 18, 2015 | 10:00 AM (PDT) | 1:00PM (EDT)

Join John Chapin on Thursday, June 18, 2015 as he discusses Domain Separation in this session to examine the basics that include:

• Global Scope
• The Top domain
• Process Domains
• Data Accessibility
• Process Inheritance

John Chapin has been in IT for over 20 years.   Prior to joining ServiceNow he migrated from Remedy to ServiceNow while working for a financial firm in New York city.

Over 4 years ago he came to ServiceNow as an Engagement Manager in Professional Services.   John is currently a Senior Solution Consultant at ServiceNow, working with our MSP partners.

[david_legrand]

some questions I never succeeded to have answers on

1) For the generic customizations, should we make them on "global" or "TOP"? (personally, I say "on DEV, the admins are on 'global' domain but when they have to customize something, they have to check if they have an update set and if they are on 'TOP' or a 'process' domain)

2) Will it be possible to have a user using roles in different Domain in a future release? (being public in domain A and itil in domain B)

3) Often, I see "special cases" where the domain separation itself isn't enough (example "the users can see all the other users but they can see only the records on their domain and the processes are the ones of their companies"),

So we make often a mix between "domain separation" and "query business rules" to answer these requirements. Is it a good practice or should we avoid?

==> The question is more "What are the best practices when we see that the domain separation will be useful for example for the process separation but it won't be enough for the data separation?"

Regards,

[richard-service]

1) For the generic customizations, should we make them on "global" or "TOP"? (personally, I say "on DEV, the admins are on 'global' domain but when they have to customize something, they have to check if they have an update set and if they are on 'TOP' or a 'process' domain)

What is considered a "generic" customization?   It is always best practice to make sure you are in the proper domain regardless of the customization.   Be it "TOP" or the specific domain.   I have seen instances get out of whack because there are ambiguous rules which enables laziness and all of a sudden there are customizations put in the wrong place.   Treat the system like you may one day have to hand it off to someone else.   It will make your life easier (and whomever you hand it off to) ...

2) Will it be possible to have a user using roles in different Domain in a future release? (being public in domain A and itil in domain B)

There has been no firm commitments on what will be released in Geneva but I have not yet seen anything that would lead me to believe that functionality would be available.   But that doesn't really mean it will not be.   I just don't know.   I would love to see it. We have been asking for it for a bit.

3) Often, I see "special cases" where the domain separation itself isn't enough (example "the users can see all the other users but they can see only the records on their domain and the processes are the ones of their companies"),

So we make often a mix between "domain separation" and "query business rules" to answer these requirements. Is it a good practice or should we avoid?

==> The question is more "What are the best practices when we see that the domain separation will be useful for example for the process separation but it won't be enough for the data separation?"

Can you elaborate on this?   I am not sure I understand the question as far as not sufficient for data separation.   Domain separation happens first.   But normal ACL rules still apply to the platform after that.

[david_legrand]

1) Ok, it's what I think as well, either we make updates on "TOP" or on the right "process domain" but not on the other ones.

2) Ok thanks, it was I was thinking also

3) A recent example I had is:

1. One "MSP like" supporting several small "organizations / companies" but the "MSP" and the "customers" are all part of the same global organization
2. by contract, the "MSP users" can't see all the tasks from the customers, it's the customer itil team who decides if the MSP users can see or not their tasks
3. by contract, the companies could have small differences in the processes / forms...
4. all the users should see each other even from company A and company B and often a user in company A will approve things of a user in company B
5. also the companies share the same CMDB but all the companies can't see all the servers or services (example, a linux server shared by company A and B but not C while a windows server is shared by B and C but not A)

To resolve this, i proposed:

1. "MSP users" have visibility on TOP
2. We have a field "visibility" on the task table where the "customers itil users" can define if the MSP should see or not the task and we have a "query business rule" to prevent the MSP users to see these specific tasks
3. the modifications on the processes / form are done on the right domain (Domain Separation does that easily but we said "the logic of the processes should be similar")
4. all the "public" users have visibility on TOP, because of the ACL / query business rules, they only see their own incidents / requests + the approval and the tasks of the approvals (even if they have to approve a request from another company) and of course they can see all the users to use collaboration
5. The CIs are all in a "shared" domain visible by all the customer domains but a field "used by companies" has been added and a query business rule prevent the people to see the CIs used by the other companies

I think the propositions I have made are logic given the way the domain separation has been designed and don't jeopardize anything for the upgrades (it's just new business rules, a lot of "domain visible by" records and some automation) but I wanted to know if we have any best practices (performance wise, logic...) for these cases more complex than "MSP company + completely separated customers who don't know each other"

Because for now, I always have specific requirements (justified by contracts signed at top c-level) from the customers and apart during POC, I never "just configure" the Domain Separation

But thanks already

Regards,

[darrenm]

Can Domain Separation be activated for some applications (like Incident & Problem) but not other (like Service Catalog and Change Management)?

[admin_michelle]

Yes, some applications are Domain Separated, while other applications stay global in their position in the instance. Domain Separation is applied before contextual security and according to visibility established by the domain hierarchy.