Which are the best practices for Groups structure setup in ServiceNow ?

[IvanC1]

I am working on the Naming Convention for Groups in a new ServiceNow instance in my company. About the Groups structure, which are the best practices to define:

* Escalation level for a Group, (is this a field or attribute of a group?, should I define escalation level L1/L2/L3 in the Group name?)

* Should there be a differentiation of Groups that process/handle Tasks vs Incidents ?

[Michael Jones -]

In part it will depend on how your organize your fulfillers.

It is generally a good idea to have different groups for different levels of escalation (L1, L2, L3) as you often have different fulfillers that handle those issues. 

As far as tasks, again, it depends on how you want to organize your work. If you need to differentiate between incident and task work by group, then separate groups would be the way to go. If the same people handle both types (incidents and tasks) then using the same group for both might make sense.

It is common to see organizations use the approach of different groups for different escalation levels, and separate groups for requests vs. incidents. It gives a little more granularity and visibility into the different types of work you're fulfillers are doing and what their current load looks like. 

Hope this helps!

If this was helpful or correct, please be kind and click appropriately!

Michael Jones - Proud member of the CloudPires Team!

[IvanC1]

Hello Michael, tks for the quick input, definitely I will consider your comments with my team!

[Kieran Anson]

Hi Ivan,

By no means is the following best practice but my personal style. Group naming is, and should be, business specific. It should be simple enough for fulfillers to easily distinguish what a group is / does and be quickly searchable from reference fields and I would strongly suggest the use of special characters and underscores as that can cause issues in scripting and visibility. Also worth thinking about group naming if groups are exposed to end users.

Couple Examples I've seen / had over my years. Some of the values below I've had to slightly change in order to not specifically identify the company.

ARB Supply Chain Support

• ARB - Divisional Prefix
• Supply Chain - Support Area
• Support - Easily identifies this as a support type group

ARB Implementation

• ARB - Division Prefix
• Implementation - Field Service Fulfillers

XRJ Change Approvers

• XRJ - Division Prefix
• Change - Approving Area
• Approvers - Easily identifies this an approval group

I've also seen stuff as simple as "Ops" & "Dev". 

Other suggestions

• Make use of the type list. This will allow you to easily filter what a group does and only expose the relevant groups via a reference field.
• Don't go crazy with nesting, it can become a pain to manage.
• Come up with a standard for adding roles to users. Roles shouldn't be directly added to users but to groups but I have seen people create specific "role access" groups which only provision platform access and are seperate from ticket assignment groups.

[IvanC1]

Thks Kieran for the quick input! Actually your group naming examples are similar to what I have been brainstorming, I am thinking to add 3 'granularity' levels (resembling the best the company structure) and a final part showing the 'escalation' level (L1/L2/L3)