Home 
Integration tips and tools 
Twitter Feed snc tweets 
Downloads SNCGuru apps 
About/Contact 
About about SNCGuru 
Contact contact SNCGuru I
often get the request to set up access for group managers to be able to manage the members of their groups in Service-now. 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 Service-now. 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.
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.
if(gs.hasRole('user_admin') || current.group.manager == gs.getUserID()){
answer = true; //Allow access if user has 'user_admin' role or is group manager
}
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 as shown here…
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(gs.hasRole('user_admin') || parent.manager == gs.getUserID()){
answer = false; //Show the 'Edit' button if user has 'user_admin' role or is group manager
}
That should do it! You may also want to create a ‘Groups’ module that is available for the role that your group managers have. This will allow your group managers easy access to the groups in the system (and with a filter access to the groups that they manage).
Comments
Posted On
Nov 24, 2010Posted By
Rick mannMark
I tried to add this functionality to our instance, but I’m seeing a syntax error when I add the scripts to the ACL and the Edit condition.
Error:
Problem at line 5 character 1: Expected an assignment or function call and instead saw an expression.
answer;
Posted On
Nov 24, 2010Posted By
Mark StangerThat’s a syntax checker issue. The record should still save though. You should also be able to get it to work (without the syntax error) by removing the last line of the script. I’ve modified the scripts above to reflect this change.
Posted On
Dec 14, 2010Posted By
Jim PiselloNice, elegant solution and easy to implement. Thanks for another great tip, Mark!
Posted On
Dec 15, 2010Posted By
Mark StangerThanks for using it! It’s a lot more fun when I know that people have found a use for a solution.
Posted On
Oct 18, 2011Posted By
NandoI’ve tried to implement this in the demo site but it’s not working. Has there been any updates since Dec 2010 to make this work?
Posted On
Oct 18, 2011Posted By
Mark StangerThis works fine for me when I set it up on demo. Make sure you edit the existing write, delete, and create ACLs for the ‘sys_user_grmember’ table. If you follow the instructions it should work just fine.