Skip navigation

A ServiceNow group is a container for users that have similar purposes or functions. Creating and managing groups in ServiceNow should not be taken lightly, as many ServiceNow functionalities, such as task assignments, approvals, security, and emails rely on groups. With that in mind, here are my top tips and best practices for enhancing and managing groups in ServiceNow.



Assignment groups are the most common group type. ServiceNow has an out of the box dependency between assignment group and assigned to fields. Typically, it’s mandatory for the assignment group to be identified on task records before a user can click save. These assignment groups will allocate responsibility for working on the task to a specified team so that nothing drifts into the “ticket abyss.” Even if that particular team is not responsible for working on the task, the group is now responsible for reassigning the task to a more suitable group.


From a manager’s perspective, groups allow for detailed resource reporting, including what each team is working on, which teams may be overloaded and which teams have availability to take on new tasks.


Some examples of assignment groups are:

  • Service Desk
  • Network Administrators
  • Server Administrators
  • Database Administrators
  • Application Developers


These groups can also have a hierarchical structure. So, if you’re using ServiceNow for HR, you may consider setting a parent/child group dependency like this:


  • Human Resources
    • Benefits
    • Payroll
    • Recruiting
    • Learning and Development



When designing approvals in your ServiceNow workflows, you have the option to select user approval or group approval. I highly recommend using group approvals as much as possible since it allows you to add or remove members from a group without any development. Even if this group only contains one person, it’s still a preferred method. You can also create custom groups for approving any process. A CAB (Change Advisory Board) group may be needed to approve high risk changes.



As a best practice, ServiceNow recommends never assigning roles (permissions) directly to a user. Instead, it recommends creating a group to which you can assign roles. A group can have as many roles as needed, and ServiceNow Admins can define those roles using the Access Control List (ACLs). The ACLs allow you to set read, write, create and delete access for fields data, records and tables. With this granular security ability, you may need to create additional groups for elevated permissions.


Examples of applying roles to groups include:


  • ITIL vs. ITIL Admin: ITIL has basic read/write capabilities whereas ITIL admin has an elevated level that includes delete. Typically we see the ITIL role assigned to groups such as Service Desk, Network Administrators, System Administrators, etc. while the ITIL Admin is usually assigned to a managers group, such as IT Managers, that contains each ITIL group’s functional manager.
  • Knowledge vs. Knowledge Admin: The Knowledge role is able to create, edit and review articles, while the Knowledge Admin role is also able to publish and retire articles. In this case, a hypothetical group called Technical Writers might have the Knowledge role while a Content Manager group might have the Knowledge Admin role.


You can refer to the ServiceNow Wiki for a more detailed description of each out of the box role.


Using groups can also improve security by limiting Catalog Items displayed on the Service Catalog or restricting visibility of certain reports for specified groups.



The last type of group to consider is email notification groups, which are most commonly used in task assignments. You can use these groups to automatically send an email letting users know that a task has been assigned to their group and is now waiting to be assigned to an individual.



Here are the recommended fields to fill out when populating group information:

  • Name: This one is fairly obvious, but you will want to give your group a name.
  • Manager: Setting a group manager allows the system to reference that individual for other processes.
  • Email: If you fill out email, any group emails will send to this address instead of individual users in that group. Unfortunately, distribution lists without a fully qualified email address will not work.
  • Parent: If you are setting up a group hierarchy like in the HR example above, you will need to add a parent group name that already exists.



Managing LDAP groups is out of the realm of ServiceNow administration. For manually created groups, I usually suggest creating a Service Catalog item called “Add/Remove user in ServiceNow group,” which will do all of the management autonomously.


To create this catalog item, you’ll need to have at the very least a mandatory reference or list variable referencing the user table and a reference to the group table. Other variables such as business reason are optional and can be added for your process. Once the requester fills out all of the other necessary details, he or she will order the request. The first step in the workflow is to send an approval to the group manager. Once approved, the user(s) will be added to the group requested via a workflow script. If rejected, no action is taken and the requester receives an email.

This method removes much of the manual maintenance from the ServiceNow administrator and provides a “paper trail” for when that user was added or removed and why.

Filter Blog

By date: By tag: