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.  

In Part 1 we covered UI Administration and Table Administration. In Part 2 we delved into everyone’s favorite subject: coding. In this final installment, we’ll cover security aspects and other miscellaneous areas of managing your ServiceNow platform. And at the end we’ll wrap it up with the overarching reasons for all of these considerations.

Security

1. Security belongs in ACLs. Anytime a record needs to be secured for CRUD rights (Create, Read, Update, Delete), it should be done in ACLs. This is the starting point- and I’d argue the ending point –  for all system security. Using other methods – Client Scripts, UI Policies – is not “real” security, it’s security through obfuscation. For example, if a business requirement is to hide a field from a particular set of users, and the administrator does it by using a Client Script GlideForm API call (setDisplay(false)), all this is doing is hiding the field on the form view. The field and the data are still queried from the database and returned to the client. They are accessible in list views, reports, and through integrations and other system-based access methods.
   
   If I had to rank security measures from bad to good, it would look something like this:
   • Client Script/UI Policies: browser side only, not really security
   • Data Policy: applies at the GlideRecord level, meaning within the database record object stored in memory inside of a GlideRecord. Slightly better than Client-only, but not a true security measure
   • Database field read-only: this secures for write access, but only write access, and has no granularity. It’s either on or off.
   • Query Business Rules: this secures data at the SQL level, preventing queries from returning results based on configuration. (More on this next.) 
   • ACLs: These are system security, as intended by ServiceNow. These should be your default security measure in all scenarios. Use the previous methods only in addition to ACLs, if you need it for UI/UX reasons. 
   
   One of the nice things about using ACLs is if a field is not readable to a user based on an ACL, the UI will automatically hide it on forms, lists and reports. So there’s no need to make UI adjustments.
   
   ACLs themselves are a large topic with much to know and learn. This is outside of the scope of this article. There’s plenty of learning available on the internet, like here and here.
   
   
2. Use Query Business Rules if absolutely necessary. As mentioned, Query Business Rules are scripts that run prior to querying the database that essentially add WHERE clauses to the query, limiting the results that come back from the database. These are effectively read ACLs. So why use them instead of a read ACL? There’s only one reason I’m aware of in my 15+ years of doing this: to avoid that pesky little message that someone decided many moons ago to add to the UI letting users know they are getting “hit” with an ACL.
   
   
   Why in 2025 ServiceNow has not found a way, or decided, to make this configurable if it shows or not, is beyond my comprehension. Regardless, because a Query Business Rule will not return the filtered out (WHERE clause) results, users don’t see this message. They just see the total rows returned from the Query. Query Business Rules are used extensively in Customer Service Management, so that external customers don’t see this troublesome little message.
   
   While Query Business Rules are nice from a UI perspective, they are often difficult to troubleshoot. After all, if a row isn’t returned from the database for a particular user, you won’t see it to know. And there isn’t really good debugging available for the rules. You basically have to use trial-and-error with the rule and the query parameters until you get it right. Also, Query Business Rules are strictly at the row level, whereas ACLs can be applied down to the field level.

Other Considerations

Here are other areas of the platform, and developing and configuring for it, where thought and consideration should be used: 

• Notifications: I find that notifications are often an afterthought, both from ServiceNow and in the install base community. We can all agree that we don’t want to be working out of email, but it’s still a reality of our lives. My recommendation here is that you develop a consistent look and feel for notifications going out from ServiceNow. This can mean branding, e.g. branded headers and footers, consistent salutations, bodies and closings, standard font type and size, a consistent strategy for what data to put in an email, and where and how to link to the source record. If you’re a developer and don’t want to be in the writing business, ask the business for the wording. Don’t send out poorly worded or grammatically incorrect emails – it reflects poorly on the platform and the business. It is wise to come up with an overall business strategy for how emails should look and feel and templatize this as much as possible. (And don’t forget to apply this to out of the box notifications that you’re leveraging too!)
• System examples: ServiceNow is a giant database that contains data, code and configuration. When you need to provide a solution to the business that isn’t an obvious configuration, often there are examples in the platform you can leverage. These can range from the mundane to the sophisticated. For example, if I’m building a new UI Action and the correct solution includes verifying a choice from the user before executing the action, I look in out of the box UI Actions for a similar solution. Something more sophisticated than a Javascript pop-up that may be browser-dependent. Much like searching for existing database fields before adding a new one, search the system configurations for example you can use. At the very least, these can be considered an adjunct to what the interwebs may provide, and I would consider them more trustworthy.

Conclusion

It’s easy to consider these guidelines as persnickety and unimportant when taken individually. Often it’s quicker to skip these steps and implement whatever fulfills the requirement; in the short-term no one is the wiser. As someone who has been implementing and maintaining ServiceNow since 2010, I can assure you that skipping this guidance is the platform equivalent of grabbing all the stuff around your house or apartment and throwing it in a closet when guests are coming. Eventually, you’ll need something from that closet, and your day is ruined.



There are two primary reasons to think about, use and enforce these guidelines:

Perception

Users and business stakeholders form their opinions based on “the little things”. Consider the form and UI administration tips: if users see forms with wrapping labels and mismatched cases, and fields all over the place, and inconsistency, and when they go to lists and see duplicate field names and mismatched values, they’re going to think the system is not up to snuff. Sloppiness equates to low quality; perception is reality. You could build the greatest code behind the scenes, but if you don’t pay attention to the little details, users will not care. This is the most important reason for doing these things correctly and with consistency.

Maintenance

Using the closet analogy, when a change is needed to an existing solution, or a fix is needed, having a consistent approach across the platform “keeps a neat closet”. This means building additional features to an existing application or solution in the future, or fixing issues, is quicker and easier. It’s like looking for that favorite board game or puzzle in the closet. Think about finding these when your closet is stacked neatly and things are put in a sensible order, versus digging through piles of unordered things. The simple truth is that an organized, well-built system is easier to maintain than the opposite.

I don’t intend any of what I’ve described as gospel. Rather, my intention is to give those working in ServiceNow food for thought as they build and configure. I consider many of these things to be “the basics”, but I don’t see them in training or documentation. So I hope to get readers to espouse these “rules of thumb” to make both their ServiceNow journey and their platform’s overall health something that is a source of confidence rather than consternation.

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.

In Part 1 we covered UI Administration and Table Administration. In this part we’ll delve into everyone’s favorite subject: coding. And of course when we say “coding”, in ServiceNow we mean scripting in Javascript and the Glide APIs.

Coding

