(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 guess it’s time to write something about AI. The topic seems unavoidable these days. Everywhere you turn there’s another article either breathlessly extolling the virtues of AI, or warning of the dangers, or predicting a future where AI either has given us lives of leisure or made us its slaves. What I don’t see is a lot of analyses of the short-term practical uses of AI, and where it may or may not make sense for business use. In this vein, I will give you my thoughts on how AI fits into a ServiceNow strategy for the next 1-5 years, and highlight what I think are both the realistic benefits and the unrealistic hype.

A Brief History (and Where We Are Now)

There has been some version of AI in the ServiceNow platform for years now. The early iterations were machine learning (ML) models that attempted to fill in “ticket” details based on what was learned from previous tickets. For example, an Incident comes in from an end-user with a short description of “Can’t access SAP expense module”. The ML uses its database of learning similar Incidents with keywords of access”, “SAP”, and “expense module” to auto-assign and prioritize the Incident automatically, bypassing initial human triage, saving time and human intervention.

The second phase of AI incorporated Large Language Models (LLM) into specific toolsets (currently branded Now Assist). These tools can take data from the system and build natural language outputs for a variety of uses. The most common example is using LLM to summarize a triage type “ticket” (Incident, Case, etc) into a resolution notes field, saving a human from having to read through the entire history and start writing a summary from scratch. They can also be used to write emails and code blocks.

The next phase is Agentic AI; there’s quite a bit of “press” about this today. Agentic AI is meant to mimic a human’s process / decision flow – analyzing a problem and taking steps to remediate the problem automatically using intelligence it has built up over time analyzing similar problems. It is meant to work largely if not wholly autonomously.

The AI journey to-date can be summarized thusly:

1. Informational: The AI provides information – and hopefully answers – to human interactions based on learning from previous similar interactions and “grading” of the information provided by the AI.
2. Problem Solving: The AI runs workflow automations based on input from the human to automatically provide solutions to the user’s needs. The AI bases its decision making on “grading” the success of previously suggested solutions.
3. Automatic detection and remediation: The AI learns when issues are occurring and runs workflow automations based on learned knowledge of the issue to automatically resolve the issue.

Much of the AI available in ServiceNow today is still ML-based. You’ll notice this as you read about and set up the AI tools: there are minimum number-of-record thresholds that must be met in order for the “machine” to learn enough to be able to provide viable suggestions and solutions. Viable in the sense that the AI can determine it is statistically likely that the suggestion is accurate.

Recently, ServiceNow has added large language model capabilities to leverage “ChatGPT-like” functionality. This allows for auto-creation of chat and “ticket” summaries, notification text, and other customer communications. This is the next phase of AI in ServiceNow, currently branded as Now Assist.

As we venture into mid-2025 (and the annual Knowledge conference), it is likely we will be hearing quite a bit about ServiceNow’s plans for Agentic AI, as the promise aligns so well with the Service Management paradigm ServiceNow has excelled in.

Considerations for AI in Service Delivery

The marketing around these new AI solutions certainly make them sound like the answers to all your problems. While there is promise for automating facets of work that are tedious and human-intensive, I believe that using AI specifically for Service Delivery needs to be carefully considered. Let’s look at a tiered approach to using AI for a Service Delivery situation, then delve into the concerns and challenges.

Consider an example of the layered approaches to Service Request using AI:

• A chatbot that attempts to answer user questions based on knowledge gleaned from analyzing the available data in the system. This is the most basic level and functions much like ChatGPT does using the broader internet. Simple to turn on and implement, but many users don’t want this as a solution, any more than they want an automated phone tree when they call a company’s customer support number.
• Automatic ordering of a Catalog Item based on questions and prompts to the user. This expands on the solution above, but adds the intelligence to understand when a Catalog Item will provide the required solution, and uses prompts to gather the required information to begin the Service Request process without the user having to navigate to the Catalog and order it themselves.
• Automatic fulfillment of the process started in part 2. This would include the AI initiating an RPA or orchestration to complete the Service Request without human intervention.

The layers go from initial “call” deflection with targeted knowledge, to full end-to-end delivery with AI making all the determinations for the correct process steps along the way.

Concerns/Challenges

What are the concerns for letting AI take over the end-to-end delivery? Typically they are allowing AI to make all the decisions along the way. Regarding the full process, you can ask yourself:

• Has a human determined the process can be automated?
• Has a human built the workflow that the AI can initiate?
• Can the Request be fulfilled without human approval or other fulfillment work done by a human?

If you say that a human does not need to make these determinations, there are potential organizational challenges that arise. They center around what KPIs a company uses, and how they rank the importance of these KPIs. In a Service Management environment, consider:

• Customer satisfaction risk. Regardless of the AI solution, is a company willing to risk customer satisfaction, and potentially customer retention, by turning customer service over to a non-human entity? In the scenarios above, what if the AI makes an incorrect determination and there is no human error-proofing along the way? What if AI misinterprets a password reset request as a system reset request and reinitializes a server VM?

Most of us in the business world live in risk-averse environments. Leadership and management are more likely to preserve the status quo than take large risks against customer satisfaction and retention.

There’s a further challenge I don’t hear about much: AI works best with large volumes of data to analyze. The bigger the better. In an ideal world, ServiceNow’s AI would be analyzing data across all customer instances, not just one customer. But companies are not likely to sign up to share their data. Additionally, there is some data even within a single customer environment that will not be made available to AI: Think sensitive HR data. It certainly is a different scenario than say a Google AI agent scanning the entire internet for useful data.

Reality Check

What I see for most ServiceNow customers is a “tiptoe into the AI water” approach, rather than wholesale adoption. The approach often incorporates these aspects:

• Turning on an AI tool in a subproduction environment and observing the results
• Using LLM to auto-create text passages for notes and emails that get reviewed and edited by a human
• Letting AI make a suggestion for a resolution but having a human execute the action, or at least approve of the action prior to AI executing them
• Building orchestration flows that AI (the system) will execute, but a human designs, or co-designs with AI

Smart companies use their best employees to spearhead these initiatives, running in lab-like environments before turning on in production, and becoming champions of the initiative throughout the organization to drive adoption.

Conclusion

There’s great promise in the features and functionality of AI. Being able to use machine learning and large language modeling to remediate issues and fulfill requests automatically, freeing up precious human resource time and capital, is appealing to corporate executives in all industries. As with most new technologies, the theory and the marketing pitch run far ahead of the reality and challenges of implementation and management of the technology. Given the scope of AI for automating work, much consideration must be given as to when, where and how to implement. Smart organizations have knowledge of themselves and their processes, and plan for an intelligent, phased approach to AI implementation, aligned with their KPI objectives. These same organizations measure against these KPIs and continually tune along the way. The alternative risks both customer satisfaction and retention; eliminate these risks as you go on your AI journey!

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.