I

often get the request to set up access for group managers to be able to manage the members of their groups in ServiceNow. This configuration isn’t too difficult to set up but it does involve a few different pieces. It’s also important to consider your group setup in your system before allowing access in this way. If you are bringing in group memberships from a data source like LDAP for example, the last thing you want is to have your managers manually changing those group memberships within ServiceNow. The configuration shown below could be easily customized to allow access only to non-LDAP groups if you needed to do both however.



This solution requires you to modify the out-of-box ACLs for the ‘sys_user_grmember’ table. You’ll also need to modify the ‘Omit Edit Condition’ field for the ‘Group Members’ related list on the ‘Group’ form. These configurations are outlined below.

Write and Delete ACLs (‘sys_user_grmember’)
The following script can be used within your Write and Delete ACLs on the ‘sys_user_grmember’ table. No other roles or conditions are necessary for this configuration.

 

var answer = false; //Restrict access by default
if(gs.hasRole('user_admin') || current.group.manager == gs.getUserID()){
   answer = true; //Allow access if user has 'user_admin' role or is group manager
}

Create ACL(‘sys_user_grmember’)
The create ACL works a little bit differently because we don’t have access to ‘current.group.manager’ before the record is created. Because of this, you need to open up create permissions to the role that your group managers will have. Typically these managers will have the ‘itil’ role anyway so you can just set up your ‘create’ ACL with the ‘itil’ role defined in the related list at the bottom of the ACL.
‘Restrict Changes to Group Managers’ business rule
Opening up the create ACL is necessary for this configuration to work, but needs to be backed up by some additional security in the form of a ‘before’ business rule. The business rule performs a secondary check on insert/update of the group member record to ensure that the user is actually a group manager or has the ‘user_admin’ role. If not, it aborts the insert/update and alerts the user.

 

Name: Restrict Changes to Group Managers
Table: Group Member [sys_user_grmember]
Name: Restrict Changes to Group Managers
Before: True
Insert/Update: True
Script:

(function executeRule(current, previous /*null when async*/) {
    if(!gs.hasRole('user_admin') && current.group.manager != gs.getUserID()){
        //Abort the insert or update
        gs.addErrorMessage('You do not have permission to modify this group membership.');
        current.setAbortAction(true);
    }
    
})(current, previous);
List Control ‘Omit Edit Condition’
The final piece of controlling ‘Create’ access is to limit the visibility of the ‘Edit’ button on the ‘Group Members’ related list on the ‘Group’ form. You can manage this by right-clicking the related list header and selecting ‘Personalize -> List control’ from the context menu. You can place this script in the ‘Omit Edit Condition’ field to restrict visibility of the ‘Edit’ button on the related list to those who have the ‘user_admin’ role or are listed as the manager of the given group.

 

If the ‘Omit Edit Condition’ field is not visible you can add it by personalizing the ‘List Control’ form
var answer = true; //Hide the 'Edit' button by default
if(gs.hasRole('user_admin') || parent.manager == gs.getUserID()){
   answer = false; //Show the 'Edit' button if user has 'user_admin' role or is group manager
}
answer;
 
 
Please mark reply as Helpful/Correct, if applicable. Thanks!