1. Only script (code) when you can’t configure. I’ve written on this topic previously, both how to design for a configurable solution, i.e. code once, configure often, and when you should and shouldn’t code. So we won’t dive deeply into this topic. Suffice it to say the lesson for administrators and developers is when you think about creating a solution in ServiceNow, exhaust all options before you start writing a script. It’s often super easy to just start writing a script that will give you the solution you need, and while it solves the need for a particular requirement, as each solution is developed, you wind up with more and more one-off code, making system maintenance and further development harder and harder.
   
   Quick thoughts:
   • Can you use a UI Policy instead of a Client script?
   • Can you use a Data policy instead of a Client script or Business rule?
   • Can you use a Display Business rule instead of GlideAjax? (more on this below)
   • Can you use a Condition builder instead of a coded Condition?
   • Can you use the Set field value function of a Business rule instead of scripting?
   • Can you build a configuration table instead of writing it all in code?
     
     
   This is just a short list but hopefully gets you thinking in this direction.
   
   
2. Default to building server-side. The very simple reason for this is that things that run server-side run orders of magnitude faster, and far more securely. For the former, you have the beefiest computer at your fingertips, but it is not likely faster than the server with its dozens of processors and dozens of gigabytes of memory. For the latter, processing data on the server is always more secure than sending it “over the wire”, and a server in a data center is always more secure than a laptop in your home or at a coffee shop or airport.
   
   What are some examples of this?
   
   • Using a display Business rule to process logic on the server for a form view of a record, and using the scratchpad to make the data available to Client scripts. (Versus GlideAjax calls to the server.) This of course is if your order of execution supports it.
   • Using a before or after Business rule to process logic on the server “on the way” to the database. Compared to processing it on the client and having the client pass it back to the server.
   
   You’ll need to understand where the different elements of ServiceNow run to be able to fully embrace server-side design. But the key is to always think “can this work on the server” as you design your solutions, and default to building it there if you can.

3. Run your code async where possible. Akin to the previous point, it’s the correct choice to run your code asynchronously whenever possible. In ServiceNow, asynchronous means that the code is placed into a system managed queue to be processed as system resources allow, rather than running the code synchronously as part of a user session that requires the user to wait until processing is complete. Ergo, the user experience is better, and the system is allowed to manage its resources better. As a developer or administrator, you have to know when this is possible. At its most basic level, if the logic you are running does not need to be completed before the database transaction, or does need to be immediately reflected to the user as part of their session, then you can run it asynchronously. Technically, this means using the async value in the When field on Business rules, and events and Script Actions in other cases. (This is a technical approach that is beyond the scope of this article.) At the very least, consider the question: When does your code need to run, and don’t blindly create code elements that run synchronously and release them because they “test OK”.
   
   
4. Consider reusability. Most folks who have scripted in ServiceNow know there are inline scripts that are meant to run as processes are executing – Business rules, Client scripts, Transform scripts, etc., (most scripts are of this type) and standalone scripts that are meant to be called by these inline scripts – Script Includes. As you are developing code-based solutions, consider if the code you are writing could be used or called from other inline processes, and develop it in a Script Include function rather than directly inline.
   
   
5. Add comments tactically. Commenting code tends to either be “not at all” or “more comments than code”, with the former being the most popular. My rule of thumb is to comment in three ways: 
   • Add a block comment at the beginning of functions to note the purpose of the function, the input(s) and the output(s).
   • Add inline comments if you’re writing a block of code that is non-standard or more esoteric than ordinary Javascript
   • If the code is as a result of an Agile Story, or Enhancement, or Bug Fix, or other development tracking record, add a comment noting the record number. It helps other developers backtrack why the code exists.
   
   
6. Keep your logs clean. A common trait I see on customers’ instances are busy and messy logs. As I’ve mentioned, ServiceNow itself is as guilty as anyone for this: “out of the box” instance logs are pretty massive. But it’s also true that developers add logging in their DEV instances for troubleshooting and do not turn it off before moving to PROD.
   
   A good rule of thumb is to take one of two approaches: Either have the last step you do before closing out an update set be to review all the code in that update set and comment out the logging, or, as a more robust solution, add a system property the application that can turn logging on and off, and wrap your logging statements inside an IF check on that property. There are many out of the box examples of ServiceNow doing this.
   
   The obvious reason to do this is the processing and storage logging takes up. But the more important reason is that when you are troubleshooting issues in your instance, having to fight through extraneous log statements to get to the ones that help identify the root cause can be time consuming and frustrating.

Part 2 Conclusion

Despite the marketing claims to the contrary, anyone who’s worked with ServiceNow for more than a moment knows that you cannot really create anything bespoke without some scripting. But anyone who’s been around multiple customer instances also knows that scripting can get out of control quickly – making the system harder to maintain, fix, and create new solutions on top of. Keep the fundamentals in mind and you can at least keep the damage to a minimum.

In Part 3 we’ll discuss security and other platform areas, and draw some larger conclusions.

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).

1. 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!
2. 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.)
3. 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.
4. 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

1. 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.
2. 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.
3. 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.
4. 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.

Introduction

Unless you’re brand new to the ServiceNow ecosystem or have completely ignored all talk and literature about the platform in recent years, you’ve heard the drumbeat of a couple of key messages (that I’ll paraphrase):

1. Low and no code solutions are the future
2. Stay “Out of the Box” as much as possible

Out of the gate, the question I’ll pose is: does low code / no code matter? If so, why does it matter? In this article, I’m going to present an analysis of when to and when not to code, for the ease of build and maintenance of your ServiceNow platform. And – spoiler alert – the answer is not as simple as “code is bad, low/no code is good”.

Low code and no code solutions are some of the buzziest IT terms in recent years.  I suppose the idea behind these is that non-coders can “develop” solutions on a platform without having to write lines of code. (In reality, the platform is giving them a GUI that writes the code for them behind the scenes.)  I’m not going to delve into whether I think this is a good idea – I’ve already covered many of the arguments in a previous article. Instead, I’m going to go into the decision-making process for those who can code: when should you code, when should you avoid coding, and what is the correct balance. And of course this is all with the context of ServiceNow.

The article presupposes that almost every ServiceNow “shop” – an organization’s ServiceNow staff – has admins and/or developers that know how to write code* working on their implementations. I have not found many companies that do not – at the very least they have a partner or contractors who do. At the same time, I have also found that many folks implementing on ServiceNow, particularly those with a software development background, tend to overcode their solutions. In other words, they tend to write code until the requirement is met or the problem solved. And keep writing code, and keep writing code… And the reality is that a lot of solutions can be implemented by writing code. It’s just one way the system can be made to work. (Frankly, a lot of the new ServiceNow created solutions released in the platform are overly coded. Have you ever attempted to stack trace through a ServiceNow-created implementation of a UI Action condition or an ACL that calls a Script Include? That calls another Script Include. That extends another Script Include. It’s enough to make you bang your head against the desk.)

