GoLive

Deploying ServiceNow Successfully: Success is in the Recipe

Starting as an IT ticketing platform and building its way across Customer Service and HR, ServiceNow has several product areas. Now with an IT, HR, CSM, and Security cloud, the platform is both vast and complex. So, if you are embarking on a new ServiceNow installation you might quickly realize that there are numerous tasks to perform before your system will actually be useful to your team and enterprise. In order to enjoy a clean, problem-free installation with smooth, quality user experience, it’s best to have a planned strategy and follow it.

The problem is, that no one recipe fits-all when it comes to implementation.  As you well know, each organization has its own characteristics, which come along with certain unavoidable peculiarities and quirks. Still, to be as helpful as possible, we’ll walk through categorizing the major steps to success into several key areas.

Core Data Installation 

In order for any modern software system to run, it needs to be pre-filled with certain critical data.  In ServiceNow, this data is called Core Data and it refers to the following: 

Users and Groups 

These are needed to let people log-in to the system, and to control what they have access to.  User data, including groups and group membership, are typically provided by an inbound integration, which 99% of the time is an LDAP integration with Active Directory.   

While you may think this sounds like a totally re-usable solution which should be the same for all companies that have Active Directory networks, that is not the case.  Each AD implementation has a unique structure which is specific to the organization.  Your company may have various departments or groups which are identified differently than other companies.  Also, your AD system likely has certain categories of ‘entities’ that do not belong as users in ServiceNow; these can be things like printers, or special users, and they need to be filtered out. 

So, before you begin your user integration, you will want to be sure that: 

  • An Active Directory SME is on hand to support the integration, 
  • You have identified exactly which user and groups are to be brought into ServiceNow and also which ones will not be.  This needs to be expressed in an LDAP filter specification. 
  • ServiceNow will need access to your LDAP server.  Be sure that any firewalls, VPNs or other network security mechanisms are well understood so that a clean-safe connection can be established. 

Locations 

One of the most troublesome bits of core-data can be the information stored in the Locations table (cmn_location).  This table has references from myriad places within the system and it must be pristine.  Unfortunately, getting it that clean can be an enormous challenge.  Here are two key issues that make this data difficult to get right…

  1. The location data, more often than not, comes from multiple sources, and they each treat it differently.   
  2. The location data usually does not have a good field or set of fields to ‘coalesce’ on.  This means that it is easy to have duplicate location records for the same physical place.  The most common culprit is the lack of spelling consistency.  Consider these addresses from different sources: 

With over 800 references to locations in the default ServiceNow installation (no special plug-ins installed) there are plenty of opportunities to have one of these two big mistakes occur: 

  • Wrong or deleted references:    
    • If an item was pointed to (b) above and it really should have been using (a), then it is simply referencing the wrong data.  This can break a number of search and lookup activities.  
  • Orphaned Data 
    • If the location (b) is removed because someone realizes that the correct location (a) is supposed to be the only one needed, then the record(s) that referenced (b) have orphaned data.

A recipe for loading data into locations should include, but is not limited to these steps: 

  • Try to use a single source for the master location data.  It should include all locations that other sources may relate to. 
  • Make sure that the data is unique.  There should be no duplicates such as the ones shown above.   
  • Add a Location ID column to the form and make sure it is both; 
    • unique
    •  never empty 

If the master source has some unique ID for all of its locations, then, by all means, use that.  Otherwise, add a new unique ID column.  It can be a number or alpha-numeric value as long as it is unique to each location.  

  • Ensure that all ‘other’ sources of location data have been refined to fit into the master locations and add the Location ID to every one of their rows.  Then use that ID to coalesce on. 
  • Finally, consider whether any location sources, master or otherwise, should be able to ‘update’ a location and if so- under what circumstances.  Then build-in logic safeguards to protect the data from being accidentally overwritten.  Having a location of an object or person change out from under it can cause alarming results, as well as a lot of confusion. 
    • TIP: Consider having ServiceNow be the ONLY place where locations are edited once they are in place; then outbound integrations can update other systems of record. 

Tree Picker for locations 

ServiceNow supports an optional ‘picker’ that can show locations in a hierarchy as a tree.  This is a great way to let people drill-down, perhaps from Country-to-State-to-City or maybe via a corporate hierarchy that may already exist for very large organizations.  But the tree-picker comes with some work.  First, each row in the location source data must have a Parent column.  Also, the picker often needs to be customized so that the location ‘name’ displayed is obvious to the user.

Location types 

With the introduction of Customer Service Management for ServiceNow comes a new column called the location ‘Type’.  This column is a list column so any one location can be of more than one type. Initially, this column might contain values for ‘Customer’, or ‘Contact’, but it is much more powerful when used with a little clever thinking. Using this column can help distinguish locations of equipment as being separate ‘types’ than locations for People or perhaps Buildings.  Again, every installation has unique needs and so each recipe is a bit different, but consider using this column in your solution if you have lots of types of data using different types of locations for different purposes.  The location types are stored in a table with the internal name ‘address_type’ which is the legacy name for this information; be sure to consider this if you are scripting for these details. 

Companies 

Another important table in your ServiceNow system is the ‘Companies’ (core_company) table.  While the name may seem to make it obvious what belongs in this table, don’t sell it short.  The Companies table can be used in a number of ways.  This table can hold your company, companies that your company deals with, companies that provide services or own devices in your configuration database or just about any other company-like information that can be useful to your ServiceNow solution.    

One helpful feature of Companies is the fact that it has a ‘Parent’ column.  This means that it can store hierarchies of component companies or subsidiaries.  I’ve seen this used in some rather fancy ways when combined with domain separation; but as Occam’s Razor tells us: the simplest solution is usually the best.  So be careful before you get too far into the weeds on this one. 

Other Core tables 

Altogether, there are over 30 core tables in the system.  Before you begin loading data into any of these you should consider all of your sources of data and how they may interact with each other.  Here are a few of the more common core tables that may need some initial data loaded into them; some of these will come from integrations, while others may be manually updated or rely on one-time imports from spreadsheets or other sources. 

Label  Name 
Skill  cmn_skill 
Schedule Entry  cmn_schedule_span 
Schedule  cmn_schedule 
Notification Service Provider  cmn_notif_service_provider 
Notification Messages  cmn_notif_message 
Notification Group  cmn_notif_group 
Maintenance Schedule  cmn_schedule_maintenance 
Location  cmn_location 
Department  cmn_department 
Cost Center  cmn_cost_center 
Building  cmn_building 
Blackout Schedule  cmn_schedule_blackout 
Address Type  cmn_location_type 
Users  sys_user 
Groups  sys_user_group 
Roles  sys_user_role 
Group Members  sys_user_grmember 

Do it up front!

Often you will hear that the best approach to development is the Agile approach, where you build small pieces of the larger solution and combine them over time to realize a larger total system.  While this is a great method for building well-tested software, the best way to handle core data is to get it all resolved up front before other development begins.  This is primarily due to the fact that nearly all other development that you do on your ServiceNow instance will in some way touch core data.  And you do not want references to Locations, or Users or any other core information being broken by reloading or changing this content.    

Find someone to help you.

We like to say that the technology of ServiceNow is just the table stakes. Because getting ServiceNow right and seeing a return from your platform takes more than just implementing the software – it takes forethought, consistent management, and communication. These “advisory” parts of your ServiceNow implementation take the form of Governance and Organizational Change Management (OCM). Governance is all about protecting your investment for the future. Make sure that you choose a ServiceNow partner that understands the importance of advisory… and has the technical expertise to back it up.

Continue Reading