Foundational Guidelines – Group Naming

There usually are two circumstances when this topic gets center stage: implementation planning, and when things go sideways.  More ofteng than not, it gets the most attention when things go sideways and everyone is in a panic about how to fix their foundational data woes.  The concept of Enterprise foundational groups is not a terribly complex one, but sometimes resembles a foreign language when described and typically requires the use of a metaphor to reach a common understanding.  So lets us a house metaphor association for foundational groups.

During the construction of a house, foundational groups can be associated with a basement where the utilities (HVAC, plumbing, and wiring) connect the house to the city infrastructure and the floors above. If your basement is like mine, “conduits” are used to deliver the utilities throughout the house.  If your conduit runs are designed strategically in the basement, then you will have years of use without any issues.  If there are flaws in the design, then usually a major renovation would be your eventual recourse.

But even with a well-designed basement, there will always be additions and renovations to support requirements.  This is to be expected and a structurally sound basement make these additions function as if they existed when the foundation was first poured.  I’ll refer to the house metaphor many times when describing foundational groups so it’s best to lay the foundation first.

Initial go live foundational groups

One of the first things you need to do when designing a basement is to figure out how the utilities will be clustered and where the conduits to the upper levels will be placed.  There will be core conduits like HVAC and electrical and supplemental conduits for cat 6 and coax.  Like a house groups its conduits, your Servicenow groups will also be aligned into core conduit grouping and supplemental conduit groupings. Core conduit groupings support services, AD registration, and role inheritance.  Supplemental conduit groupings support Servicenow modules, operational purposes, and other apps.

Your core conduit groupings in Servicenow are assignment, fulfillment, alignment, supplemental, and role.  Membership within each conduit in your sys_group table will be uniquely identified by its type column.  Flows and form dropdowns will need to be cognizant of the type of group it is looking for and include the group type column when determining the appropriate core group to include in its lists.

There will be a degree of cross reference that naturally occurs between conduits primarily within the alignment conduit memberships primarily to decrease repetition.  Supplemental conduits can be an exception to the rule as they can have a hybrid purpose intersecting with several of the other conduits.  The role and alignment conduits are the typical intersection points within the supplemental conduits.  A sAFE set of groups is a great example of a supplemental conduit that intersects with many of the other conduits.

During implementation a common mistake is to align your conduits to your organizational hierarchy.  It may all be well and good for a while, but the first major re-org will be a cause for pause when determining long term viability.  Typically on the first go around little is known how the overall system will eventually be designed, so its more efficient at this point to align your core conduits to your service portal categories (security, collaboration, mobile, etc).  Each conduit will maintain a parent child relationship mapping that contains the core groups applicable to the service category it represents.  Role conduits will branch off of the upper most category group and can also be the parent of the core group if the roles maintained by the role group are designed as a universal inheritance model for the core group(s) that have the role group as its parent.  What I’m referring to here is a basic three level structure where level 1 is the category group, level 2 is the role group acting as an alignment group, and level 3 is the assignment, fulfillment, etc. core groups.

The naming used within your group conduit is also equally important because the display name for the group can be nebulous at times when the customer requires a specific name for the group instead of a standard default representation.  Nebulous display names can be a killer for group automation so there needs to be an easily mapped programmable method back to the conduit when programmatically accessing it.  The method that should be used here is an AD adaptation that can be used even if AD is not utilized in the overall solution.  This AD structure adaptation will be the lynchpin for all future automations. 

While group display names in a list can literally be named anything, your AD structure will be refined and precise – and totally 100% outside of customer visibility.  To implement the structure you will need to add the column u_sAMAccountName to the sys_group table.  U_sAMAccountName has the distinct purpose of identifying to AS that the group is a Servicenow group and is named using the conduit acronym applicable to its membership.  The first concept is quite important if you have a Servicenow OU in AD as duplicate group names in AD are always an issue (a common issue within an Enterprise with 10 of thousands of group OUs within AD).  The second concept is equally important so you can find the group quickly when your Servicenow group contains thousands of entries.  By applying a standard prefix to your AD groups like SnLvl1 MOBILE identifies the group as Servicenow (Sn), the alignment level in the conduit, and its portal category (MOBILE). Using this simple method, you will always be able to locate your group quickly in AD and will always be able to derive conduit membership and placement with each and every nebulous group name.  A typical alignment conduit will look something like this

Role Conduit (role inheritance @ lvl2 to membership): SnLvl1 APP >> SnLvl2 APP ITIL

Role Conduit (role inheritance lvl2 to Lvl3 to membership): SnLvl1 APP >> SnLvl2 APP KNOWLEDGE >> SnLvl3 APP SHAREPOINT KNOWLEDGE WRITER = Sharepoint Knowledge Writer (Servicenow name)

Role Conduit (role inheritance @ lvl3 to membership): SnLvl1 APP >> SnLvl2 APP >> SnLv3 APP SHAREPOINT POC = Sharepoint POC (Servicenow name)

Alignment Conduit (no role inheritance at any level): SnLvl1 APP >> SnLvl2 APP >> SnLvl3 APP SHAREPOINT US EAST = Sharepoint US East

The last example of a group conduit is a membership conduit where the Servicenow group Sharepoint East could be the fulfillment group assigned to the eastern US region.  The only way to tell if this is a fulfillment group in a group list would be via the “Fulfillment” designation placed in the type column.  Usually all alignment conduits rely on the type column to fully define the purpose of the conduit.