Like most things in life, there is a happy medium to be reached. I’ll use the rest of this article to elucidate some strategies and examples for how to achieve a balance, and hopefully get you thinking. (For recommendations on how to create code once, configure often solutions, see this article where I delve into specific examples.)

When Not to Code

• When a ServiceNow UI element will do the same thing:
  • Using a condition builder instead of a condition code string
  • Using a UI Policy instead of a Client Script
  • Using a simple Workflow or Flow activity instead of a large code block
• When the customer does not have developers supporting the platform, or admins who can at least manage a code-based solution
  • Of course this is case-by-case – certain custom solutions simply cannot be implemented without some coding
• When you are not prepared to create design documentation for your code-based solution
  • If you are creating a solution that implements various code elements, draw the picture of how it works together. (ServiceNow should be serving 8-10 years for a lack of this!)

When to Code

• When your company has a ServiceNow team knowledgeable in and able to support code-based solutions
  • This can be full-time employees, contractors or a long-term partner. Regardless, it implies you have people who are working on or around your platform that fundamentally understand it, and are engaged long-term.
• When building a Flow or Workflow to support the same solution will require orders of magnitude more activities, configuration and time to implement
  • This is a key one: in my experience, if you’ve got ServiceNow people who understand both configuring and developing ServiceNow, often it’s far quicker and easier to write and maintain a few lines of code than configure and test through a UI interface like Flow Designer. You don’t need to use Flow Designer just because ServiceNow says so.
• When your solution is well-documented so that future developers can easily understand how it works without having to reverse engineer your code
  • In the words of Nike, just do it.
• When the business requirement is critical or at least very beneficial and there is no other way to implement it in ServiceNow
  • The key here is there is no other way to do it, or at least not a realistic other way to do it.

An Example

There are many examples I can cite but I’ve found the most common is creating integrations. There’s been a big push to use pre-built integrations using Integration Hub or approved 3rd party apps. Like a lot of these situations, this is great if your integration requirement aligns perfectly with how the integration has been pre-built and configured. But for the purposes of illustration, let’s assume it doesn’t. (I’m smiling as I type this because I’ve yet to see one that does!)

In this situation, you have two choices:

• Create a Flow-based integration using dozens of activities and complicated logic blocks, attempting to overcome the linear nature of the tool. Potentially struggle where to configure certain parameters, and how to successfully test.
• Create an inbound or outbound REST message, write a few lines of code in a Business Rule and Script Include, and add logging for testing and debugging.

I’ve never seen a non-developer implement an integration by themselves. Not once. So given that this is highly likely to be done by a developer, the reality of this situation is that the developer is more likely to be able to review API documentation and implement through a combo of code and configuration solutions than use a UI tool that obfuscates the code but is harder to understand for the developer. And in my experience, I can develop and deploy an integration a minimum of 3x faster by avoiding using a no-code solution.

Conclusion

A common thread through many of the articles I write is “don’t believe the hype”. This is no exception. As non-technical and unscientific people breathlessly espouse the tremendous benefits of low and no-code solutions, and citizen development, I constantly weigh this against what I see and experience “in real life”. And what I see and experience does not align with the marketing pitch.

Conversely, I also see over-coded solutions all the time, not the least of which is ServiceNow’s own out-of-the-box solutions. And I’m most definitely not espousing these either. As with many things in ServiceNow, this balance is as much art as it is science. I simply can’t give you a definitive list or decision matrix when to code and not to code. It takes knowledge, intelligence and experience. But hopefully I’ve given you some ways to think about it.

Happy developing!

*specifically writing Javascript and using the ServiceNow Glide APIs

“Thinking about design is hard, but not thinking about it can be disastrous.” – Ralph Caplan

Introduction

For almost 14 years in the ServiceNow space, and across a rapid expansion of the exosystem, it has been interesting to observe and analyze various organization’s approaches to developing and maintaining their ServiceNow environment. Specifically, how do organizations manage the inflow of business needs, the distribution and velocity of development, configuration and administrative work, and the ongoing maintenance of the platform? As the footprint of ServiceNow has expanded conjunctionally with the expansion of the business functions the platform supports, I increasingly see divergence in these strategies. I’m writing this article to articulate these strategies and provide my view of how each succeeds and fails, along with my recommendations for the correct strategy given a company’s view of ServiceNow.

Management Approaches

There really are two ends of the spectrum for how ServiceNow environments are managed. At one end is the idealized view and what ServiceNow itself espouses: Use of Idea and Demand Management to receive and vet business requirements, an oversight board – which ServiceNow calls a “Center of Excellence” – who does the vetting and prioritization of these requirements, Agile and PPM to manage the development work to fulfill these requirements, and an operational organization that handles release management, break/fix work, upgrades, and performance and security of the platform. If you’ve got your thinking cap on while reading this, you’ll quickly sense that this is intended and works best in the largest ServiceNow implementations, where the platform is a large part of an overall enterprise strategy for a company.

The other end of the spectrum stems largely from traditional IT functions; that is, a purely operational model and mindset where all development is treated as one-off break/fix/enhance type work. Where “keep the lights on” is the primary and sometimes only strategy. In these organizations, ServiceNow development work is typically handled through Incident and/or Enhancement processes, and each task is designed, developed and released “in a silo”, usually without thought to larger strategic initiatives. In other words, the view of the development does not extend beyond the scope of the need elucidated.

With a 25 year career in IT, I’m certainly aware of and sympathetic to this mindset. I find it particularly prevalent in MSP or MSP-like organizations. It’s not that the people running these organizations intend to be “unstrategic” (not a word), it’s what they know. These mindsets are built over years and decades of running IT as an operational entity.

There is a cost to doing business this way – and this is the crux of this article. When you implement under an operational mindset, you necessarily build everything as one-off. Critically, there are no design or architecture considerations taken into account, which means there are concerns for platform maintenance, stability, health and optimization. These can range from the simplest quirks like inconsistent forms and fields, and re-creations of code logic, to large-scale issues with performance and user experience.

Examples

Here are some specific examples of development done without design or architecture prior to “hands-on” work:

• A developer customizes an out of box ServiceNow application when a custom application would have served the requirement better. This leads to upgrade issues.
• A developer builds a security requirement using client-side functionality, which is pseudo-security. This security hole is exposed when using integrations and server-side functionality to the same data.
• A series of requirements for a single application are developed as one-offs. After these are implemented, the UI/UX experience is compromised, as now the form design is cluttered and out of sync with other applications. Adding UI logic and many related lists hinders the performance of form loads.
• One developer uses Workflow, another Flow Designer, another a series of Business Rules, and another a series of Glide Ajax client scripts, all to implement similar requirements. Maintenance becomes hyper complex as each change or fix is a one-off “head scratcher”; “Now where is this functionality??”

