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

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!

Application scoping protects applications by identifying and restricting access to application files and data. By default, all custom applications have a private scope that uniquely identifies them and their associated artifacts with a namespace identifier. The application scope prevents naming conflicts and allows the contextual development environment to determine what changes, if any, are permitted.

Source: Application scope

Each ServiceNow application has an application scope that determines which of its resources are available to other parts of the system. Application scoping ensures that one application does not impact another application. You can specify what parts of the application other applications can access by setting application access settings.

Source: Understanding Application Scope on the Now Platform

The concept is that application code, configuration and data is programmatically “siloed”. This is the ServiceNow version of the old encapsulation concepts in object-oriented programming (OOP). In ServiceNow, applications across scopes have methods of interfacing with each other, but the elements that make up the application (tables, UI element, scripts, UI configuration) cannot be directly accessed by other applications unless granted specific permission to do so.

An important note: When ServiceNow moved to application scoping, all existing platform applications and elements moved into the “global” scope. This is still a scope, but with special properties – it is by its nature more accessible. In general, by default any other application can access global elements and data, rather than by default not being able to access.

Since its introduction, ServiceNow has been touting application scoping as a panacea to many development ills. The stated “best practice” is to always build new applications inside of a scope, and if you’re familiar with installing new applications from plugins or the ServiceNow store, you’ve likely seen quite a few scopes added to your platform environments. For example, in my Personal Developer Instance (PDI), which has very few plugins installed and no Store apps, I have 115 primary application scopes. (The main thing I’ve installed outside of the baseline platform is Customer Service Management.) To me, ServiceNow has gotten “scope crazy”. For example, in my PDI, just within the Change Application there are these scopes:

• Change Management – Approval Policy
• Change Management – ATF
• Change Management – CAB Workbench
• Change Management – Change Schedule
• Change Management – Color Picker
• Change Management – REST API

I can see having Change Management within its own scope. But why are six (6) needed? Does a change approval policy need to be in its own scope? If you’ve tried to make some basic configuration changes within an application, like a reference qualifier or a dictionary override, you know what a pain it can be to have to constantly change scopes and manage all the resulting update sets.

So why has this change been made? Here are some of the stated benefits of Application scoping:

• “Containerization”: All aspects of the application are contained in a namespace
• Security: By default, parts of the platform outside of the application have limited to no access to the application
• Versioning and governance: The entire application has a version, versus the individual elements
• Deployment: Much like versioning, the entire application can be deployed and removed as an entire entity
• Isolating development: Because of the above, large development organizations can segregate development by application

Sounds wonderful, doesn’t it? I’m in total agreement with the concept. However, there are several known and stated qualifiers to developing this manner (in ServiceNow):

• If you are building an application that extends from an existing application in another scope – including global – any element you want to leverage has to be copied into your application scope. For example, if you need a Business Rule’s logic from global, you have to copy the whole Business Rule to your application scope.
• There are different platform APIs for global versus scoped applications. Many of the API calls are the same, but not all of them are. You have to be sure you are looking at the correct API documentation for your current use case.
• Managing development can get more complicated – you’ve got to pick the correct application in addition to the correct update set. This gets more complicated if you are developing across scopes.

Additionally, I’ve noted some other concern in my experience working with this functionality:

• By isolating development, there is a human nature aspect to consider – that developers are less likely to consider platform architecture when developing. There may be a comfort level with the siloing which might lead development organizations to skip oversight of design and standards.
• Having to develop so that applications can use cross-scope APIs and elements adds a non-trivial amount of overhead to development times. In my experience, I’ve noticed a 20-25% uptick in time to develop inside of non-global applications. This is not an across-the-board universal uptick; rather, most things take the same amount of time, and once in a while something that would take 5 minutes in the global scope takes 2 hours in the application scope, as you scratch your head and desperately search why something that works quickly and easily in global doesn’t work at all in your application scope. So there is a large uptick in time on a small number of elements that averages to a 25% total time increase over the course of a development project.
• Pushing upgrade sets across environments using multiple application scopes causes more conflicts and errors than just using global.

My conjecture is that had ServiceNow been designed with scoping from day 1, these probably would not even be concerns – it would have been worked out and eliminated in the platform design process. Instead, scoping has been bolted on “after the fact”, and it raised these and other concerns I’m probably forgetting.

