I think from the capabilities of ServiceNow you are correct though our need is really beyond that. We have customers that use us simply as a manager of a ServiceNow instance for them, thus they have a domain dedicated to them. But, some of them ALSO use us for what we call Leveraged Services. This means that our company own and maintains their business functions within our infrastructure, making any requests truly belong to us. Combining the two ideas together, there are client requests that should be private to them but there also client requests that exist within our company's domain structure that is shared between them and us.
I'm looking at a domain structure that can support this, giving them the privacy of their own domain yet visibility into a sub-domain under our company's domain. From a data access perspective, my structure seems to be working well. But from a usability standpoint, it's not as clear. The application defaults to the shared domain area where the user record sits thus the session domain would need to be changed before any activity starts to take place. We have found the domain picker confusing for users and want to limit their usage of it.
Managed domain simply exposes the sys_domain field for the user record. This allows us to manage the user domain independently of the domain of the company, which it defaults to. When this domain value is changed, it changes the domain which the user record exists. So this doesn't really help as, changing the record's domain, removes the shared domain capability that I'm looking for.
So, I'm looking to not change where the user record sits in the domain structure, but instead looking to force the session domain (the domain picker at the application level) to start in a different domain, that the user is given visibility into, than the user record's domain.
Here is a crude drawing of what is taking place:
Companies:
- "Us" represents our company.
- "Only Leveraged" represents a client that only uses our leveraged infrastructure BUT setup so that if they ever want their own ServiceNow space, it is available.
- "SNandUs" represents a client that uses Us for both ServiceNow as a service and our leveraged infrastructure.
- "SNOnly" represents a client that only uses our ServiceNow as a service offering.
Domains:
- Domain "Us Users": location of our internal user records. It contains "Us Top" allowing our users access to any requests within our domain structure. It is also contains "SNandUs Users" and "Only Leveraged Users" so that when client approvals are needed, access to those user records/groups are also accessible.
- Domain "SNandUs Users" contains client users for the SNandUs client. Since they have private requests under their structure, the users are given access to the client's domain branch. Since they have requests that are owned and maintained by us, they are given access to their companies sub-domain under the "Us" branch.
- Domain "Only Leveraged Users" contains client users for the Only Leveraged client. It is only split out to keep the domain structure consistent, and to allow for growth if the client wants to take advantage of our ServiceNow services offering. Beyond that, they are given access into their client branch under "Us" domain so that they can see requests that are for them but owned and maintained by "Us".
- Domain "SNOnly" contains client users for the SNOnly client. They are using us for our ServiceNow Services offering only. They only are given access to their domain. But the structure is such that if they start using our leveraged services offering, they will be granted access to a new branch under the "Us" domain.
So, to round out the conversations. I need the user records to stay in these domains to get the proper sharing between the "Us" company and the perspective client. But I would like those users, when they log in, to have their session domain set to their parent company's domain so that they can see and log requests from the perspective of that company.