I can argue that Agile is a contributor to this problem. Not the methodology itself, but the incomplete usage of the methodology. I often see organizations going no further than Stories to manage their work. While Stories done correctly are ideal for “state the business requirement, not the technical how” of documentation, without using Epics to group requirements into a cohesive release, and more importantly, without architectural design overseeing the Epic, the Stories are developed in silos and lead to the issues noted above.

Best Practice

In my experience, the best practice is to have an architectural or design review of all requirements prior to development. Some may only need a cursory review to confirm it can be built as a one-off. Others may need a directed technical approach because there are several ways it could be built, and a consistent approach platform-wide is best for long term maintainability. And some may need a complete analysis of pros and cons, buy versus build, custom application versus out-of-box in order to build the right solution for the business need and the platform sustainability.

I’ve included a diagram below that shows the “idealized” process flow, including a Center of Excellence that fulfills this function:

The concept of a Center of Excellence, or at least some level of architectural oversight, is not meant to be onerous or a process bottleneck. This is a common concern organizations have, and a reason they don’t do it. My argument is that the operational sweet spot for such a function lies somewhere in the middle of the spectrum: Organizations are free to be as fast and independent with business requirements as they choose. The oversight part of the process is a simple architectural design review of all Stories (requirements) prior to development, with the end result a proper technical approach to development. A good architect will quickly recognize when there are multiple approaches to implement a requirement and provide guidance on the correct approach, taking into consideration all aspects mentioned previously. If the Agile methodology is being used, this can be part of the grooming process.

The diagram above is one I drew for where the Center of Excellence lives in the overall development process, between the requirements gathering, and the execution, either as operational one-offs or as larger project-type initiatives.

ServiceNow’s Documentation on Center of Excellence

In the end, it comes down to an organizational decision, even if not made consciously: “Do we spend the time up front to ensure things are developed in a cohesive platform strategy way, or do we dedicate more time, money and resources to fixing issues when they (inevitably) rise in Production?”  The simple analogy is working to prevent forest fires, or dedicating resources to fighting forest fires.

It’s been a few years since I wrote Part 1 of this article, going through the history and evolution of the ServiceNow platform, and the morphing of the company strategy from platform to product. After working with multiple clients in the meantime, and reading lots of new marketing and going through many platform release upgrades, I thought it time to revisit the subject with new perspective and analysis.

A quick recap: In the early 2000s, ServiceNow (nee “Glide”) was envisioned and built as an extensible business workflow platform, designed to replace paper and manual processes, but without a defined business application built-in. The idea was that businesses would analyze their own processes and automate using the platform components. Once this didn’t catch on, the SN founders built an application suite on top of the platform using what they knew – ITSM. This caught on, and in the subsequent years both customers and ServiceNow have used the extensibility of the platform to build and solve countless business processes problems. As ServiceNow itself has gone public and had multiple leadership changes, the company has shifted development, sales and marketing focus to products it builds on top of its own platform. This is why most discussions around new releases are around Products, and not platform enhancements.

While this all may be natural progression for a company that goes public and has to answer to the markets and short-term financial interests, it poses some issues for those attempting to use ServiceNow as a platform rather than a series of products.

Buy versus Build

In the early days of ServiceNow, the process for implementing a business process solution was generally straightforward (other than specific ITSM processes, which were built in). As a consultant, you would listen to the business problem that needed solving, then design and implement a custom* solution using the platform components provided (see Part 1 for more detail). There wasn’t a longer discussion or decision required for build versus buy, since the platform was designed to be built upon. ServiceNow provided the components to build the tools (applications) to solve business problems, and the licensing was based on fulfiller versus requester. There was no further buy versus build decision to be made.

*NOTE: Although this could spawn an entirely separate discussion, I want to point out that in the ServiceNow world, “custom” is not a bad word, though it is often seen as such.  In reality, building a new application using the platform components ServiceNow provides is doing exactly as the founders intended.  It is also not really “custom” in the true sense of the word. It is simply a new way of using the components provided.

Simplification by Obfuscation?

The nature of strategizing control over flexibility means you take the power of the platform out of the hands of those who are best equipped to take advantage of it. This has been true long before ServiceNow and will continue to be true long after, but I believe it is exacerbated in the ServiceNow space by the factors previously mentioned: market forces, management changes, market strategies, misinformation and misconstrued information. Over the years as ServiceNow has moved from a ticketing system to a strategic platform for companies, I’ve watched as C-level executives have injected common phrases like “stay out of the box” and “minimize upgrade efforts” into the lexicon. I can only assume these come from history with other platforms and reading industry studies, rather than from deep knowledge of what this really means for their ServiceNow implementation. I also assume because those who are making the financial decisions are saying these things, that they become both gospel and strategy for those who have a vested interest in their decision-making.

I liken what ServiceNow has done to the platform to using WordPress for website development, rather than DreamWeaver. The latter is a framework that gives you pre-built components that experienced developers can use to build custom websites faster. The former is more for non-developers to implement fully pre-built websites with a small to moderate ability to make configuration changes. But for an experienced website developer in certain circumstances working with WordPress can be more challenging because things that could easily be modified in CSS aren’t always accessible. In this way, WordPress makes it easy to deploy a website that fits their model, but makes it far more difficult to make what are often necessary changes after the fact.

Business Example:

Here’s an example of what I’ve been describing:

Business Requirement: A need to manage company events such as luncheons, meetings and guest visits. The company wants to use their ServiceNow investment and the platform tasking and workflows to do so.

Platform Solution: A ServiceNow architect uses the Task application model to extend to a new Task Type called “Event”, creates a Record Producer to intake customer needs (available in the Service Catalog), builds sub-tasking records and initiates them with a workflow based on state changes to the parent Event. Form and list views, notifications and reports are configured to meet business needs. Security for the new application is layered on as needed. Any specific business requirement can be implemented without concern for “breaking” out of box solutions, and is completely upgrade-proof (ServiceNow doesn’t care about net new applications and components – they are completely ignored in upgrades).

“Out of the Box” Solution: The customer ServiceNow team is told to stay “out of the box” and so attempts to build the solution in Service Request with a Catalog Item for intake. The Event data takes the form of many variables on the Requested Item. The workflow is driven off of variables, and Catalog Tasks are initiated by the workflow. The ServiceNow team has to customize the Request and Task forms for Event needs, creating maintenance issues – the application looks and functions one way for “normal” Service Requests, and a different way for Event Requests. Forms, lists, reports, notifications, security are all doubled with mutually exclusive conditions. Subsequent implementations like this use case in Service Request further complicate the configurations and maintenance.

