Best practices for Group Setup

[Joshua Cassity]

Good Morning Community,

We're about ankle deep in our StartNow Implementation and we're getting the foundation data ready for importing. One of my tasks is to get our listing of support groups ready and I've got a question about maybe a best practice approach or what others have found success with in organizations similar to ours.

We have a structure within our organization where we have many different silo departments/agencies that have their own support groups underneath them. For instance,

Department of Fun (a fully independent department)

        Pool Fun (Support Group)

        Ski Fun (Support Group)

        Surf Fun (Support Group)

Department of Crossfit (another fully independent department)

        Burpee Assistance (Support Group)

        Weight Lifting Spotters (Support Group)

        Stretching Coaches (Support Group)

My initial thoughts were when setting up these groups to setup the department as an umbrella or catch all group for that department and then to setup the support groups as well but point them to their appropriate parent groups. I believed this would help distribute permissions to both the entire department at once (catalog views, ESS, other roles as needed) while maintaining the ability to specifically target license based roles to those more granular children groups. However, after speaking with our implementation team I get the idea that this may not be a best practice when approaching this issue.

Does anyone have any experience in doing the group hierarchy in this manner? Was it a good thing? Was it a bad thing? Any lessons learned or possible alternate approaches to this issue would be greatly appreciated.

Thanks guys.

[Brad Tilton]

I think typical the way people do this is just with a group hierarchy without departments being involved. Generally roles are meant to be assigned to groups with them cascading to the users of those groups, and getting departments involved in that I think could give you some trouble down the road.

[Joshua Cassity]

I think maybe there's some confusion on the terminology I used.. I'm not speaking about Departments in ServiceNow.. in our hierarchy lingo they are actually named "Department of <insert department name>" so I'm only referring to nesting groups here. Maybe a better example of how I had anticipated setting these groups up:

Group 1 named "Department of Transportation" - No Roles

        Terry Buffdude

        Wesley Snipes

                Sub-Group named "Software Support" - ITIL Role

                                                          Joe Smith - Inherited ITIL Role User

                                                          Bob Jones - Inherited ITIL Role User

                  Sub-Group "Transportation Hardware" - ITIL Role

                                                          Larry David - Inherited ITIL Role User

                                                          Jerry Seinfield -   Inherited ITIL Role User

Does that make more sense now?

[Brad Tilton]

So your parent group would include some users with no roles, but it would have subgroups that contain users with roles and your subgroups would have the itil role on them? I guess I'm not quite seeing why you would need the parent groups in this case.

[Joshua Cassity]

That would be the initial setup.

I'm also thinking we would use these parent groups to easily attach any custom roles for applications we create in the future or other items that would affect the entire "department" such as service catalog visibility/access - given they each will have their own internal service catalogs as well. This was my thought process.