I’ve thought a lot about the question of whether to scope or not to scope. I get asked about it all the time on projects that require custom applications. In my experience, these are the actual reasons to use an application scope:

1. You are building something you want to package to put on the ServiceNow Store or Share site, outside of your ServiceNow environment(s).
2. You save money on licensing.
3. You aren’t versed enough in the platform to feel comfortable implementing isolation techniques in the global scope, such as ACLs, or you aren’t comfortable with your developers for the same reason.
4. You work in a massive development house with many teams developing in ServiceNow without any centralized management of the design, architecture and QA/QC of the platform.
5. You want to be able to say you followed ServiceNow’s advice.

What if these don’t align with your needs? My advice is that you do not need to create new application scopes in order to do custom development. Do what you’re comfortable with. I prefer the ease of developing in the global scope, and I much prefer architectural oversight of the development happening in the platform. When I consider a set of business needs, and determine custom development is required to meet them, I want to be able to determine if I should extend base functionality and use existing elements without having to deal with the issues previously mentioned with application scoping. I also want my developers thinking about how anything they’re developing affects the larger platform. I think that not scoping actually encourages and trains design and development discipline.

I’ll caveat all this by saying that I learned ServiceNow prior to application scoping, and I am comfortable managing development and updates in a single scope. If you’re not comfortable designing and developing with the whole platform in mind, by all means use the tools ServiceNow has provided. I’m not saying it’s a bad thing, I’m simply saying that I don’t think it’s necessary and can have negative side effects. As always, think before you act

Happy developing!

Over the years I’ve seen this flexibility used in a myriad of ways, some really clever and some head-scratchers. Most fall somewhere in the middle. It’s also been the impetus for the rise of good and best practices, from tribal hearsay to attempted codification. But one thing I feel strongly about is using the pieces of the platform in the best way possible for maintenance by non-coders. This is my good practice.

One of the elements that exists all over the platform is the ability to script your way to a solution. Often times it’s an “advanced” option on a particular element – think Business Rules and Transform Map scripts. For people with a coding background, there’s also ways to use object-oriented concepts to build classes and extensions and call them from most anywhere you need them. What we’ve seen in recent years is ServiceNow itself has moved into this for much of its new product development. Anywhere advanced logic is needed – something that requires logic that can’t be contained in a single core element – ServiceNow development is building advanced, decomposed scripts (usually in standalone Script Includes) and calling them from script blocks in platform elements: ACLs, Business Rules, UI Actions, etc. The issue with this is it requires a coding background to either understand the logic flow, or to make changes required for your business.

(I’m going to go on a slight rant here. If you don’t care to read my angst and just want my good practice suggestion, skip to the next paragraph.) In my opinion, this is simply poor design and is indicative of turning ServiceNow over to coders and not critical thinkers. The founders of ServiceNow gave us all the elements we needed to create code-light solutions but they aren’t being used. I often say to customers, “you can code your way to anything, but this isn’t good design”, but I also see a lot of customers whose admins or outside contractors working on their instances just write code until a problem is solved. Great. So now any troubleshooting or changes require going through mountains of code to try and solve. This is not a sustainable maintenance model and should concern anyone making budget decisions about paying for ServiceNow development and maintenance.

So what am I getting at with this article? What I’m suggesting is that if one is smart with designing solutions, these solutions can be maintained through configuration and not code. The solution looks something like this:

In this scenario, the UI Element is out of the box, and the code and config are created by the developer. What’s important to note is that the code is written once, as part of the development of the solution, and changes to the logic are done through the configuration. In other words, the code is simply a mechanism to connect the business logic to the front end, and the logic is contained in configuration.

Let me go through a more specific example of this. I’ve worked with quite a few customers who are using Customer Service Management (CSM) and ITSM and need them to work together. From a business logic standpoint, CSM Cases need to integrate to ITSM records (Incident, Change, Service Request) when non-CSM teams are needed to solve an issue or fulfill a request in order to complete a Case. The Case remains the purview of the customer and the CSM Agent teams, but backend teams and processes are needed to “finish the job”. I call this a Process Integration or intra-ServiceNow integration – it works much the same as a ServiceNow to other system integration (or SN instance A to SN instance B), but is managed wholly within a single instance and works to integrate disparate records and processes rather than systems.