Product Solution: A ServiceNow Account Manager hears “buzzwords” from the customer regarding their business needs and finds an out of the box product to license them. The customer installs the new product and demos for the business. Stakeholders find that the product only partially aligns with their needs. The business has to make a decision to either customize the ServiceNow product for their needs, or go through a rigorous and costly OCM cycle to change the way their business works to fit the ServiceNow product. If choosing the former, the company loses the ongoing maintenance benefits of staying “out of the box”, while still paying new licensing charges. Anyone who has worked in corporations knows the latter requires an incredible sales job to accomplish – businesses DO NOT like to change!

If you’re intuiting the conclusion I’m reaching with this example, you realize the irony is that what most would call the “custom” solution is actually the solution with the least development friction, the least technical debt, and the least upgrade concerns.

Conclusion

We’ve reached a concerning level of misinformation and mischaracterization of design and development decisions as ServiceNow has changed both their platform focus and marketing strategy. But what ServiceNow cannot change is the fundamental nature of the platform any product they build and market is based upon. Those architects and developers who truly understand this fundamental nature are much better equipped to deliver real value to their customers via shorter development cycles, maintainability, and upgradeability. Remember: “custom” is not a bad word!

eBonding Design Considerations and Good Practices

As mentioned previously, the example I’m working from is a bi-directional application to application integration, meaning that the systems are integrating application records throughout the lifecycle of that application’s workflow. For example, an Incident in system X that integrates with a ServiceNow Incident and exchanges updates throughout the life of both incidents, regardless of who has ownership of the resolution. Many know this concept as “eBonding”. Simply put, this is integration of both data and process, where what data is exchanged, and when, are as a result of process and may also influence process.

The technical designs I’ve outlined above work very well for eBonding, and are in fact designed to work with this practice. In addition to the technical aspects, here are other considerations when designing an integration solution for eBonding:

• Both systems have to agree on the field mappings and data types. (No different than any other integration.)
• Both systems have to agree when mapped fields can be updated. This is especially important for things like the ServiceNow “state” field, which either controls or is controlled by workflow. In our Incident example, often the only states that are allowed to be set by the integration are canceled or resolved. Other states may change in the other system but aren’t automatically updated by the integration as it may affect workflows, SLAs, etc. Rather, information may be included in a work note so each system is aware of activity in the other, but the process is not potentially adversely affected by it.
• The integration needs to include mapping translations for field values that don’t match in usage across the systems. For example, if ServiceNow uses Priorities 1-4 and System X uses Severity 1-10, you’ll need to create a mapping matrix to map System X’s Severities into ServiceNow’s Priorities, and vice versa. (Also consider States, Categories, etc.)
• You’ll need to consider how Reference fields get populated and integrated, but I’ll discuss that more in the Good Practice Tips.

I’m including diagrams from the AT&T Incident eBonding I built for ServiceNow below. It details the integration flow for two scenarios: A “Proactive” incident initiated by AT&T, and a “Reactive” incident sent to AT&T. In both scenarios AT&T is the owner of the incident – responsible for the resolution, as the use case is AT&T owns the customer’s network and in the incident is network related.

Note the listing of updateable fields, and when, as well as uni and bidirectional flows of data.

The keys to a successful eBonding integration are the discussion of, and agreement on, the data what and when that will flow between the systems, and the rigorous test planning and testing of all lifecycle scenarios. These are vital to ensure you don’t break existing internal processes already developed and running in your ServiceNow environment.

Other Good Practice Tips

In addition to the primary design considerations outlined above, I recommend the following:

• While security is of the utmost importance, and is often the thing customers think about first, try to design and build your integration without the security layer, or use the most basic security possible. This allows you to prove out the design and confirm the connectivity first, and assumes you have sub-production environments to develop and test in. Security can almost always be layered in as a second step. This eliminates a layer to troubleshoot as you iterate your development.
• You’ll need to consider and account for integrating ServiceNow Reference fields *. As you know, these are fields that are stored as sys_ids in the integrating ServiceNow record, which is not likely to mean anything to the external system. Here are some guidelines for integrating Reference fields:
  • Consider if there is value in having the Reference data tables stored and maintained wholly in each system, so each is aware of the full dataset and mapping is an easier exercise. (There good reasons to do this, and reasons it’s often either impossible or a bad idea.)
  • Ensure that both systems have a field that uniquely identifies the reference in both systems. For example, for users records, email address may suffice.
  • Ensure that field data is included in the bidirectional payloads
  • Use the “Reference value field name” in your Web Service Import Set Transform Map Entry to use this field to choose the right ServiceNow reference record (using our out of box functionality again!)
  • Set up your Outbound Field Mapper to map the ServiceNow field to System X field, so that the external system doesn’t get the sys_id
  • And for goodness sake don’t try to use display value strings as unique identifiers!
• I suspect integrations that don’t use REST (or even SOAP) could use the same approach I’ve outlined. Even a file-based export could work the same, save for the nature of the outbound and/or inbound payloads.
• Wherever possible, the outbound integrations from ServiceNow should be run asynchronously. This is a general good practice with all integrations. For example, if the integration is triggered via a Business Rule, the Business Rule should be set to async if at all possible. This way the end user and the system (UI) do not wait on the integration to move forward, and the integration runs as system resources are available to it. The exception is if there is a business requirement for the system to wait on the integration, e.g. the end user is expecting to get a result back from the external system before proceeding. There are also technical reasons this can be a challenge: For example, you cannot run an async Business Rule on a comment or work note addition.
• Only use a Scripted Web Service if the inbound payload will not be in a name:value format that can easily map into a staging table, and rather requires scripting logic to manage the payload before injecting it into a ServiceNow record. Consider this a “last resort” in most cases.

Some of these points could warrant their own article; hopefully this article triggers your design thoughts and gives you ideas about how to manage your integrations.

Conclusion

Since its early days ServiceNow has had integration technologies built into, and fundamental to, the platform. Many a system has been integrated into ServiceNow in all shapes and flavors. While all kinds of new tools inside and outside of ServiceNow have attempted to simplify integrations, the “good old” ways still work when no other options exist (or existing options don’t quite fit the bill).

Captain: You can have the easy way, Luke… Or you can have it the hard way… It’s all up to you. – Cool Hand Luke

If you work in a ServiceNow environment in 2023, it’s more than likely you’ve got it integrated with other systems. Given ServiceNow’s place in the market, it’s unlikely that an instance is running in an environment small enough or segregated enough to not need to be integrated with other systems. At the very least, you’re likely getting your core data from somewhere outside of ServiceNow, and hopefully not through a manual import. (Who wants to keep up with that effort?) You may be using a “good old” LDAP integration, or you may be using middleware, or an Integration Hub pre-built solution. Regardless of the solution, I’m going to use the rest of this article to talk about good practices for how integrations should be designed in ServiceNow so that your applications, and indeed the platform as a whole, are protected from possible integration chaff, and so they can be easily extended by non-coders when the need arises. I’ll primarily cover custom Web Service integrations, with the intention that if you understand how to design these kinds of integrations the knowledge translates well to all integrations.

