Allow Group Managers to Manage Group Members

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') || == 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 ‘’ 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

(function executeRule(current, previous /*null when async*/) {
if(!gs.hasRole('user_admin') && != gs.getUserID()){
//Abort the insert or update
gs.addErrorMessage('You do not have permission to modify this group membership.');
}})(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

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).

Date Posted:

August 9, 2010

Share This:


  1. Rick mann November 24, 2010 at 12:35 am


    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.


    Problem at line 5 character 1: Expected an assignment or function call and instead saw an expression.


    • Mark Stanger November 24, 2010 at 1:20 am

      That’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.

  2. Jim Pisello December 14, 2010 at 7:56 am

    Nice, elegant solution and easy to implement. Thanks for another great tip, Mark!

    • Mark Stanger December 15, 2010 at 2:05 am

      Thanks for using it! It’s a lot more fun when I know that people have found a use for a solution. :)

  3. Nando October 18, 2011 at 11:06 am

    I’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?

    • Mark Stanger October 18, 2011 at 4:06 pm

      This 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.

  4. Aric February 8, 2012 at 8:23 am

    This was awesome and works great, thanks!

    I also stole this and modified it so that group members can modify information in their own group; however, I would like to restrict their access to being able to modify just two custom fields without having to create an ACL for each field. Any suggestions?

    var answer = true; //Restrict access by default
    if(gs.hasRole(‘user_admin’) || (gs.getUser().isMemberOf(current.assignment_group))){
    answer = false; //Allow access if user has ‘user_admin’ role or is a member of the current group

    • Mark Stanger February 8, 2012 at 11:52 am

      You’ll probably need at least 3 total ACLs then. You’ll need one ‘sys_user_group.*’ field level ACL that locks down write permissions to the entire record – probably to everybody but admins or something. Then you could use a script like you’ve got above in a couple of field level ACLs for just those fields that you want to open up.

      • Aric February 8, 2012 at 2:54 pm

        Finally figured out what I was doing wrong, incase someone else wants to do this. Mark is correct about needing an ACL to give write only permission by default to admin, and an ACL for each field that needs write access, or just one .* ACL if you want group members to be able to write to all fields in the group. My problem was with the script in my previous post.
        The correct script is as follows:

        var answer = false; //Restrict access by default
        answer = true; //Allow access if user has ‘admin’ role or is a member of the current group

  5. Kari Sweeney October 24, 2012 at 2:12 pm

    Hi Mark,

    Thanks so much for these instructions – this is working great for us!. I have just 1 question in regards to your very last statement about creating a ‘Groups’ module to make it easy for managers to get to their groups. You recommend making that module available to whatever roles our managers have. In our case, managers do not have a special role…they share a role with all other IT users (similar to the itil role). Is there a way to hide/display this module in the application navigator based on whether or not they are a group manager….basically, using the same script as we’re using in the ACL’s?

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


    • Mark Stanger October 24, 2012 at 2:14 pm

      Good question, and I’m glad you’re liking the solution. Unfortunately, modules can only be restricted by role. You’ll need to give your managers a separate role in order to show the module to them, but not to regular users.

      • Shaun Oelofsen October 24, 2012 at 8:34 pm

        Hi Mark,

        Would it not be possible to restrict access to the modules through the use of a query rule, much the same was as it can be used to restrict access to applications via query. I have this running on some of our customer instances, but havent tested it on the actual modules.


        • Mark Stanger October 25, 2012 at 5:09 pm

          You’re correct that it’s technically possible, but the problem is that none of the structure is there to restrict access on a per-module basis based on anything but a role. The before query business rule restricts access to modules, but it doesn’t have anything to say which module to restrict access to. If you did use a before query business rule you would need to build out some additional fields, or add a bunch of clunky conditions to check the titles of the modules you wanted to restrict in a certain way. If users already have one role, then it’s usually much easier to just grant them one additional role and be done with it.

  6. Anoop P October 30, 2012 at 3:55 am

    Hi Mark,
    I have tested this on demo.But,the user having no user_admin role can’t see the groups.So,will u please help me to sort out this issue.


    • Mark Stanger October 30, 2012 at 4:22 am

      The article assumes that the managers have the ‘itil’ role. I’ve just tested this out on demo22 with ‘ITIL User’ and it works correctly. You can review the setup in that instance to get a working config.

  7. Rachelle Sanon July 25, 2013 at 2:55 pm

    Is there a way to modify the code, so that it looks if you are the manager of the group or a member of the group?

    • Mark Stanger July 25, 2013 at 5:12 pm

      Sure. Take a look at the ‘isMemberOf’ method here…

      The general syntax in an ACL would probably be something like this…

      • ravali May 14, 2015 at 10:41 am


        I tried using this in my ACL script, but it is returning FALSE always even though user belongs to the group. I am trying to impersonate the user and I see this value always returning FALSE.


  8. John Lampson December 19, 2013 at 3:37 pm

    Thank you so much! Now our managers can modify their own group memberships!


  9. Rachelle Sanon December 20, 2013 at 10:51 am

    We’ve noticed in our instance, that while users are able to add users, when they attempt to remove and save the action. Nothing changes….is that a bug?

    • Mark Stanger December 20, 2013 at 10:56 am

      Probably just a mis-configuration. If you can’t remove the users from the group it probably means that your delete ACL on the ‘sys_user_grmember’ table isn’t allowing access.

      • John Lampson December 20, 2013 at 10:59 am

        Mark is right – I had to add that into my ACL because I was having the same issue. Works like a charm and adding in a “My Groups” module with a filter for only stuff of which that person’s the manager is going to be so helpful!

        • ravali May 14, 2015 at 9:29 am

          Hi Mark,

          Thanks for a beautiful solution. I tried this and created 3 ACL create, write and delete. As you suggested the script for write and delete is the same. I am trying to make the users of the groups to be able to add/delete members.

          When I do edit, I am able to add but when trying to remove from the slushbucket, nothing is happening.

          Can you suggest why?


          • Mark Stanger May 14, 2015 at 9:48 am

            Thank you. The only thing I can think of is that you’ve got some other Delete ACL on the ‘sys_user_grmember’ table that is preventing the delete. You can debug ACLs to help identify which one might be causing the problem.

  10. Shawn Dowler June 25, 2014 at 10:48 pm

    I am noticing that the manager can add and remove groups from any user form. Is there a simple way to restrict using the New and Edit buttons on the related Groups tab on the User form?

    • Shawn Dowler June 25, 2014 at 11:44 pm

      I asked before taking the time to look into it. I personalized the list control on the User record for related Groups and added the role user_admin to both New roles and Edit roles. That appears to do what I want. Otherwise the manager (and presumable other itil users) could do strange things like create a new group (with all empty fields) and associate it to the user. Or even worse, they could add and remove the user to and from any other group.

      Thanks for this excellent solution. Now I won’t have to be the full-time Assignment Group editor.

      • Miguel Schöngarth July 21, 2015 at 7:16 am

        Thank you Shawn,

        I have discovered the same. Horrible when roles are assigned to groups :-).

  11. Annette August 28, 2015 at 5:42 am


    Could you please write on this wich version it applies to, I think it works a bit different on Eureka.


    • Mark Stanger August 28, 2015 at 6:47 am

      Should work on any ServiceNow version without issue.

  12. Adam Rasmussen October 17, 2016 at 12:02 pm

    On the Omit Edit Condition, in Fuji release, I had to create a function around this process otherwise it was I was unable to save the form. Unfortunately, it’s still showing the edit button on every group.

    function checkgroupmgr(){
    var answer = true;
    if(gs.hasRole(‘user_admin’) || parent.manager == gs.getUserID()){
    answer = false;
    return answer;



    — Adam

    • Mark Stanger October 17, 2016 at 5:57 pm

      I’m not sure why it’s not working in your instance but I’ve never seen an issue with this and I’ve got it running in our Crossfuze production instance successfully right now. No function required and the script exactly as shown.

Comments are closed.




Fresh Content
Direct to Your Inbox

Just add your email and hit subscribe to stay informed.