ServiceNow has recognized this need and created a Service Management integration plugin (check name), but this solution is all code, 100%, down to the field level. If you need your process integration to work any differently than what ServiceNow has provided, you have to write your own code to make it work.

To me, this is clearly not ideal. So what I’ve done is something that looks like this:

The key is that we use mapping records to maintain what should go where, when.  The code simply is middleware between the maps and the application – it is kicked off when needed by the application, does lookups against the maps and updates records accordingly. The map records tells the system the following:

• What record and field to pull from
• What record and field to push to
• When the transaction should occur*
• Any field value translations required

* If you’re really slick, you use condition builders on the map records to determine the when. For example, you may only update the Case State to resolved when the integrated Request completes. Rather than building lots of Business Rules or writing If/Elses into your code, you build it into the mapping record. Now customer admins and even “admin-lites” can maintain business logic in configuration records and not code!

The elements described above can be extended and used for any Task integrations required across the platform. The steps are:

• Create Task Mappings as required
• Create Business Rules on the source tables – I usually just add a condition that the source record has to have a related Task-type record – that call the Script Include and pass the source and destination information to them.

I don’t consider any of this out of left field. Why? ServiceNow has already provided a model for this type of solution: Transform maps. While they were designed for importing data into the system, the use case is the same: We need to get data from one place to another, and we need allow for transformation of that data and logic to say when the data should be inserted, updated, or ignored. So why not use the same model for a process integration? 

I’ve described a specific use case, but if you’re thinking along with me, you realize this way of thinking can be used for other development scenarios. For example, I’ve seen quite a few consultants and customers (including myself) develop Service Request fulfillment lookup tables for Approvals, Tasking, routing and other data points. The goal is not to have to maintain dozens or hundreds of workflows (flows) or to have to checkout and edit a workflow every time a simple configuration change is needed. Ultimately, the lesson is this: when you’re designing a solution to a business problem in ServiceNow, always think, “Can I build this in a way that a non-coder can maintain the solution? Does it have to be solved with code only?” I suggest the answer to the latter is rarely “yes”.

Happy designing!

In recent years in the ServiceNow ecosystem, one of the topics that has taken on a “blob-like” existence is upgradeability: the ability to perform an upgrade to the next ServiceNow release, how long it takes, how much it costs, how much remediation is required, and to minimize all these aspects. I’d posit this is directly related to the increasing costs of the platform, and the ensuing exposure to C-level organizational people, and in particular, those who control the corporate purse strings. In conjunction with this, catchphrases such as “How to make your instance upgrade-proof” and “Stay out of the box (to make upgrades easier)” have taken on an inflated importance in companies’ ServiceNow journey. 

For this article, I’d like offer my opinions on the following topics, based on my experiences of 11 years of dealing with this:

• What actually affects your upgrades? What does it mean to take ownership of a ServiceNow element and go away from “out of the box”? What does it mean for your upgrades?
• How do you configure, design, develop and customize in ways that upgrade-proof your instance? 

How Upgrades Work

First, let’s talk about how an upgrade really works. ServiceNow releases a new version of the platform, which includes “black box” items and new items stored in the database. We don’t care about the first (and can’t even if we wanted to). The new database-stored items* are what cause us potential work. There’s three (3) scenarios when ServiceNow attempts to push these items with the upgrade:

1. A net new item is inserted into your instances. No conflicts occur because it is brand new, not seen in previous versions of the platform.
2. An existing item has a new version that updates your instance. You have never touched the item, so it upgrades with no issues.
3. An existing item has a new version that attempts to update your instance, but the existing item has been “touched” by you, so the upgrade skips the update, and you are left to research the differences and determine what to do. This is where the real upgrade work occurs.

* ”Items”: The ServiceNow configuration elements we are familiar with: Business Rules, UI Actions, Policies, Scripts, etc., that live inside of the ServiceNow database

So how does ServiceNow determine what should be skipped? If you’ve worked in ServiceNow for a while, you’re probably familiar with the “sys_update_xml” (“Customer Updates”) table. This is where every configuration or customization you’ve done is captured – the record of every Update Set entry. Without going into detail, any database table in ServiceNow that contains the metadata items that make up the system configuration is marked, and the system adds an entry to the sys_update_xml when any record in these tables is created, updated or deleted. If you update or delete a metadata item (record) that ServiceNow provided “out of the box”, it’s in sys_update_xml and you now “own” it. If you’re following the logic, the ServiceNow upgrade checks sys_update_xml when it attempts to update the metadata items. If it finds an entry in this table, it skips the update. (This includes marking a record inactive! I don’t know how the urban legend began that unchecking “Active” is upgrade-safe, but it’s not.)

