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

Introduction

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

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

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

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

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

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

When Not to Code

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

When to Code

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

An Example

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

In this situation, you have two choices:

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

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

Conclusion

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

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

Happy developing!

*specifically writing Javascript and using the ServiceNow Glide APIs

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

Introduction

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

Management Approaches

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

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

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

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

Examples

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

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

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

Best Practice

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

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

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

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

ServiceNow’s Documentation on Center of Excellence

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

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

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

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

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

What is the ServiceNow Core?

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

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

The main tables are:

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

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

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

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

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

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

Building and Maintaining Your Core

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

Here are some common examples:

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

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

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

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

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

Benefits of a Strong Core

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

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

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

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

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

Conclusion

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

In part one, we discussed what an architect is within the ServiceNow and the larger IT ecosystems. Now, we’ll delve into design documentation – a key part of an architect’s deliverables, and some of the behaviors of folks who may have the title architect but whose actions belie the title.

Documenting designs and implementations

A good architect understands the value of documentation, and both creates and enforces documentation. My rules of thumb for documentation are:

• Any custom development that includes creating new tables needs design documentation. This does not include Import Set tables, but does include tables meant for custom lookup functionality, extensions to existing functionality, and new task-based applications.
• Any development that spans multiple Agile stories likely requires design and implementation documentation. What I mean by this is if the solution being implemented is complex enough to require multiple stories, there should be a centralized design for the solution that can be referenced by Story developers and post-implementation maintainers.
• Any development whose essential nature cannot be found in existing ServiceNow documentation likely requires documenting. This is typically custom development.
• Any development that would not be obvious to an experienced ServiceNow admin or developer who walks in “off the street” likely requires documenting. In other words, if an experienced ServiceNow person wouldn’t be able to understand the design of the solution simply by looking at what’s in the platform, then the architect “owes” them design documentation so they can see the thinking behind the design. (I can’t say how many times I’ve come into a situation like this and my only tact is to start reverse engineering code. I find this unacceptable.)

My standard “as-built” documentation for these scenarios includes:

• The picture of what was designed (aka “Visio”)
• The narrative of what was designed, and why
• The elements of what was implemented, and where
• The narrative of how the solution is to be maintained

For the sake of illustration, a Salesforce integrated application design document make look something like this:

Design Diagram

Design Narration:

The solution uses a custom request application to align with the Salesforce model, and uses Web Service Import Sets to stage the Salesforce data. Within ServiceNow, the same request can be initiated through a Record Producer in the Service Catalog… continue to describe the diagram and how the pieces fit together.

Implemented Elements:

Maintenance Notes:

In order to extend the data schema on both systems, add fields to the ServiceNow request and import set tables, and use the transform map functionality to populate the field(s). Extend the custom mapping table to Salesforce so the outbound REST message will pick up the new field from ServiceNow… continue to describe the maintenance and extension of functionality

The goal is not documentation for documentation’s sake. The documentation should be clear and straightforward – think of the person who is seeing the solution for the first time. If it were you, what would you want to see to understand what was built?

You should be able to give the document to an experienced ServiceNow admin or developer and they understand the solution and can maintain it without having to comb through the system and/or reverse engineer it to learn it. And if I’m being perfectly honest, there are plenty of times I have to do this with new ServiceNow created applications or solutions.

Architect Failings, aka When It’s a Misnomer

It’s also helpful to list things that aren’t architecture, or at least don’t fall under the heading of “what makes a (good) architect”. I posit that when someone who has the title of “Architect” does these things, they are not truly an architect.

• Treating all requirements development as a one-off. In other words, as requirements come in, the named architect only considers the requirement within the scope of itself, and solutions inside of that box. Doing so results in many unrelated one-off solutions within the platform, without a cohesive platform strategy to tie them together. This leads to maintenance challenges, as each change requires modifying a particular element. For example, I was working with a customer who had several hundred catalog items, each with their own workflow. We made a platform change at the Task level that required the modification of the same few lines of code across hundreds of workflows. A good architect somewhere in that development journey should (would) have stopped these one-off developments and designed a solution where the code existed in one place and was called where needed by the workflows. (I would argue a good architect would also consolidate the workflows, but I hope you see my general point.)
• Implementing all requirements with code. I also refer to this as “write code until it works”. I’ve written about developing solutions that leverage the elements of the platform and maximize configuration over code. An architect understands how this is done, and avoids the common trap of overcoding. Just as important, he or she assures that the development team doesn’t do this either by providing design guidance as I’ve described previously.
• Pushing products over solutions. There is a balance that must be struck between defaulting to a ServiceNow product as a solution, and developing a custom solution that may more perfectly align directly with business requirements. An architect understands each, and the tradeoffs, can articulate the advantages and disadvantages of each, and guides customers to the correct implementation for their business needs. In my view, those who do not make this distinction, but default to a ServiceNow product based on a few keywords heard in requirements sessions, are better termed as Sales or Solution Architects and not Technical Architects.
• Limiting solution scope to ServiceNow. When reviewing business needs, if an architect does not consider all possible solutions in the enterprise, but limits their scope to only ServiceNow, they are not performing the duties of a true architect.

Conclusion

A good ServiceNow architect always starts with understanding the business’s short and long term needs, and recommending a solution that aligns with both, regardless of the technology. He or she understands enough about the ServiceNow platform to recommend the correct application or platform technology to meet the need when ServiceNow is the correct solution. And the good architect provides design oversight so that all parties involved in the solution are working toward the correct goal in the correct ways. In short, the best ServiceNow architects have knowledge of, and can work in, all spheres of the ServiceNow and Enterprise IT scopes:

