Request Management in an MSP / Domain Separation context

[Ryan S]

Hi All,

The design of service request catalog items and their supporting workflows in a domain separation context is where we could use guidance to help minimize development and maintenance effort of the catalog items and flows. I’ve found a fair bit of “best practice” guidance on ServiceNow sites, youtube, community, etc. and the Domain Sep documentation provides technical knowledge, but I haven’t found anything directly addressing this nor have I been able to connect all the dots with the available materials. Hoping the SMEs here can help get the puzzle pieces straightened out here. Sorry for the longer post, but thanks in advance.

For example, let’s say we have a service request called “New User Account” that could be used by 10 companies. However, there are some variations to handle:

1. Companies 1 & 2 require an extra approval activity in the flow
2. Companies 3 & 4 have an extra question (variable)
3. The form asks “select an application.” Companies 5 & 6 have a different set of values in the choice list.
4. Companies 7 – 10 have a very different set of questions and flow activities.

So the questions center around “how do we minimize our build and maintain effort while making it easy for our agents (as service providers) as well as end-users to submit their requests?" Of course ServiceNow provides multiple ways to solve a problem, but it’s harder to figure out if some options are ill-advised, indifferent, or best practice. Here were some initial thoughts on the approaches for each scenario:

1. For scenario 1, we can just add an if condition in the flow.
2. For scenario 2, we can just have the variables shown/hidden based on company.
3. For scenario 3, we can create different variables or (maybe) override the choice list for the specific company(ies)
4. For scenario 4, some combination of the above or maybe it’s better to build a completely separate request.

All those options take the approach of no overrides. Should we instead have overrides to address some or all of these scenarios? It seems like it would get very complicated to start mixing approaches. If we do overrides, what the easiest way to allow some companies to share the same override?

Now let's throw in Scenario 5 where there are actually 15 companies. The extra 5 shouldn't even have access to this request.

As if that wasn't complicated enough, let's focus back on the agents submitting requests. If they do NOT change their domain picker, then they would need to select the company and we let that drive the domain.

1. If the request is only available for 10 out of 15 companies, how do we prevent them from selecting the 5 companies that shouldn't be able to use this request?

2. Once they select one of the valid 10 companies, if we're NOT using overrides then everything should work, right?

Lastly, you may have noticed the absence of changing domains. Yes, that is intentional. Can we make this work without forcing agents to manually change their domains?