Domain Separation, Type = MSP

[raprohaska]

I think I understand but want to make sure. When using domain separation, each domain is given a "Type" choice (OOB) of MSP, Customer, Vendor. From what I can tell the type of domain is simply for categorization and does not bring any functionality along with it. Visibility is dictated by contains and visibility domain while access to functionality such as domain picker, toggle domain scope, etc. are controlled by role.

Is there any functionality that I'm missing from a domain type = MSP perspective within domain separation?

Thanks,

[marcn]

what kind of approach could be used in order to accomodate sister companies of an MSP if these companies need to access organization data + cmdb of MSP but not requests/cases.

is it a good idea to put all organization data + cmdb of the MSP in a specific domain and then define contains from sister company domain to this data domain.

any suggestions or pointers would be really appreciated.

[raprohaska]

I don't think there is a single answer, it is really dependent on need, maintenance ability, and user strength in understanding the usage of domains.

In general my approach is based on a couple of questions:
1. Who owns the data? or Who should be allowed to modify the data?
2. Who needs to report on the data?

Who owns the data?
This can be a tricky question, especially in terms of the CMDB because some users might be able to write tickets up against a set of CIs but technically do not own the data? Should they have direct access to the CI or not? In our world, our company owns hardware but that hardware is dedicated to a client. In that case, I don't feel the client needs any access to the CI itself, they should not be able view an IP address or any configuration data for a particular hardware. So, we create a Business Service within their domain and the CI itself in our domain followed by a relationship between the two.

**Everything is data in ServiceNow, even process elements like Business Rules, Assignment Rules, Workflow, etc. The main difference between "data" data and "process" data is that process flows from parent to child domain while data flows from child to parent. When asking who owns the data, you also need to ask, who does the process apply to?

Leading to "Who needs to report on the data?"

Based on my example, The client is able to report on tickets written against their version of the business service while we can extrapolate through the relationship. This question can also expose if you need "roll-up" domains. For example, we have two divisions in our organization, domestic and Europe. So all our clients will not sit under the same domain structure which allows us to reporting per division, even though those domains do not directly expose process or hold data. The domain is there strictly to segregate the divisions.

Usability

All of this thinking has to be paired with usability questions because, unless all your processes and forms and choices   all sit in the global domain, users will have to use a combination of the Domain Picker and Toggle Domain Scope button (which is hidden in a context menu, and only exposed a certain times). I find the usability challenging even for some admins, so to think that an ITIL user, that may or may not understand "domain"   will find it even more challenging. I'm actually having a meeting with ServiceNow domain architects today to work on how to drive users into the proper domain.

One last note, depending on what version of ServiceNow you are on, that will play a role in the usability challenges. Concepts like Toggle Domain are only available after Fuji I believe. The MSP plugin also changed then and if you upgraded and already had the "old" MSP plugin activated, it will not upgrade to the new domain plugin. http://wiki.servicenow.com/index.php?title=Domain_Separation_for_MSPs#Requirements

Sorry I don't have a more clear answer and as simple as the idea of domain separation is at its foundation, the mixture of usability and data ownership can clearly make domain structure a challenging design task.

I have yet to receive any feedback but this post exposes some of the challenges I'm facing with my domain design:
Domain Strategy with Domain Separated Workflows

Hope there is something useful in here,

AA

[marcn]

thanks a lot Aaron for taking out time to give a detailed response.

If I have to answer the 2 questions then I would say that its we the MSP who owns and modifies (cmdb + org data). To some extent its also our job to report on the data (cases and requests) as part of compliance and contracts.

But ofcourse we need to give the customer the freedom to report on their cases and requests.

So the critical question - where to keep the org data about MSP employees/users/admins ?

I still think that a separate domain with just CMDB data solves a lot of issues for us , is this the right approach ?

[raprohaska]

I think this is the easiest to maintain domain structure. The MSP Users have direct access to all client domains without anything special being done. Through use of Toggle Domain Scope or setting "glide.sys.domain.use_record_domain_for_data" property to false, MSP Users can still assign CIs from the MSP domain to the client records. OR, we have chosen to tie business services to our CIs. Each client gets their own version of the business service (as they typically have different contracts and such tied to them) thus the Client Users have direct access to those business services and available in the client domain to create and maintain tickets... what CIs are tied to those business services through the BSM for MSP Users.

I guess if you have truly co-owned CIs and you can trust your clients with access directly to the CIs, you could look at a shared domain, granting access to that shared domain with Contains Domain. I have been working with similar design for sharing users across multiple domains but almost always trend back to the more simplistic structure previously stated. I'd be interested to see where you land. Domain has many challenges and usually you are trading off ease of use for data security. You sort of have to play until you find the right blend for your organization.

Good Luck,

AA

[raprohaska]

Per this example, there are two MSP domains and they both happen to have the same client. Both MSPs have their own domain because they have data private from each other. So, Parent 1's users would sit in parent 1, Parent 2's users in Parent 2 and client users would sit in Middle. The only difference between Parent 1 and Parent 2 is that one has a type = MSP and one with a type = customer.

Again, I stress the fact that this example was only to have a scenario to talk to. The underlying question is does "domain.type" affect functionality. From what I have found, the answer is NO. I have created a series of domains without setting Type on any of them. Domain access is completely handled via Contains Domain and Domain Visibility. I could use the demo data in the system... change all the domain types = Customer/Vendor, and everything would work the same from a usability perspective even though no domain is set to MSP.

Domain Type is strictly used as a way to categorize a domain.