Tips and Tricks? Ensuring users select the correct domain

[Ryan S]

Hi All,

EDIT:  This actually appears to be happening regardless of the itil user selecting their domain; the issue is the Assignment Group doesn't follow company/domain.

Does anyone have any advice, tips, tricks, etc to help ensure an itil user selects the correct domain when submitting a record (e.g. incident)? It just seems terribly simple for them to forget to select the domain first. In the previous multi-tenant system, all one had to do was set the Company field. While that's still the first thing the itil user must populate on the incident in ServiceNow, it still must come after setting the domain.

Thanks in advance for any suggestions or ideas on this matter.

[Kieran Anson]

Hi Ryan, I just want to jump in an query your statement of "While that's still the first thing the itil user must populate on the incident in ServiceNow, it still must come after setting the domain."

That shouldn't be the case. Setting the company on (most) task based records will drive the domain implicitly. This behaviour may not work if certain domain properties are changed, or the OOB domain setting business rules are changed/deactivated. 

An MSP user, with correct contains/visibility permissions, should not need to change domains with a well-architected domain hierarchy 

[Ryan S]

hi @Kieran Anson, that's for the input. So let's say you are an MSP itil user and you're creating an incident for customer A who belongs to company A. When I load the incident form, the domain on the record is set to global. I then populate the Company/Customer which will change the domain but that doesn't take effect until the incident is submitted. Until it is submitted, I can (for example) view Assignment Groups from Global instead of (desired behavior) only seeing Assignment Groups for the Company's domain. What am I missing here?

[Kieran Anson]

Have your MSP itil users been set in the global domain? They should be in a MSP-specific domain below TOP. What are the values of the following properties out of interest?

glide.sys.domain.use_record_domain_for_processes

glide.sys.domain.use_record_domain_for_data

[Ryan S]

Hi Keirnan,

I mis-stated info in the previous post. Apologies but here is the correction. As an MSP itil user, when I create a new incident the domain is set to whatever domain I am currently in. That domain will change based on the user/company I select. Regardless, the 'Assignment Group' field does not appear to follow the domain (record or session) but instead the visibility of the MSP itil user. This results in the following scenario:

MSP itil user submits incident for Company A. The incident domain is set to Company A. MSP itil user can select Assignment Group = Company B ITIL Users. Company B ITIL Users cannot see the incident because it's not in their domain, but it presents a problem to have something able to be assigned to an invalid group.

Does that make sense? How do companies handle that situation to prevent the wrong groups being selected?

As for the properties, they are both set to true. MSP users are not in global, but in the MSP company/domain.

Sorry for the prior confusion; thanks for the input.

[Kieran Anson]

Hi Ryan,

Your query does make sense and is often a point of contention. It boils down to the behaviour of domain separation:

• Record scope, which is based on the domain of the record, takes priority. Although a user may have access to other domains, they can only access data to which the domain of the record has access. So for assignment groups, the group would need to be in either global, or a domain visible by the domain of the record (which could be more if the domain has a containment rule)
• Session scope is what the user has access to. It's based on their visibility of domains, containment, etc. If they have access to the domain picker, they can override this behaviour.

For the MSP organisation:

1. What style of MSP is this? Is the MSP company a single entity that provides support to multiple customers based on sold services (cloud management, networking etc)? Or is this an MSP instance where customers act as fulfillers in their own domain, and the MSP is providing over-arching instance support.
2. Does the MSP need to ability to reference data from outside of the customers domain? An example would be linking a customer incident to a configuration item that is within the MSP domain.
3. Are there compliance policies needed within the MSP org itself. For example, users offshore can only support certain customers and therefore have restricted domain access to a subset of customers