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!