ServiceNow Group Best Practices
Groups in ServiceNow are a container (many lovingly call a bucket) for users that have similar purposes or functions. It’s really easy to go astray with groups, and there isn’t much guidance on how to best use them and govern them (besides some honorable mentions).
Table Structure
Just a quick refresher, a Group is a record/row in the sys_user_group table. This table has a couple notable columns, including:
Manager - Should be MANDATORY, every group should have an active manager that is responsible for keeping the group up to date, in terms of purpose, members, description, etc. They should be responsible for quarterly reviewing the group. Note: Many organizations also add a custom field for manager delegates to specify additional users, or they use the OOB delegates feature in ServiceNow.
Group Email - Should be OPTIONAL and sparingly used, depending on it’s purpose some groups should never should receive any email. Also some areas abuse this field and put a dummy email address and are none the wiser.
Parent - Should NEVER BE USED, most modern day implementations, it is best to not leverage parent groups, especially for the purposes of granting roles, reporting hierarchy (use department/business unit/cost center), or “rollup”. Just hide the field and wipe your hands clean.
Description - Should be MANDATORY, every group should have a clear concise description saying what the group is for, and in a certain repeatable format. Typically it should be several sentences to fully describe the audience, usage and related process area.
Source - Should be OPTIONAL, if you use LDAP integration, this field is populated automatically. Otherwise you may choose to populate it with something, but most people choose to leave it as is otherwise. Blank for manually managed groups, and filled in for LDAP/other source.
Group Type - Should be MANDATORY, every group should have one or more group types that help categorize what process areas/purposes the group is used for. This is arguably one of the most critical fields, so you can properly filter down to relevant groups on different forms.
Notable Mentions: Hourly Rate (may be important to populate for chargeback/routing decision trees), Default Assignee (usually not used in the wild… but maybe in small organizations), Exclude Manager/Include Members (usually left as default), Points field (if you are using gamification on communities)
Best Practice Guidelines
1) Separate Process and Security Groups. As a general rule of thumb you should separate the way you grant a role, and the group you use for Catalog Tasks or Incidents. In small organizations this can make sense temporarily, but as you scale, the management of roles almost always is handled by a separate group and has separate criteria for acceptance (training, department, etc.).
2) Define and govern Group Types. As mentioned above it is critical to define a list of group types and have central control over any changes to the list. The related reference fields that point to group should all have a reference qualifier based on the type, so only the proper groups are selected. Also most of the OOB group types aren’t very good… Here is an example of groups types:
security - used for groups that grant roles
catalog - used for catalog request fulfillment
incident - used for groups that can be assigned and work incidents
problem - used for groups that can be assigned and work problems
change - used for groups that can be assigned and work change requests
vulnerability - used for groups that can be assigned and work vulnerable items
knowledge - used for groups that can be assigned and responsible for knowledge articles
approval - used for groups that are used for the primary purpose of group approvals (like a Platform governance group!)
3) Avoid Duplicate Groups. Minimize any potential for creating multiple groups that grant the same roles, and have the same purpose. Every time a new group is created, the current list should be consulted to make sure nothing else fits the need.
4) Groups should not mimic Department structures. Probably one of the easiest traps people fall under is thinking that groups somehow align to departments. Work doesn’t happen in silos, work is collaborative - therefore groups should be collaborative and cross functional. ServiceNow already has a department table structure for that purpose.
5) Don’t Hardcode groups. Besides the cloning aspect, in general it’s still not a good practice to hard code groups into things like UI actions, ACLs, and yes even flows. For security, you should be coding in Roles, and for routing, you should leverage assignment rules or a reference field on a table. The one rare exception where it may make sense to put in groups is within a User Criteria record, but even then, you still have the option to use roles.
6) Use Management Catalog Item. For handling all group related actions, new groups, adding members, updating fields, retiring, should all be handled through a catalog item with the proper approvals built in. There should be built in steps on the create group to check existing groups, and vet the business case. Then on the retirement request, it is important to check related data elements, like where groups “could” have been hardcoded, and make sure data elements like knowledge articles and incidents are moved under a new group.
7. Have a Group Management Dashboard. This is the cherry on top that brings the process full circle. Set up different reports and metrics to see how your groups are being used and if all the correct fields are being populated. Example: Set up a report for catalog groups, and make a list of how many haven’t been used in 6 months. Another example, set up a report for any groups without an active manager. Have an admin check this dashboard once a week/month and take any corrective actions.
Interested in what other best practices people have for managing ServiceNow groups, feel free to comment below!
