Group Managers should be able to edit fields on groups records and should be able to add/edit member

[shikhakhann]

Hi,

Group Managers should be able to edit fields on groups records and should be able to add/edit member in the groups without consuming ITIL license.
Please suggest the best approach to achieve this.

Thanks.

[Naveen20]

Try this

1. Create a Custom Role

Create a new role (e.g., u_group_manager) that is not tied to any fulfiller license. Assign it to users who are group managers. You can even automate this with a Business Rule on sys_user_group that grants/revokes the role when the Manager field changes.

2. Create ACLs on sys_user_group

Create ACLs that allow editing only when the logged-in user is the manager of that specific group. For the table-level write ACL on sys_user_group, use an advanced script condition:

// ACL: sys_user_group - write
// Requires role: u_group_manager
// Advanced script:
answer = current.manager == gs.getUserID();

Then create field-level ACLs for the specific fields you want them to edit (e.g., description, email, name, etc.) with the same condition — or leave them without additional restriction so they inherit from the table-level ACL.

3. Create ACLs on sys_user_grmember

This is the key part for adding/removing members. Create read, write, create, and delete ACLs on sys_user_grmember:

// ACL: sys_user_grmember - create/write/delete
// Requires role: u_group_manager
// Advanced script:
answer = current.group.manager == gs.getUserID();

This ensures managers can only add/edit/remove members in groups they manage.

4. Automate Role Assignment (Optional but Recommended)

Create a Business Rule on sys_user_group (after insert/update) to automatically manage the role:

(function executeRule(current, previous) {
    var roleName = 'u_group_manager';

    // Remove role from old manager
    if (previous && previous.manager != current.manager && !previous.manager.nil()) {
        // Check if they still manage other groups before removing
        var grCheck = new GlideRecord('sys_user_group');
        grCheck.addQuery('manager', previous.manager);
        grCheck.addQuery('sys_id', '!=', current.sys_id);
        grCheck.query();
        if (!grCheck.hasNext()) {
            // Safe to remove role
            var grRole = new GlideRecord('sys_user_has_role');
            grRole.addQuery('user', previous.manager);
            grRole.addQuery('role.name', roleName);
            grRole.query();
            if (grRole.next()) grRole.deleteRecord();
        }
    }

    // Add role to new manager
    if (!current.manager.nil()) {
        var userRoles = new GlideRecord('sys_user_has_role');
        userRoles.addQuery('user', current.manager);
        userRoles.addQuery('role.name', roleName);
        userRoles.query();
        if (!userRoles.hasNext()) {
            var roleGr = new GlideRecord('sys_user_role');
            roleGr.addQuery('name', roleName);
            roleGr.query();
            if (roleGr.next()) {
                var assign = new GlideRecord('sys_user_has_role');
                assign.initialize();
                assign.setValue('user', current.manager);
                assign.setValue('role', roleGr.sys_id);
                assign.insert();
            }
        }
    }
})(current, previous);

Important Considerations

Licensing: The custom role u_group_manager should not contain or inherit from itil, itil_admin, or any other fulfiller role. As long as it's a standalone custom role, it won't trigger a license subscription.

UI Policy / Client Script: You may also want to add a UI Policy on the sys_user_group form to make non-editable fields read-only for this role, so managers only see editable what you intend them to edit.

Testing: After setting up the ACLs, impersonate a group manager user and verify they can edit their own group and members but cannot edit other groups. Use the Security Diagnostics (sys_security.do) to validate ACL evaluation.

Alternative — Delegated Administration: ServiceNow has a Delegated Administration plugin, but it's heavier and designed for broader delegation scenarios. For just group management, the custom role + ACL approach above is cleaner and more maintainable.

[shikhakhann]

Hi Naveen,

Thanks for reply.
So, the custom roles doesn't consume License?
Also, I see we have a write acl on group table protecting users from writing to the fields on the Group records.
A user should have either itil or skill_admin or user_admin to edit the data in the group records.
So, I created a test user in DEV and gave him snc_internal & skill_admin role and he is able to edit fields in the groups table.
Isn't that okay to do it this way?