(One in a Series of Posts About Building the Right User Experience)

Introduction

User Experience (UX) is a broad topic, with people whose full-time job is designing and ensuring implementation of a good user experience. I’ve found this is a discipline only done in very large organizations, or organizations who have UX as a primary focus. This is a minority of ServiceNow implementations. UX in most ServiceNow environments is left to the best efforts of developers, admins, QA and business stakeholders. And often it is largely ignored!

Although I’ve previously written about UX in general – form administration primarily – there are specific technical solutions in ServiceNow to provide a better UX. In my experience I’ve found these solutions are often undocumented (at least officially), and therefore unknown. And yet they are key to basic, fundamental good UX.

In this post I’m going to present and describe a solution for confirming an action before taking it – allowing a user to consider their action and confirm it before the system takes the action.

The Problem

Even if you’re not familiar with UI Actions, you are. These are the ServiceNow elements that manifest themselves as buttons, right-click menu items, and form links. (“Save” and “Update” are UI Actions.) There are plenty of times that a business requirement obligates the creation of a new UI Action. Like a lot of configuration, this is fairly straightforward in ServiceNow and well known by most admins and developers. The basic configuration of a UI Action includes:

• Name (what shows to the user)
• Conditions by which it should show
• What kind of element it is (button, etc)
• Whether it runs on the client (browser) side or server side
• A script that runs upon clicking the action

The issue we’re dealing with in this article is that they do not include a modern and sensible way to confirm a user’s decision prior to execution. For many “standard” UI Actions (like Save or Update), a confirmation isn’t really needed. But in cases where you develop a new UI Action, the requirements often takes a “larger” action when executed – perhaps copying a record, recalculating a total, updating a related record, or triggering an integration. Regardless, these are consequential enough that a good UX design includes a confirmation of the action prior to taking the action. As mentioned, ServiceNow does not offer this as a configuration*, nor as part of their documentation.

* Where it is configurable and not a custom or copied code solution.

The Solution

We’ve established that good practice is to have confirmation for actions that make significant or important changes in the system. Let’s look at the components and settings of the UI Action that will make this possible with the best UX.

• Combine client and server-side script into one. This means the script portion of the UI Action will have parts that run on the client browser side – this is the confirmation, and parts that run on the server-side.
• Configure the client and server identifiers. These are the Action name and the onClick fields.
• Use an out-of-the-box UI Page as your confirmation dialog. This is the key element of the solution. While you could use a standard Javascript pop-up confirmation, these are not “business class” and can be disabled in some browsers. The ServiceNow dialog “fits” the UI better, and has more configurable elements.
• Message the user appropriately. In both the confirmation dialog and the aftermath of the action, the user should be informed what will happen if they proceed, and what did happen (even if unexpected).
• Send the user to the appropriate location. At the end of the action execution, the system will take the user to the previous screen if not directed elsewhere. In the script we will redirect the user to the place where it makes the most sense based on the action executed.

Words are nice, but let’s look at a solution example so you “get the picture”. I’m going to create a UI Action to Clone an Incident record – not a great business case, but just to get the idea how this works.

The main form elements are shown below. Most parts should be self-explanatory. Note the Action name – we’ll see this in the script. Also, we can uncheck “Show insert”. This action would not be used on new records, only existing.

Farther down, there’s the client identifier – the script function that runs when you click the Action. (If you’re wondering, the “current.canWrite()” makes the button visible to anyone who has write access to the record they’re on.)

Because the script uses some Javascript browser functions, you’ll need to uncheck the “Isolate script” box. (This may not be on the form by default; you could add it or use the list view to edit.)

I’ll show the script in several chunks and point out the important pieces.

In the first section above:

• Line 2 contains the function definition that is called from “onClick”.
• Line 3 uses the correct type of pop-up based on if the underlying screen is full screen or a window.
• Line 4 contains the name of the UI Page being used for the pop-up dialog. (There are others out-of-the-box if you check the list of UI Pages in the system.)
• Line 5 sets the title text for the dialog
• Line 6 sets if the dialog shows an informational or a warning icon
• Line 7 sets the text that appears in the pop-up dialog just above the Cancel and OK buttons
• Lines 9 and 10 are the names of the functions that get called when the Cancel and OK buttons are clicked