I’ve include a screenshot representation of this here:

What this means is you’ve now got a skip log entry, and if you’re doing your due diligence, you check why and determine if and how to remediate. When something is skipped, it is advisable to review and understand what might have been lost in the skip. But it may not be required – “losing out” on new functionality doesn’t mean the system isn’t going to work! 

The other type of upgrade diligence is regression testing your current functionality to make sure nothing broke. This is particularly important for configuration changes and customizations you have made. When something breaks, it could be as a result of a skip. Usually this is a process break rather than an obvious UI issue or system error. For example, a new or change to a Business Rule is conflicting with a new Business Rule ServiceNow provided and causing logic issues within an Application lifecycle flow, rather than an ominous pop-up error message.

Upgrade Proofing Your Work

The previous section is very tactical in nature – what happened, what happens, and what to do about it. Now I’d like to discuss some ways of thinking about your work on the platform that might ease your upgrade processes. We’ll call it “Strategic Design for Easy Upgrades”. 

When you have to develop something on the platform, first consider the Business Requirements being presented. Think about what ServiceNow has provided Application-wise “Out of the Box”, and see how your company’s requirements align with them. Consider particularly:

• Does the lifecycle of the use case align with the out of box application? 
• Does the use case have special security requirements?
• Does the use case have special data schema requirements for a single entity (record)?
• Does the use case need special notifications?
• Do end users need the ability to save something as a “draft” before submitting?
• Do the reporting requirements align with the data schema?

When the business requirements don’t align with any out of the box application or function*:

• First consider an out of the box application with adjunct functionality
• Then consider a custom application
  * and the business requirement isn’t flexible

When I say “adjunct functionality”, what I mean is new functionality that runs in parallel with the “out of the box” functionality, not as a replacement or a customization to an existing item. For example, a brand new email notification with a different set of conditions and different content, or a new Business Rule that makes an update to a field that does not drive the application’s lifecycle flow.

I thought about some of the different development actions I’ve taken over the years and put them in the table below, categorized as “Start worrying” and “Sleep easy”, aka, “Probably shouldn’t do” and “OK to do”. In some cases there isn’t an equivalent in the “Start worrying” category, which I suppose is a good thing:

So to wrap it up, what I’m saying is if you follow the strategies from part 2 of this article, your work described in part 1 should be a lot easier. And, you don’t have to stay “Out of the Box” to do it. You simply have to understand what it means and work smartly with and around it to make your upgrades painless.

ServiceNow was designed as a platform, with a host of reusable elements. Using these for your business needs shouldn’t get you into upgrade trouble.

However… Just because you can do it, doesn’t mean you should!

Happy developing!

* – A play on the famous James Carville quote about the economy, not implying that ServiceNow folks are stupid

As many know, ServiceNow has been through 4 CEOs: Fred Luddy, Frank Slootman, John Donohoe, Bill McDermott; and as most know, Fred was the founder. Fred at his heart is a developer. (From Broke To Billionaire: How Fred Luddy Built The World’s Most Innovative Company) From Forbes:

Luddy hit on a revolutionary idea he had learned from three decades of programming: As the company’s name suggests, he’d deliver office services over the internet, on a subscription basis (monthly, per customer), updated easily without requiring customers to manually download software from disks on different operating systems. As this was 2003, Luddy proved to be a software-as-a-service pioneer, pushing a user-friendly interface designed for the average office worker…
The market’s response: “Meh.”

“We had this really great, simple platform for creating workflows, and we would go to people and say, Hey, you can do all these things with this, and they just weren’t interested,” recalls Luddy, who at one point sold a car to make payroll. “So we went back and said, Okay, we say this is this great tool for doing things like IT-support management, so why don’t we back that up and make an IT-support product?” This time the market bit.

I think there are two takeaways from this: ServiceNow was designed as a platform first, and the market only bit on the vision after Fred and team layered pre-canned applications (products) on top. The product just happened to be ITSM, because that’s what Fred knew from Peregrine, and the market was ripe for innovation in this space.

