Guidance Required to Restrict Manual Group Creation Without Impacting Existing Role Access

[AaishwaryaK]

We are currently working on restricting/arresting the manual creation of groups in our ServiceNow instance.

During the analysis, we identified that there are 3 roles which allow users to manually create groups. However, we found that these roles are:

• Inherited through existing groups
• Interlinked with other roles/access
• Used for activities across other related tables and functionalities

The concern is that directly removing these roles from users may impact their existing access and activities in other modules/tables.

We would like guidance on the best approach to:

• Prevent manual group creation
• Restrict only the group creation capability
• Avoid impacting users’ existing responsibilities and related table access
• Handle inherited/interlinked roles safely

Could you please suggest:

1. Recommended best practices for restricting manual group creation
2. Whether ACLs, UI Actions, Script Includes, or custom roles would be a better approach
3. How to isolate group creation permissions without affecting other dependent access
4. Any governance model or refinement approach commonly followed for this scenario

Any suggestions or similar implementation experiences would be helpful.
Thanks in advance.

[Tanushree Maiti]

Hi @AaishwaryaK 

1.  Instead of allowing manual group (sys_user_group) record creation, create a Request Item (catalog item) that requires approval  and uses flow designer to create the group.  This way it can be tracked and record can be documented, audited properly.

2. Create a "create" ACL on the sys_user_group table to restrict access to the New  button, ensuring only members of a specific group ( like "System Administrator") can create them.

3. Implement a Before Business Rule on the sys_user_group table to abort the insert if the user creating it does not have a specific role ( like Admin), and show a message: Groups must be created via the Request Item)