Lastly, when the architect doesn’t have the required experience in a particular area, they know enough to seek expertise in that area (rather than “faking it until they make it”). If knowledge is power, knowing what you don’t know is wisdom.

“Architecture is not an inspirational business, it’s a rational procedure to do sensible and hopefully beautiful things; that’s all.” – Harry Seidler

If you’re here and reading this, you probably have a concept of what a ServiceNow architect is. (In this context, “architect” means a ServiceNow technical architect.) And you’ve likely worked with folks who have the title “architect”, whether on implementation projects or as part of a larger IT ecosystem. But what does this mean, and what should it mean? I’ll spend the rest of this article discussing this topic. Having the title Certified Master Architect doesn’t mean I have all the answers, but I’ll posit that having my experience and acumen means I can define it as well as anyone.

In part one, we’re going to discuss what an architect is within the ServiceNow and the larger IT ecosystems. In part two, we’ll delve into design documentation – a key part of an architect’s deliverables, and some of the behaviors of folks who may have the title architect but whose actions belie the title.

It’s helpful to start with two lists that will contextualize the discussion: The roles that are common to a medium to large-sized ServiceNow environment, and the spheres of influence the ServiceNow leaders oversee.

Common ServiceNow Roles

• System Administrator – hands on configuration and management of the platform
• Business Analyst – elucidating business requirements
• Developer – custom solution development
• Designer – intra and inter application solution design
• Architect

In many customer environments, folks fill more than one of these roles, and potentially one person wears all the hats in small platform implementations.

ServiceNow Decision Spheres

• Hands-on development
• Application design
• Platform strategy
• Enterprise strategy

These are the areas that require guidance to be provided and decisions to be made. Much like the roles, the people providing the guidance and making the decisions may cross spheres, but the spheres exist.

These spheres fit into a pyramid picture of ServiceNow within the IT ecosystem.

At its most narrow, it helps define development best practices, and at its broadest delineates where and how ServiceNow fits in the overall IT enterprise.

Defining the “Good” Architect

In my experience, and based on feedback from my customers, here’s what makes a good ServiceNow architect, and comparing it to what might be considered architecture but really isn’t:

Considering ServiceNow in the larger customer environment

This is traditionally the purview of the Enterprise Architect in larger organizations. The role takes into account short-term organizational and project needs, and longer-term strategic needs, and evaluates which technology tools are the correct ones to meet both needs. A ServiceNow architect should be able to converse intelligently about these customer needs and convey where ServiceNow can and should fit into meeting those needs. Just as importantly, he or she should also understand and be honest about where ServiceNow may not fit those needs. Between these two, the architect should be able to articulate what ServiceNow can do, the level of effort and cost to implement and maintain in ServiceNow, and help the customer make the correct decisions about using – and not using – ServiceNow.

Understanding the platform separately from products

A good ServiceNow architect understands the platform inherently – I’ve written about this previously. ServiceNow has increasingly moved from being a platform to being a series of products developed on that platform. While there is value in understanding these products, particularly from a business process perspective(*), a good architect can separate the chaff of product marketing from the value of the platform. And more importantly, can align this knowledge with customer requirements.

*For example, understanding how HR processes work, and how these processes are implemented in ServiceNow HR, has value.

Translating customer requirements into the correct platform solutions

Assuming an architect fundamentally understands the ServiceNow platform and understands when ServiceNow should or should not be used in the customer’s overall IT environment, he or she should be able to listen to business requirements and translate into the best way to achieve them in ServiceNow (assuming ServiceNow is the best place to achieve them). What this means is that the architect knows enough about the platform to determine if there is a pre-built solution that best serves the need, or if it is better served by extending platform capabilities to create a customized solution. He or she should also be able to articulate the reasons why to choose one over the other, and both speak to and document the advantages and disadvantages of both, including hard and soft costs.

Knowing and advising on best practices

The ideal architect is knowledgeable enough to not only design the correct solution, but advise on how to implement that solution. This includes advising on technical best practices. For example, when I serve as a technical architect on both projects and ongoing development in an Agile environment, my role and input includes documenting the technical approach on Stories. This is the detail of what and where to develop to satisfy the stated requirements, not necessarily the how. In other words, because there are often 3-4 ways to satisfy a requirement in ServiceNow, the architect should advise on the best way to do it based on their knowledge and experience. This is often beyond the knowledge of a developer or administrator, and beyond what can be found in ServiceNow documentation.

After reading this, you might think “but there’s too much crossover with the roles mentioned at the beginning”. And you may be right. What I’ve found in my ServiceNow journey is that it’s rare that an architect can only fulfill a pure architecture role. Most customer environments aren’t large enough to support this level of “purity” or responsibility delineation. In addition, I’ve found that you cannot provide the correct architecture decisions without some hands-on experience with the platform. Doing so leads to “book” answers without the benefit of real-work experience.

In addition to the more pure architecture I’ve listed, the best architects can also advise on practices for instance management: managing configuration and code updates through the SDLC and provide insight on how to build and maintain to simplify system upgrades (new releases). In short, the architect should be a trusted advisor to IT Management on minimizing cost and maximizing value with ServiceNow.

Coming up in part two, we’ll look at documentation and behaviors that belie the architect title.