Considerations for All ServiceNow Administrators as they Build and Configure
Introduction
I often write about leveraging the platform for bespoke business needs, thoughts about proper design and architecture, reviews of ServiceNow solutions and how they fit into an overall platform strategy. But sometimes it’s good to focus on the basics – what a manager I had called “blocking and tackling” – the fundamentals of administering a ServiceNow platform for its overall health and creating the best experience for users. These are things I tend to take for granted, but then I see customer instances and realize people working in ServiceNow are not thinking about them.
(I’ll grant that ServiceNow itself doesn’t always do this – I’ve seen plenty of out-of-the-box elements that break these rules. Not much we can do about this – we can only control what we can.)
This is the first of several articles on this topic. I’m aiming to focus on the most fundamental parts of administration in this article.
Form and UI Administration
Let’s start with some basic administration: managing forms and the UI. Some of the most “blocking and tackling” there is. I’m not a UI/UX designer by trade, but I know what looks good and can apply common sense to some of these things. Sometimes it’s just about stepping back and putting on your user hat, thinking, “If I was a user would this make sense and look good to me”? It’s also important to note that these suggestions apply to the standard UI (currently called the Next Experience), not Service Portals or Workspaces (though some concepts carry across).
- Ensure your labels are all in the same case structure. Take note of how the fields on your form are labeled and match the case structure (Title Case, Sentence case, ALL CAPS). Be consistent with this across the platform and feel free to fix inconsistencies in the out of the box labels. Label modifications are not customizations!
- Ensure labels do not wrap in form views: Use the simplest language and words for your labels. Abbreviate where needed. Use Hints and Tooltips to provide longer explanations if needed. (Wrapped labels are ugly and messy.)
- Ensure common form elements are in the same place across all forms. All task-based records (Incidents, Changes, Cases, Requests, etc) have many fields in common: Assignment group, Assigned to, State, Priority, etc. Assuming these fields are used on the forms for the task-based records, the best User Experience (UX) is achieved by ensuring the fields are the same place on each form. This way users’ eyes are drawn to, and accustomed to, a common experience. Conversely, it can be disconcerting if the State is on the bottom left on one form and the top right of another form.
- Use Form Sections wisely. Form Sections exist for a reason: they help declutter your forms and give you a place to organize and keep fields that may be needed but aren’t needed by everyone on every record. Here are some considerations for using form sections:
- Use the top of the form, the “non-sectioned” portions, for the most critical, always-used fields on a record. And keep them consistent from form to form (see #3). Use form sections to divide other fields into sensible divisions. For example, I recently created form sections on a Project record for Dates, Financials, Settings, Related Records and Notes.
- Put very lengthy UI elements on a tab that is not open by default, so scrolling is not cumbersome by default. The obvious choice for this is the Activity log (comments, work notes, updates etc). Putting this on a form section tab that is not the first one allows users to scroll to related lists more quickly, particularly if there is important information there for working the current record.
Table Administration
- Check for out of the box fields first. This has multiple meanings. The first and most obvious is you should not create new fields if an out of the box one exists that will serve the purpose. Secondly, and more importantly, do not add a field to a table if the data required for that field can be accessed by dot-walking through a reference field. For example, if the business requirement is to add a Requester’s phone number to an Incident record, and you can use the dot-walked mobile phone field from the User table, use it! Don’t add fields just to add fields, and certainly don’t duplicate data unnecessarily. (Of course there are business needs that dictate a new field, but that’s for another discussion.) And finally, when creating new fields, look for out of box examples to mimic so that there’s a consistency of implementation across the platform. Look at field types, names and labels, max length, attributes and other attributes before blindly creating new fields.
- Put new fields at the correct table level. This pertains to tables that are part of a hierarchy, for example, Task is the parent of Incident, Change, Case, etc., and the CMDB is a pyramid of tables starting with CI (cmdb_ci) and going on down. Always create fields at the lowest level possible so as not to muddle parent and sibling table data structures. An obvious example is the CMDB: if you’ve got a need to capture an additional data point on a Windows Server, add the field to the Windows Server table, not the CI table! You should also strive for normalized data, in that a field shouldn’t be mostly blank because it exists at a level where it is typically not needed.
- Create the correct data type. It is key to understand all the data types available in ServiceNow and choose the type that best fits the requirement. There is inherent functionality with particular data types that should be used; for example, using a numerical data type prevents entry of a non-numerical value without having to add any policy logic. Here are a few specific cases where I see people getting themselves in trouble:
- Choice fields: It is very important for platform sustainability to only use Choice fields (and the sys_choice table) for simple pick lists that are generally for one table’s use. (You can use it across multiple tables by using “Choice” table/field in the Dictionary entry.) Conversely, and more importantly, it is critical not to use the Choice field type and table for core data. For example, if you have a list of organizational elements that do not fit in a pre-existing core data table, is it far better to create a new table to house these records and making Reference fields to this table. You can make the UI display it as a drop-down so the user will not know the difference. Why is this important? The minute the business needs other data on the organizational element, you can’t do it in the choice table. But you can in a table, and they use dot-walk filtering and reporting to-boot.
- True/False “checkboxes”: When the business tells you there are only two possible options for a new field, it’s natural to lean towards a checkbox true/false (boolean) field to serve the purpose. Think hard about this before you do it. The simple reason is that checkbox type fields are harder for programmers to work with. The better reason is that many times the business will come back with further requirements that necessitate a drop-down selection, or additional fields. In general, unless the requirement is for a flag (think of the active field on Tasks), it’s likely more future-proof to make it a Choice field with two options that can be expanded as needed. Before we leave this, I’ll give you two other things to consider: Using a Yes/No type drop-down selection makes for a better UX in list views (versus the words “true” and “false”), and when the requirements are for several “flag” type fields, consider consolidating them into a single Choice or Reference field. For example, if the business says they want 3 new checkboxes on a Location record for “Main Office”, “Satellite Office” and “Rental Office”, know that this should really be a drop-drop selection called “Office Type”: Main, Satellite or Rental.
- Turn off “Create access controls” creation of a new role on new table creation. This is turned on by default (see “u_sample_table_user” below). There are occasions to create a brand new role, but these are rare. If you want the system to create access controls (ACLs) automatically, use the correct existing role in the reference field on creation. Letting the system create a new role creates :”role chaff”, with lots of unused roles floating around the system. Or worse, you use the role and over time you have dozens or hundreds of roles you need to dole out for correct user access. (I suggest turning off Create module and mobile module unless you need these. You can always add them later.)
Part 1 Conclusion
UI Administration and Table Administration are some of the most fundamental aspects of managing your ServiceNow platform. These are the building blocks for everything else in the system, and the key to user perception. Get these parts right and you’re on the way to a successful ServiceNow journey.
In Part 2 we’ll delve into the coding side of the house, and in Part 3 we’ll discuss security and other platform areas.