If you’ve seen Fred speak about his original vision for the platform, you know it came out of his desire to have a tool that could easily re-create form-based processes. Why do something on a paper form if it could easily be re-created in a computer based- system? So the platform was designed around this concept – the rapid development of form-based applications. This included the following elements:

• The ability to create new tables in the database
• A set of database field types that have inherent UI functionality (e.g. Reference and Journal fields)
• Inherent UI elements on top of (almost) any database table
• The ability to extend existing database table and inherit not only the data elements, but the UI and flow elements as well (as needed)
• The ability to create and run graphical workflows against (almost) any database table
• The ability to send and receive email notifications against (almost) any database table
• Graphical and script-based configuration elements that let you manage the UI to business process needs
• Server-side script-based business logic elements
• Graphical and script-based security configuration

The real key in this is the inherent elements that were “baked” into every table in the database, even those created by customer admins. If you create a new table, you automatically get default form and list views of that table’s data, and the ability to add or layer any of the other listed aspects to it. So customers could quickly spin-up new applications by creating tables and configuring how it is presented in form, lists and reports, and layer in business logic as desired.

Similarly, the original developers simply used these platform elements – that any ServiceNow platform administrator can access – to create a set of ITSM applications. In the 15+ years since, ServiceNow development has continued to use these elements to build other application sets: Customer Service, Human Resources, IT Operations Management, etc. But what hasn’t changed is the platform under these applications.

All of this is to say that the real power of ServiceNow is the platform, not the applications that sit on top of it. I realize that the average ServiceNow admin and/or developer doesn’t have the insight into the history, standards, business processes and other elements of every application and application suite in the platform. (For example, I have very little knowledge of all the reasons HR Management is built the way it’s built.) So there’s value to having knowledge and expertise behind the creation of a particular business application. However – and this is where the curmudgeon in me emerges – what has happened in recent years – really since Fred stepped back and stepped down from the company – is ServiceNow has tilted its marketing focus from being a platform company that happened to do ITSM, to being a product company that happens to run on a flexible platform. I doubt this shift was fully intentional or fully clean; rather, it’s been a gradual shift based on several factors:

1. Changes in company leadership: ServiceNow is now on its fourth CEO, along with the requisite management changes that happen along with it. Each change brings in leadership with their own histories and biases, without the knowledge of the platform’s history.
2. Responding to market feedback: I’ve heard from C-level ServiceNow folks that the platform direction is at least partially dictated by conversations had with customer C-level folks. These are conversations that rarely focus on underlying technology but rather broad business needs, particularly financial in nature. There’s a reason “stick to out of the box” became a thing, and this is a big part of it.
3. Aligning to shareholder needs: Going public means the company is driven by quarterly and annual financial results moreso than innovation. You can draw a straight line from the ServiceNow product releases of recent years – and their accompanying licensing – to quarterly financial goals that edify the markets. (For a great read on what this mentality does to companies, see Christensen’s “The Innovator’s Dilemma”, ISBN: 978-0062060242.) It’s easy to draw a straight line from Importance of Financials to Licensing to Focus on Product and not Platform. You can’t easily sell Platform improvements, but you can easily sell and market new Products.

You can’t necessarily argue with the results. (Check the share price.) My concern is that like a lot of successful companies that lose sight of what made them great, the turn from Platform to Product will catch up with them sooner or later. It’s a testament to how great the core platform is that the success continues, but as the complexity of the Products ServiceNow builds on top of it continues to increase, and admins and developers are hamstrung by the need to stay out of the box – rather than adopting the platform to their business needs – one wonders how much Platform goodwill will erode over time.

Last note: I’ve been saying for years now that it feels incongruous every time I attend a Knowledge conference and hear, “Upgrade-proof your instance – Stay out of the box!” in one ear and eye, and in the other, “CreatorCon! Create anything on ServiceNow!”. This incongruity goes hand in hand with what I’ve outlined in this article. Ultimately, I still love the platform but struggle to love its products.

(I’ll have more about “out of the box” and “upgrade proofing” in other articles.)

The generally accepted ITIL definition of a Service Request is “request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery”. (This differentiates from Incident, in that it doesn’t involve a restoration of Service.) The key part of this is “agreed as a normal part of service delivery”. Companies often struggle with what a “normal part of service delivery” means. ServiceNow further complicates this with how they built the Service Request application. If you’ve worked with the Service Catalog, Catalog Items, and the Service Request records they create, then you are probably aware of some of these challenges.