In Part 1 of this article, I’ll delve into Inbound and Outbound design considerations, and in Part 2, I’ll cover considerations for a true eBonding type integration as well as other general tips I’ve learned through the years building integrations.

A quick bit of “curriculum vitae” to establish my bona-fides: I’ve been doing ServiceNow integrations since 2011; I was one of the early ServiceNow Professional Services consultants to delve into integration work. I developed one of the first AT&T eBonding integrations and gave the code and configuration to ServiceNow development to leverage as a packaged offering. I also built the ServiceNow side of the Workday to ServiceNow connector for Workday (the company). I’ve focused primarily on SOAP (early on) and REST based Web Service integrations. I also helped build the first iteration of the Perspectium DataSync tool.

Baseline Knowledge

This article assumes the reader has a baseline knowledge of how to do integrations, both in general and in ServiceNow. It also assumes you have knowledge of the various ways that ServiceNow does, or can do, integrations “out of the box”.

The examples in this article are based on Diagram 1. The example is a bi-directional application to application integration and includes the following:

• The REST protocol with JSON payloads
• A Web Service Import Set to stage the inbound data
• An integration with a Task-based application in ServiceNow
• A field mapping table to manage inbound and outbound data updates

Inbound: Default to Using a Staging Table

You should always default to staging the inbound data in Web Service Import Sets (WSIS). These are nothing more than Import Set tables with a slightly extended API. (I’ve honestly never needed anything more than the standard API calls when using these tables.) Here are the reasons these tables should be the place to integrate into ServiceNow:

• Staging the data insulates your application tables from data issues with inbound integrations. This allows you to build both data and logic safeguards into your integration. External systems can use the WSIS Table APIs to inject data into ServiceNow, where it waits to be transformed into application or core-specific data. Transform logic can ensure that bad or malformed data doesn’t make its way into your SN processes, preventing potential SN instance issues.
• Staged data in WSIS can be transformed like any import set. This means SN administrators who may not be familiar with Web Services or integration design in general can still configure transform maps and transform logic. Many of the future changes to the integration can be handled by anyone who can maintain transform maps.
• Staged data can be used for troubleshooting integration issues: If there’s an issue with the integration after the inbound request has reached ServiceNow, the import set record serves as an auditable trace of the raw data received. Often issues can be solved by a review of this data, e.g “Hey we agreed you’d send the data in format YYYY-MM-DD and you sent MM-DD-YY.” Clever developers will set up ways to store raw JSON payloads and integration messages (errors etc) in the Import Set record.

Things to note with this approach:

• For most situations, you’ll need to ensure the integrating system receives the unique identifier of the record created by the transform, not the import set record. Recent versions of ServiceNow’s Import Set API appear to do this inherently in the JSON response.
• The import set will need to be set up not to use the default ServiceNow system delete property of 7 days if you want to be able to trace issues older than this.

ServiceNow documentation can show you how to achieve both of these.

For folks reading this who have become skeptical because Integration Hub doesn’t take this approach, I learned this approach from ServiceNow employee #1 (those who know, know). My standard tact is to believe those who created the platform over “johnny come latelies”.

Outbound: Create Extensible Field Mappers Instead of Writing Code

While WSIS are standard ServiceNow functionality, this recommendation is my good practice, and one I’ve espoused for all platform development. The goal is to build solutions that write code once, and build configurations that are extendable for future changes – ones that can be managed by non-coders. Think of it like a custom Transform Map for your integration. In the diagram above, this is the “X Request Map” at the middle bottom. In its simplest form, the table contains the following:

1. The table and field of the application in ServiceNow
2. The table and field of the integrating system
3. The nature of the integration: Inbound, Outbound or Bidirectional
4. An active flag

For #1, you can use the Table Name and Field Name dictionary field types. (The latter is dependent on the former; e.g. choose the Field from the Table selected) (Dictionary types).

Numbers 1 and 2 tell the integration the tables and fields from both systems map to each other. Conceptually, exactly like a Transform map, although one of the table\field combinations in this case is from the external, integrating system. Number 3 is a choice drop-down with options for Inbound, Outbound, and Bi-directional. Finally, an Active flag (Number 4) tells the integration is this a mapping that is currently used.

In Diagram 1, the bottom right side of the image shows how and where this is used. In many integrations I’ve seen, the creation of an outbound request from ServiceNow is done with pure code: the payload is built out via code, and changing the payload requires changed code. My suggested approach is to use Business Rules to trigger the request – when an update to an integrated record occurs, trigger the initiation of an outbound request. I use a Script Include function to build the request, so that it can be called from multiple places. Most importantly, I use the mapping table to determine what fields should be sent, and the field names to get the values from the ServiceNow record. The process flow is:

1. The integrated ServiceNow record is updated
2. A Business Rule running on that record’s table determines if the update needs to trigger the outbound integration
3. The Business Rule code calls a Script Include function, passing it the current GlideRecord
4. The Script Include function queries the mapping table, filtering on active, type=outbound, table is the current table
5. The Script Include function loops through the result, pulling the values for the external system fields and the GlideRecord field values, building an outbound name:value pair payload
6. The Script Include function triggers an outbound REST message and attaches the payload
7. The Script Include function processes the response as desired

Important Note: Wherever possible, the Business Rules should be run async. There is more on this in part 2.

If this is built correctly, the major benefit is that future updates to the integration can be completed with updates to the Mapping table, rather than with code. A true low-code, no-code solution!

More to come in Part 2.

“Continuous improvement is not about the things you do well — that’s work. Continuous improvement is about removing the things that get in the way of your work. The headaches, the things that slow you down, that’s what continuous improvement is all about.” – Bruce Hamilton

I’ve written previously about the power of the platform, and my belief in its terrific original design and flexibility. In recent years, in its push to create and sell products, ServiceNow has sacrificed enhancements to the platform which us architects, developers and admins have to work around and explain to our customers. In this article, I’ll discuss some of the enhancements I wish ServiceNow would implement now (and in some cases should have done long ago). While selfishly these would make my life and the lives of people who manage and work on ServiceNow easier, these are also features that will keep ServiceNow ahead of, or at least apace of, the competition. And let’s not overstate our selfishness – some of these are great for requesters and customers too.

Rich-text / HTML Comments and Work Notes