In the next section, the other client-side functions either cancels and closes the dialog, or submits the action to the server-side for processing:

Finally, the server-side script below executes the clone, redirects the user to the new record, and messages that the clone occurred. (Technically, line 26 is client-side and line 27 is a server-side function name, but it’s not critical to know this, just that it’s needed and works.)

Lines 31-37 can be whatever you need them to be to fulfill the action required. You can also call functions in Script Includes from here. The key UX takeaways are lines 38 and 39, which navigate and inform the user in “sensible” ways. (Again, use your best judgment for this portion as well – think about what navigation and messaging would make sense to you if you were executing the action.)

Very briefly, here’s what this looks like in action. Upon clicking “Clone” on an open Incident, you are presented with this dialog box:

If you click Cancel, the dialog box goes away and you’re back on the original Incident form. If you click OK, the system executes the server-side script, sends you to the new Incident, and provides the messaging from the script:

This provides a much better user experience than having everything executed on the server-side, and either leaving the user on the same record or sending them to the new record without any confirmation of either to take the action (and what it implies), or what just occurred.

The last thing I’ll point out is the importance of aligning your names across the UI Action fields and within the script. The image below shows the five places function and action names need to align or your UI Action will not work.

As usual, a little attention to detail goes a long way!

Conclusion

How ServiceNow is perceived, and how your work is perceived, is based on how users view their experience of using the system. While ServiceNow has provided plenty of good user experiences “out of the box”, sometimes the platform falls short in giving admins and developers the tools at hand to develop their own best-practice user experiences. But often the components exist even if they are not well known or documented. Use these components to create the best UX possible, and put what you’ve built into your library of tools to draw from as you develop similar solutions down the road. Your users will appreciate it and you’ll be a ServiceNow star!

Go forth and develop wisely…

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

In journalism, there’s the concept of the Five W questions whose answers are fundamental to getting the information needed:

• Who
• What
• When
• Where
• Why

I want to talk about what I call the “Three Ws of Development” in the ServiceNow realm. These three are: When, Where and Why. We’re going to skip the questions “Who” and “What”. Why? Because “who” is a question for hiring managers, recruiting, and resource vetting. And “what” is (too often) the focus of most if not all training and documentation. Do you need to get the current user’s ID on the client side? Check the API – that’s the “what”. Instead, I want to focus on some areas of development consideration that I feel are often neglected, and I’ll explain each and try to put them in context.

Most everyone in the ServiceNow world knows the basic system architecture, which is the same for almost all cloud-based applications:

On the ServiceNow side, there’s an Application Server that stores the compiled code, the files (images, etc.) needed by the application, and delivers content to the user’s browser when requested. The App Server connects to a SQL Database that stores all the data records, and in ServiceNow’s case, all the configurations and code customizations created by both ServiceNow and customers.

Now consider a “normal” transaction between these entities. We’ll use one that’s fundamental to ServiceNow: Accessing and updating an Incident record. The following shows all the component parts in this transaction:

1. Client makes a call to the server to get a specific Incident record
2. Query Business Rules determine if certain records should be restricted from view
3. Application queries the database for that record from the incident and related tables
4. Database returns required data to the application server
5. ACLs are evaluated and applied
6. Display Business Rules run logic and place data on the scratchpad (to use client-side)
7. Application Server provides browser with form, data, and all configurations based on 4-6

8. onLoad UI Policies and Client scripts run
9. User manipulates data, onChange UI Policies and Client scripts run
10. UI Actions run client-side, server-side, and sometimes both (first client, then server)
11. On Save, client sends form data to the Application Server
12. Before Business Rules manipulate record data prior to saving to the Database
13. Application Server sends data to the Database
14. After Business Rules run on any table (current, previous still available)

This is a broader “order of execution” list than ServiceNow provides in their documentation, which deals strictly with Business rules.

So how does this apply to our Ws discussion? Let’s discuss:

Where

In considering where to develop your configurations and customizations, you will almost always get better performance having them run on the Application Server rather than the client’s browser session. Observe the middle section of the diagrams above and the components that live in it. For example, when a user accesses a record, if you need to run logic and have the result available on in the client’s session, it is faster performance-wise to run the logic in a display Business Rule and place the result in the scratchpad rather than run the logic in a Client script, particularly if the latter would require querying the database after the record has been accessed and loaded in the client browser session.

