Domain Separation and Custom Form Layouts

[Chris Sanford1]

I am fairly new to domain separation, and am facing an issue with domain specific form layouts. I have created an incident form layout for a specific domain (let's call it Domain X), which overrides the pre-existing global form layout. From what I understand, this means any incidents in Domain X or below in the domain map will now display that form layout, but all other domains will still show the global layout. I also understand that when you create an incident, the domain of the incident is based on the domain of the user in the caller field. Please correct me if either of these notions are wrong.

The problem I am facing, happens when support users in the top domain sometimes have to create an incident for a user in domain X. When a top domain user creates an incident, the form still shows the global form layout since they are in the top domain. But once they save the form with a domain X caller, the layout 'switches' to the domain X one. So the top domain users are then confused, because many of the fields they initially populated are missing from the form, and new domain X ones show up after they click save.

This problem could be solved if the top domain users simply switched the domain picker to domain X prior to creating the incident, but many of them do not know ServiceNow very well, and this seems like a bad user experience for them. Is there another way I could fix this, such that the form layout could update in real time once they set the caller to a domain X user?

[AshishKM]

Chris , Ideally on domain separation all users belong to same domain should be in same domain. So if you can change the support user's domain to X domain in user profile they need not change the domain and same form layout will use. In a service-desk environment , support users don't have access to change the domain. 

[Chris Sanford1]

The support users are in the top domain, which is a parent of X domain. Switching the user to X domain would make them unable to see their top domain tickets.

[Michael Fry1]

Are you a MSP? As a MSP you shouldn't have overrides on form layouts.

Regardless, there isn't a good answer here. Create a record producer to capture the 'common' data, then submit and the domain changes, then finish capturing the rest of the data. If this is a one-off case, which I doubt, create a module that will generate a new record in the domain.

[Chris Sanford1]

Ah, great ideas! Yes, we're a MSP. Why is it that MSPs should not have overrides on form layouts? Some of the clients want different fields, how else would I solve this? I suppose global domain UI policies with conditions that check the company field?

But yeah, it's not exactly a one-off case, but only a couple of clients have custom form layouts. So I guess I could create modules that set the domain for these clients, and maybe even add a reference qualifier on the company field to enforce it.