We don’t live in a plain text world any more. … ServiceNow should enhance Comments and Word notes fields to support rich text and HTML formatting. One of the important outcomes of having this feature is the ability to include inline images and marked up text, so that agents and customers can exchange examples in order to resolve issues more expediently. Consider any IT firm who is troubleshooting a customer issue via Customer Service Management. The ability for both the customer and the support agent to supply screenshots with text and arrows to explain the exact issue or fix is far easier to communicate and comprehend than a plain text explanation (“a picture is worth 1000 words”), or a text description of an attachment that don’t live together in the UI. This method is cumbersome and unintuitive. Additionally, the rich text / HTML notes can go out and be received via email – the bane of our existence but fundamental part of how “business is done” no matter how much we fight it or come up with alternatives. (I don’t know of any email system that doesn’t support this formatting.) Regardless of whether the customer is viewing these marked up notes in the Service Portal or via email, their experience is enhanced, and in best cases, their issue can be resolved faster.

Editable Comments and Work Notes

I’ll include this as a sub-header under the enhanced notes banner. If we’re going to make comments and work notes rich, let’s go ahead and make them editable after saving in select cases and to select people. I say the latter part because if an agent has entered an Additional comment and the system has informed the customer of the comment via email, it’s likely a bad idea to turn around and edit that note. However, there are plenty of cases where the ability to edit a Work note is useful, and sometimes security reasons why (someone has put a password in plain text in a note). I haven’t devised a hard and fast rule of what should be editable when and by whom; let’s start with the functionality and figure it out from there.

Enhanced Attachments

Attachment functionality has been basic since the platform originated: Users with write access to any record in the system can attach files to that record and users with read access can view those files. There isn’t much functionality beyond this other than the ability to add all the attachments to all instances of an outbound email notification.

Customers have been asking for years for additional functionality around attachments:

• Classifying attachments as internal (fulfillers or employees) and external (requesters or customers), much like Comments and Work notes
• Specifying more complex security around each attachment on a record
• Choosing particular attachment(s) to send with an email notification (in real-time)

I’m sure there are others but the point is made. Getting into the weeds on how attachments are stored in ServiceNow is a discussion beyond this article. Suffice it to say there is a great demand for greater flexibility around the classification and security of attachments, beyond “this attachment belongs to this record”.

Requested by and for at the Task* Level

*Assumes you understand the Task table hierarchy and inheritance.

This is one of the most common customizations implementers have been doing as long as I’ve worked on ServiceNow. The basic thesis is this: For every Task (every Task), the system should be able to record, track and report on who requested the work, and who it’s requested for. This seems so simple. I think the lack of this in the platform is residue from the early days when ServiceNow was primarily just an ITSM system, and as such, they put a Caller field on Incident, a “Requested by” on Change, a “Requested for” on Service Request, and then didn’t think past it. In subsequent applications, they added “Requested for” or “Requested by” on certain applications, but it’s not consistent across the platform.

(Some may say “what about the ‘Opened by’ field on Task?”. While it’s great that this field exists at the Task level, consider this: An administrative assistant calls in a request to the Service Desk for something for his CEO boss. The Service Desk opens the Request. In this case, the “Requested by” is the admin assistant, the “Requested for” is the CEO, and the “Opened by” is the Service Desk agent. I think this field is needed and serves a distinct purpose to the others.)

To this end, I’ve worked on many implementations and have often recommended these fields be added to the Task table and they are used as the defacto values on all Task forms, lists, reports, etc. In addition to having a consistent approach and data/field structure on all Tasks (work being performed), it also enhances reporting at the Task level, and can be used to report on organizational performance: How many requests is IT delivering to HR? And vice versa? Having your requesters and assignees all at the Task level, along with good core data, allows you to take your Service Management to the next level. But this should not fall on implementers to customize; ServiceNow should fix the platform so it’s “out of the box” this way.

More Granular Log Timestamps

This is a feature purely for admins and developers. Because the platform timestamps on all records in the Created (sys_created_on) and Updated (sys_updated_on) are granular only down to the second, it’s often hard to troubleshoot the order of processing execution. After all, many of these executions are happening at the millisecond level. For example, if you’re troubleshooting a complex script with lots of logging, when you view the Script Logs or the more general Platform Logs, because you can only sort down to the second, you can’t see exactly the order of your logging. Of course you can number your log statements, but you lose the order of other logging that may be occurring outside of your explicit statements. This is important when other things in the system may be impacting your code. In an ideal world, at least for logging, you could see the exact order of execution. Indeed, this was possible when I was working at ServiceNow and could elevate to maint access on the platform (access above admin only available to ServiceNow employees), and I can tell you from experience it made my troubleshooting much easier.

I’ll hedge my statements by saying this is only really necessary for logging – Task-based work and other auditing is typically fine at the hours:minutes:seconds level.

Other Quick Hits

Here are a few others that I’ve addressed in other articles or will be in the future:

• Complete Catalog Variable redesign (aka “Variables are the worst”)
• Upgrade Workflows or fix Flow designer to have a GUI approach like Workflow
• Stop creating so many scopes – how about 1 per application?
• Fix the out of box State model once and for all
• Create out of the box solutions that are less code-heavy, aka Drink your own “low code” Kool-aid. None of us want to try and troubleshoot by looking through dozens of undocumented function calls!

Conclusion

I’ve written about some of the most common areas of concern for customers, things I’ve learned from 13 years of ServiceNow implementation. There’s still plenty of power in the platform – it’s why many of us started working with ServiceNow and what keeps us evangelizing about its power. The ask is simple: ServiceNow should solicit feedback from its most experienced implementers, honing in on the most common platform concerns that birth customizations of all shapes and sizes, and devote some of their massive development resources to these changes and enhancements. I’m sure this can be done in parallel with licensed application development. So do it, and keep this platform great!

“A tree with a rotten core cannot stand.” — Aleksandr Solzhenitsyn

In the fitness world, and in fact the physical human world, your core is the central part of your body. It includes the pelvis, lower back, hips and stomach. Exercises that build core strength lead to better balance and steadiness, also called stability. Stability is important whether you’re on the playing field or doing regular activities. In fact, most sports and other physical activities depend on stable core muscles.

As ServiceNow has moved further towards being a product company and less a platform company, it’s easy to lose sight of the aspects of the system that are core to its functionality and its value. If you’re solely focused on products*, it’s akin to building big arms and shoulders, and large calves and thighs, but ignoring your back, abs and glutes. Eventually you’ll be a Popeye-ish figure, unable to balance because you’re both disproportionate and “weak in the middle”. In this article, we’ll discuss what’s core to ServiceNow, what benefits having a good core provides, and how to build and maintain this core.

*Products, or Applications and Application Suites, are things like ITSM, CSM, HRSM, ITBM, ITOM, and their components. These are the things ServiceNow builds, markets and licenses on top of the core platform.