I drew this picture on whiteboards for customers for a few years and then gave it to ServiceNow training in 2013 and said “This needs to be in your curriculum. People need to understand this picture.”

The initial challenges are two-fold:

1. The Service Catalog and Catalog Items were designed to give an “Amazon” like experience. Customers select items, add them to a cart, and order them. In order to do this properly, the items need to be well-defined. You don’t go to Amazon and say, “I need socks”, press “Order” and Amazon says, “we’ll figure out the rest on the backend”. No, the expectation is you are selecting a well-defined product – size, style, color, etc. Amazon knows what they offer, which leads us to part 2 – they also know how to deliver it.
2. The Service Request is a 3-tiered record structure, with an Item-specific workflow running against the middle tier (Requested Item). The workflow generates and assigns Tasks (the third tier) based on a known delivery flow. In other words, because Amazon has defined what they are offering, they also know exactly how to deliver it.

In this way, the Service Request structure does not lend itself well to open-ended requests or ad-hoc delivery flows (aka “We’ll figure it out as we go”). The idea is that IT (or any part of the business) is delivering a known entity – they are able to define what that entity is, what it needs to ask the requester about the entity request, and what process and people need to be involved to fulfill the request for the entity successfully.

When part or all of this can’t be met, the reality is that the Service Request application (starting with a Catalog Item) may not be the correct place to build the requirement. In general, I ask the following questions of the requirement to determine if it can and should fit into a Service Request:

1. Does the use case have special security requirements? (Securing individual records gets complicated with the 3-tier record structure, and doesn’t scale well. Not to mention the notification and audit concerns.)
2. Does the use case have a known approval and delivery process? (Open-ended and ad-hoc approvals and tasks make for complicated workflows.)
3. Does the use case need the user to interact with the data after submitting the request, beyond comments? Do users need the ability to save something as a “draft” before submitting?
4. Does the use case have special schema requirements for a single entity? (e.g. Dept X needs to have 5 “special” fields on RITM to satisfy some specific need)
5. Does the use case need special notifications?
6. Does the use case require editing of variable answers after the submission of the request?
7. Does the use case have reporting requirements against what would be a variable? (ServiceNow still doesn’t do variable reporting well. Even though it is supported, it wasn’t designed with this in mind.)
8. Does the use case need an integration after the request has been submitted? (I’m shuddering at the thought of having to integrate variable data with another system.)

In general, I treat variables almost as “read-only” and un-reportable, in that a user should be able to populate them, submit them, the fulfiller looks at them to fulfill the request, and never needs to do anything else with them. Adding logic to variables is kludgy, and you don’t get a real audit history when they get edited. So when someone comes up with some complex use case that needs all this weird logic and interaction with variables, it starts to look like a Picasso painting. (As usual, this is as much art as science.)

So what to do? There isn’t a hard and fast answer to this. In some cases, when a customer is new to the platform, I have less of an issue creating a single “generic” request item that fills the need for requesters of “I don’t see what I need, can I just tell you what I need?” What this usually requires is two-fold:

1. An open-ended description that allows the requester to describe what they need. The assumption is that this almost always requires a follow-up by a service desk agent and some back-and-forth before being able to assign out work and fulfill the request.
2. A fulfillment workflow that allows for ad-hoc approvals and/or fulfillment tasks.

Keep in mind this type of request usually cannot be aligned with any delivery metrics, or if it is, will potentially skew these metrics.

In other cases, I’ve built an entirely new application to support these kinds of requests, using the Out of Box “Ticket” (ticket) table. This was for large organizations who have a well-defined catalog of items, but also fulfill a lot of requests that don’t align with a pre-built item. These are organizations whose use cases answer “yes” to many of the questions above. Once built, the records themselves can be assigned, worked and reported on like any other task-based record in ServiceNow, and queues can be managed with the ideas of “My Work” and “My Groups Work”.

So why not use Incident? An argument can be made for this, particularly if the volume is small. This is the reason for Category “Question” and Priority 5. However, keep in mind that the definition of Incident is something is broken and the goal is to restore service as quickly as possible. Often the use cases we are describing have nothing to do with restoration of service.

Regardless of the approach, the best practice is to continue to mine the requests entered for these use cases to determine if they can be converted to a well-defined Catalog Item and Fulfillment Workflow.