Where international enters the picture for a global enterprise, multiple regions of groups exist within a now hybrid conduit. There are an infinite number of hybrid conduit configurations, but when working within an international foundational group structure you’ll need to address the region in both the Servicenow group display name as well as it’s u_sAMAccountName.  With AD the following is an example of a mobile hybrid conduit where the level 3 groups inherits its base role from the level 2 role conduit.

Role Conduit: SnLvl1 MOBILE >> SnLvl2 MOBILE APPROVER >> SnLvl3 MOBILE WORDPRESS MGMT = WordPress Approver (Servicenow name)

This quickly becomes a more complex hyprid conduit when international regions enter the picture where like core groups all inherit their role from the level 2 role and all level 3 groups contain a prefix alignment to the applicable region.

SnLvl1 MOBILE

SnLvl2 MOBILE APPROVER

SnAMER MOBILE WORDPRESS MGMT = AMER WordPress Approver (Servicenow name)

          SnEMEA MOBILE WORDPRESS MGMT = EMEA WordPress Approver (Servicenow name)

          SnAPAC MOBILE WORDPRESS MGMT = APAC WordPress Approver (Servicenow name)

While it’s perfectly acceptable to use this model to align Enterprise core group conduits for an initial go-live of Servicenow, core foundational groups typically require an additional layer of abstraction shortly after go live to augment the base structure.  Even if go-live was a little haphazard in the design of their basement, there is a little glimmer of light at the end of this tunnel when the subsequent service model is applied.

Supplemental conduits will be for all of the additions you add to your house.  Supplemental conduits are typically function specific and have a much smaller footprint than core conduits but apply to the same basic principles that core conduits apply to and also can be used in a hybrid fashion.  Operations, sAFE module, AIOps, licensing, etc. are good example of a supplemental group conduits designed specifically to support a Servicenow function and/or module.

var lvl1 = new GlideRecord('sys_user_group');
var lvl2 = new GlideRecord('sys_user_group');
var lvl3 = new GlideRecord('sys_user_group');

lvl1.addQuery('active', '=', true); 
lvl1.addQuery('u_samaccountname', 'STARTSWITH', 'SnLvl1');
lvl1.query();

while(lvl1.next()){

     gs.print("Lvl1 ******* "+lvl1.name+" assignment group "+lvl1.u_samaccountname+" ("+lvl1.sys_id+")"); 

     lvl2.initialize();
     lvl2.addQuery('active', '=', true);
     lvl2.addQuery('parent', '=', lvl1.getDisplayValue('sys_id'));
     lvl2.query();

     while(lvl2.next()){
                              
            gs.print("Lvl2 ************** "+lvl2.name+" ("+lvl2.u_samaccountname+"-"+lvl2.sys_id+")"); 

            lvl3.initialize();
            lvl3.addQuery('active', '=', true); 
            lvl3.addQuery('parent', '=', lvl2.getDisplayValue('sys_id'));
            lvl3.query();

            while(lvl3.next()){
                  gs.print("Lvl3 ******************** "+lvl3.name+" ("+lvl3.u_samaccountname+"-"+lvl3.sys_id+")"); 
             } // L3                 
      }  // L2
} // L1

Now even if your current set of foundational groups are in disarray, a service model for foundational groups can be applied to your existing group structure to bring them back into line.  This is part 2 of the foundational group series.

Service model

The initial go live model is a simple parent child hierarchy using the parent reference column on the group table.  Each group stays within their own functional conduit, but the initial MVP will be lacking the appropriate references to activate a rich set of reports, dashboards, and performance analytics.  The existing category conduits are created by using the type column, which is referenced by “everything else” to derive items such as the correct drop down selections in forms. Core group activation is performed by adding the core foundational group types of fulfillment, assignment, and role to the type table and applying one of these types to each group created, creates self-sufficient conduits for all your core groups. Alignment groups are utilized to structure the conduit and are also identified via the type column.   Names are critical for identification purposes within a conduit and provide means for evaluating the conduits in an automated way.

Now even if your current set of foundational groups are quite a mess, a service model can be applied to your groups to bring them into line.  Bottom line it’s fairly safe to say that mostly every enterprise has not used the prior model during go live.  Even ones where I participated have deviated a bit due to external forces.  That’s where plan B comes in – The post go-live service foundational model.

The post go live model is an abstraction that adds depth to the original go live model and it equates to a large scale renovation of your house, but leaves the  original structure intact (even if it is a bit of a mess).  This is implemented in service now by creating a global app that performs all of the mapping facilities that the alignment groups do but in a service oriented mapping structure.

Even if you implemented the initial go live model, you will likely move to the post go live model to amplify your capabilities when you start associating your CIs to their respective service line support model.

That about sums up enterprise foundational groups in a nutshell.  While I realize there is not a lot of detail provided here, its quite important to create the foundation concept to wrap you head around the house model before attempting to explain further in-depth concepts.  In supesequent posts  I’ll write a little bit about the in-depth concepts AD/ADFS, automation, automated group creation/ maintenance (AIGroups), scripting, integration hub (particularly the Powershell shell spoke) and support play into the overall enterprise foundational group picture.

This is one angle for doing enterprise foundational groups that is currently in-place within a large organization.  Service now is a participation sport, so please add to the conversation.  That’s the only way this method can adapt and survive and actually thrive by placing it in the wild!