Domain Seperation | Managing the users on Global domain

[vrnath]

Hello All,

Appreciate your help on this.

Currently we are working on Domain separated instance. Where we are facing an issue with the users. Right now, we have a domain structure like this:

Global

|

Global/Company   (where Company we built all the blueprint and have access to all the data in global and all customer domains)

|

Global/Company/CustA && Global/Company/CustB

We are having the different support groups and users (Support people) are in Company. From there we already given access for users the visibility to see all the data in CustA & CustB (Eg: Reporting the incidents by the CustA & CustB can bee seen by the support group people based in Company). As we declared all the users in Company we dont want to create the users (support people) in Cust A and Cust B. We want to create some different groups for Cust A & Cus B and want to add these users (Support people) to that groups.

As we are using the AD and making the userID as email. So while to recreate the users also will be an issue with duplication.

The other thing we tried to make these users( support people) as global, but they are getting access to all the domains from the settings menu and as well as the data. (thought to write an access control on Domain table and only allow Admins with domain = global to be able to create/write and delete items on domain table. - is this one will work to not show the drop down of the domain menu in settings)

Thought to make the group as global but once the incident is created - change the domain to company and still the users is not populating.

How to make the users (support people) to be created under one domain and is there any way to utilize that users on other domains. As its a domain specific environment the records created in one domain cant be visible in other domain.

Please suggest me if you have any other alternative which i missed.

Thanks in advance!!

Raghu

[vrnath]

Hi Deepak,

Thanks for your response,

I went through the both threads earlier, but bit stuck up with the before query business rule, As i havent used much on that query business rule.

Thread answer -

prototype example:

1. Set the "global_visibility=true" attribute on the "sys_user" table "collection" record in the dictionary.

  This will make the user table GLOBAL meaning all user records are potentially available to everyone until the ACLs are applied

2. Create a before query business rule that limits users to user records in their own domain plus ones you create a special attribute for.

  Condition this rule so it does not run at all for MSP users

And in another thread they suggested that to go with ACL - and create a group and add all the MSP users under it and restrict them. According to this, I think first we have to make all the users under global domain and then create some different groups where the support people will be and then we have to go with ACL, And in future if some support people wants to change their area of work and again we have to take them and put them in different group. i thought managing this in future is a bit tricky. Suggest me if i am wrong

• I created a group that would contain all of the users whom I need to limit access for.
• I created an access control rule for all tables that would check to see if the user was in the "limited access" group and the sys_domain of the record for the domain that needed this restriction.

if (current.sys_domain == {your sys_id} && gs.getUser().isMemberOf({your limiting group sys_id})){ answer = false; } else { answer = true; }

These both threads they have also the similar kind of issue we are facing now.

Will wait for your response,

Raghu

[Deepak Ingale1]

Hi Raghu,

My approach normally would be

1) Configure only "admin" accounts in "global" domain. Other accounts must strictly be restricted to "customer" domain to which they belong. If access to other domain is required, this can be set up using "Visibility" domains. I would ask people to follow the process to assign the tasks to group and not to the people. Queue manager, team lead of the respective group should manage the queue.

2) Once done, make sure "global" domain accounts (admins) are not available for other users in the system. This can be done via before query business rule. Global admin accounts can only be visible to users with admin role.

Tip For Creating Complex Before Query Business Rules | Service Now Gems

Fixing the Fatal Flaw of Before Query Business Rules - ServiceNow Guru

Controlling record access using 'Before Query' business rules - ServiceNow Guru

3) Setting up groups: Setup the groups at domain level of the customer if these groups are not MSP groups. MSP groups can be setup at global domain and using the before query business rule, you can restrict their visibility. I would try to configure the "list collector" field on my groups in "global" domain.

This field will refer to "domain" table and will list down all the domains of the users to whom these groups should be visible.

[vrnath]

Hi Deepak,

Thanks for your response,

Exactly our approach is in point 1 what you mentioned, we created the admins in the global domain and they will have all the control in related to all development and stuff. And then created all the respective users under the customer domain.And created the Support people who support the CustA & CustB for incidents, we created that support people and groups in MSP (company). The tasks will be assigned to groups only as the group field is mandatory and not assigned to. We already given the visibility domain access to all the support people who are under MSP, and all the support people can able to see all the tickets logged under the CustA & CustB.

Global

MSP -Company - Parent Domain

CustA & CustB - Child domains under company

MSP Groups are created under the MSP domain. And MSP groups contains several (support people) users records are present in MSP(company) - (So for this you want me to creat a list collector field - give it reference to domain - so that we can able to select the domains where this MSP group will have the visibility) - But as we declare the group as global or MSP and we can see the groups but not the users in it - when we try to access this global group from other domains.(like custA & CustB)

CustA & CustB - we created a different named support groups and in that we want to push the users (support people under MSP) records into this newly created groups under cust A & Cust B. This is the issue we are not able to see the users (support people under MSP) in CustA & CustB as the user record is there in MSP.

Will wait for your response.

Thanks

Raghu

[Michael Fry1]

It sounds like some users in CustA or CustB have itil role to work tickets. Is that correct? Normally we wouldn't expose the Assignment Group to customers.

[Deepak Ingale1]

Hi Raghu,

My suggestion was to have MSP groups configured on 'global' domain, other customer specific groups into the customer domain only.

MSP global group visibility can be controlled via the combination of "display business rule" and "list collector" field on group table.

This list collector field should only be filled up with "domains" which requires a visibility for global MSP group since global records are visible everywhere irrespective of the domain, and we dont want MSP global groups to be available for unwanted domains.

For rest of the groups, your OOB domain design is sufficient enough to control the access and visibility.

CustA & CustB - we created a different named support groups and in that we want to push the users (support people under MSP) records into this newly created groups under cust A & Cust B. This is the issue we are not able to see the users (support people under MSP) in CustA & CustB as the user record is there in MSP.

This can be solved by the solution already provided by Michael.Fry by using toggle domain option.