Another important use case is security. All security should be done in ACLs, and only supplemented with UI Policies and scripts where needed. ACLs are the only true security, all other methods are posing as security and can usually be bypassed. For example, let’s say you have a Social Security Number field on a User record that should only be available (visible) to Human Resources, and should not be editable by anyone (it feeds from an HR/HCM system). This field should be secured with field-level read ACL for users with an HR role, another field-level read ACL marked false for all other users, and field-level write ACL marked false for all users. If you were to use a data dictionary level read-only marker, this could be bypassed by scripts running as the system. If you were to use a UI Policy or a Client Script to make it visible and/or read-only, this could be bypassed by list views and edits, server-side scripts, and Integration APIs.

In keeping with the last idea, it is also good practice to mimic your client-side logic on the server-side. For example, if you don’t want to force a field to be mandatory for every save, but want to run client side logic that prevents the save of the record without the mandatory field in a particular scenario, you should also create a server-side Business Rule that aborts the save and messages the user about the mandatory field. This way, your logic is enforced in list edits and server-side record manipulation, and not just in form views.

• List edits bypass “standard” Client Scripts and UI Policies
• External systems integrate directly with the Application Server

Note: You may have noticed that I haven’t mentioned List configurations like List Edit client scripts. These are also usable to “fix” the List edit issues mentioned, but it doesn’t fix server-side logic and integrations.

When

Going hand-in-hand with the Where is the When of development. Specifically, consideration should be paid to when in the lifecycle of the full transaction the development is best to exist. Consider the following Business Rule scenarios:

• You need to access information client-side that is not available on the current record being accessed but can be ascertained using the current record (e.g. querying information from another table using field data from the current record. The correct time (when) to run this logic is in a display Business Rule and place the needed information in the scratchpad.
• You need to manipulate field data for the current record before the record is saved to the database; for example, you need to multiply two integer fields from the current record and store the product in a total field on the same record. The correct time (when) to execute this is in a before Business Rule.
• You need to manipulate field data for a different record using the current record data, and either need to access the “previous” object, or you need the manipulation to be reflected in the user’s updated client session view. For example, you are updating a related record to the current record and the update needs to be reflected in a related list of the record form the user is currently viewing. The correct time (when) to execute this is in an after Business Rule.
• You need to manipulate field data for a different record using the current record data but it doesn’t need to be reflected in the user’s updated client session view, OR you need to trigger an integration whose updates don’t need to be reflected in the user’s updated client session view. The correct time (when) to execute this is in an async Business Rule. Async Business Rules create a Schedule Job that gets queued and executed as system resources become available.

Why

There are many other scenarios an experienced system admin/developer can think of. A key is to understand all the component parts of the transaction diagrams above; the goal is to configure and develop in the correct place, both where and when. Why? The benefits of developing in the correct time and place are:

• Performance: Following the when and where guidance will ensure the best system performance. Running logic on the server is almost always faster than on the client. Running logic asynchronously means the client, and therefore the user, means they don’t have to wait for the transaction to complete. Each time the transaction can avoid another database query means faster execution and less wait time.
• Security: Developing measures that secure fields and records, both visibility and editability (R and U in CRUD), in the correct place, means your instance is actually secure, versus appearing to be secure to an end user. After all, most if not all security breaches do not come from a human clicking and typing.
• Maintainability: Broader maintainability comes from following good and best practices. Consider a ServiceNow health check – what is the likely result of a system audit if you follow the practices suggested above versus using whatever means are available to create solutions.

Conclusion

ServiceNow provides many means to an end. Sadly, much of the documentation and training does not cover which the correct means to the end; rather, it simply details, “If you need to do X, go here and do this”. It doesn’t say why you should do it this way, or what the overall implications are to doing it that way. What I’ve tried to do is give you a baseline of how the system works, so you can understand where and when the correct places are to do X. Understand the baseline, and stop and think about it before everything you develop. I promise your platform, and hopefully your work life, will be better for doing so.

Happy developing!