What is the ServiceNow Core?

There are several aspects to the core platform. I’ve highlighted some of these in a previous post, primarily the development components that make up all the applications. In this post, I’m going to focus on the core data which in the least drives consolidated reporting, and as I’ll elucidate later, the best gives a full insight into how your business is running.

From a data perspective, the core data are the tables that can be seen in the Organization application in the left navigation menu.

The main tables are:

• Companies
• Departments
• Locations
• Business Units
• Cost Centers
• Users
• Groups

Note: Vendors and Manufacturers are Companies with particular attributes, not unique tables.

If you look at the schema map for any of these tables, you’ll see how many tables reference these records. For example, the Department table is referenced 746 times in my largely out-of-the-box PDI. Most of these are the CMDB, and indeed, it is hard to use the schema visualization ServiceNow provides because of the number of CMDB tables it needs to draw to represent the schema. If you look at the dictionary references to Department, there are still 36 entries.

However this is just part of the usage of this data. Consider the dot-walking use cases for Department. (If you don’t understand what dot-walking means, please refer to ServiceNow documentation.) Since Department is a field on User record, everywhere a User reference exists, Department can be used by dot-walking to it. Looking at the dictionary references to User, in my PDI there are 784 non-CMDB fields across the platform. So this is 784 places you can inherently filter on or group by Department by dot-walking from the User reference field.

Because the in-platform schema is overwhelmed by the CMDB, I drew a diagram of just how these core tables tie together:

Note: Depending on your organization, you may not need all these tables populated. Smaller organizations may not distinguish between Departments, Business Units and Cost Centers.

Building and Maintaining Your Core

Experienced system administrators and ServiceNow developers are familiar with these tables and this data. What I’ve often found is there’s an effort during the initial implementation to populate the required tables, then the maintenance is lacking and data becomes stale or messy.

Here are some common examples:

• The data is imported once and either an integration or an ongoing process for maintaining the data isn’t implemented
• The company does a re-organization and user departments, cost centers, business units aren’t updated
• Unique identifiers aren’t determined for the core records and subsequent imports create duplicates
• Companies treat users like tickets – they just need to be able to login, have the correct roles, and “life is good”

Here’s a small example I ran into recently: A customer had done a series of User imports from other systems without clearly identifying and marking a unique field. An integration was built from Salesforce using the email address as an identifier of a Requester (User) in ServiceNow. An issue was reported after we went live because the Requester was incorrect. The root cause was there were three active user records with the same email address and the system picked the first one sorted by sys_id. This issue was not previously identified because the two bad records weren’t being used by actual users.

In these scenarios, core data quickly becomes utilitarian and not useful for broader service management insight or improvements.

My recommendations for implementing and maintaining good core data are as follows:

1. Identify sources of truth and system(s) of record for core data. This is an organizational best practice that certainly applies to ServiceNow as well. It’s rare that ServiceNow is or should be the source of truth or system of record for core data, perhaps other than local User Accounts, Groups and Group Memberships. For example, Active Directory is often the system of record for users across the enterprise. As an organization, identify these systems and implement integrations to receive data from these systems of record.
2. Identify and implement unique identifiers for data records across systems. Akin to my example above, and assuming you’ve done step 1, before importing data from a system of record you need to determine the unique identifier from the source system. Ensure that ServiceNow has this field in the destination table (and import set table), and set up your transform maps or other integration logic to coalesce on this field’s data. This is critical to ensuring duplicate records are not created.
3. Set up your imports and transforms to ensure core references are populated. You’ll need to order your transformations so that references to core table records on other core tables are populated – see the table diagram above. For example, in order to set the Location on the User record, the Location table needs to be populated first. However, if you want to use the “Contact” field on the Location records, you’ll need the Users in place. The reality is you’ll need to do multiple transformations or scripting to handle this circular logic. (Challenge yourself and try multiple transformations!)
4. Use the Production (“PROD”) instance as the system of record for core data across ServiceNow instances. Within your ServiceNow environment, PROD should be the system of record for this core data; sub-production environments will get their core data from PROD via clones. You can and should use sub-production for testing core data integrations, but the data itself should come from PROD. This includes Groups and Group Memberships wherever possible, save for a one-off when development requires a new Group that cannot exist in PROD prior to release. (Think about this as you do development – often a Group can be created in PROD without impact to process.) Using PROD as the system of record for this data means you have matching sys_ids of these records across your environments, and references to this data will not break in clones or code and configuration promotions. It is fine and expected to create additional core data records in sub-production instances – test users in your TEST instance for example – but use PROD as your source of truth.

Benefits of a Strong Core

For experienced system administrators and ServiceNow developers who are aware of and/or follow good practices, I haven’t mentioned anything they don’t already know. Sometimes it’s a matter of time and execution rather than knowledge. But what is sometimes not known is why this is important other than having good, clean data in your systems. What the larger benefits from having this data correct and available are.

It is hard to generalize all the benefits into clean, succinct bullet points. What you can do is move past the ideas of “number of tickets open/closed” and SLAs. Here are examples of the use of good core data, and hopefully it will trigger your imagination to think how it might apply to your organization and its business needs:

• Using the Department and Cost Center data tied to the User References on task-based application records, you can see what organizations are delivering services to what organizations, and use this data for charge-back accounting. For example, IT has completed 500 Incidents for Sales, or HR has fulfilled 300 service requests for Finance. With timekeeping and cost accounting, this data could be used to flow-down into cross-department accounting.
• Analyze trends of types of Incidents and Service Requests by Location (again by requesting User). This analysis could reveal Incident types that could be converted to Problems that are localized but could be avoided in the future.
• Group by core data points to determine if certain organizations or locations could benefit from a new or modified service (Incident deflection?)
• Align new hires and intra-company moves with Department so that standard packages can be pre-ordered (rather than asking each time). For example, the Sales Department employees always get certain access, software and hardware; this could be aligned with the Department so that when a new hire is requested who is part of Sales, the access, software and hardware can be automatically ordered.

For further reading, I did detail an example of what level of service can be provided, reported and analyzed when your core data is complete and used in a previous blog: Tier 5 Service Management.

Hopefully these examples trigger your own ideas about using referential core data to improve insight and improvements to your own organization.

Conclusion

At a cursory level, it is fairly obvious why having good data in ServiceNow is beneficial: clean is always better than messy. However, there’s more benefit than just cleanliness. Having accurate, up-to-date core data can help take your Service Management to “the next level” – both understanding what is occurring in your organization at a deeper level, and being able to make informed judgments about how to deliver Services that maximize benefit and minimize human effort. So start with your roots – good core data – and cultivate the ideas and features that will make your Service Management bloom.