Mastering ServiceNow - Second Edition

All the examples in the book have been recorded as Update Sets, which we discuss in detail in Chapter 10, Packaging with Applications, Update Sets, and Upgrades. The hotels application is also in a public Git repository. You can apply them to short-cut the examples. Even if you you wish to work through all the examples, I recommend applying the first one, so your scope identifier is the same as the book. It'll make copying and pasting code much easier!

You can download the Update Sets at http://www.gardiner-hotels.com. Alternatively, you can fork the Git repository available at https://github.com/gardinerhotels/hotel. More instructions are at the website.

An instance is an independent implementation of ServiceNow. It is isolated and autonomous, meaning your code and data is not shared with other customers. ServiceNow uses a single-tenancy architecture, which means your instance is yours: you can do what you want with it, such as changing logic, updating the UI, and adding fields.

Every customer has several instances-again, each isolated and independent. One instance is usually marked out for developing on, another for testing, and yet another for production. And because each instance is independent, each one can be running a different release of ServiceNow. The production instance differs by having more powerful hardware.

A new instance starts with a few ServiceNow applications, some demo configuration, and example data. This is often called the out-of-the-box state. One of the example data elements is the System Administrator user. You are able to log in and get going, getting full control immediately.

Everyone makes changes to their instance. Unless the people who will be using the system are called Beth Anglin or David Dan (some of the default example users), you'll need to load some users at the very least. Some ServiceNow customers configure a lot, and some do the bare minimum. You can choose how much you wish to do. Because it is single-tenant, you can alter the configuration and data in almost any way you see fit-now, it might not always be smart to do that, but you can!

My favorite analogy, if you haven't guessed it yet, is a building. ServiceNow gives you an office that is yours. It starts off identical, built to the standard plans, but you can redecorate or remodel as you see fit-perhaps even knock down a wall! (Let's hope it's not load bearing.) This is the benefit of single tenancy.

Multitenancy is like an apartment in a block. It is generally more efficient to pack lots of people together in a single building, and you can build it pretty high. However, you don't have the flexibility that being in control gives you. The landlords of the block won't let you knock down a wall!

The vast majority of customers have their instance hosted by ServiceNow. This means that the people who built the house will also look after it, on their land. You get great economies of scale and the benefit of tools and automation design to perform maintenance and give support fast. All the gardeners and janitors are on site, ready to work-they don't need to travel to help out.

The heart of ServiceNow is the platform. This is a series of data, logic, and user interface layers, combined to provide a high-level environment that makes it really easy to build workflow and forms-based business applications. If you like, the platform takes raw materials and develops them into building blocks. You then plug them together to create what you need.

ServiceNow has already done a lot of building work. Prebuilt applications are available to perform service management, such as IT, HR, and facilities. Managing IT infrastructure is made easier with the ServiceWatch suite, while the needs of the business are helped with demand, project, and vendor management.

When you know how the platform works, you can more quickly use and support the applications built upon it. And, of course, you can build your own. Understanding the platform will help you in all respects-which is the focus of this book.

All ServiceNow functionalities are delivered as plugins. When an instance is turned on, one of its first tasks is to load all the plugins that are turned on out of the box. There are quite a few of those: over 200 in the Helsinki version of ServiceNow. And there are several hundred more that you can turn on if you want. A plugin may provide an app, such as HR Service Management, or provide new platform functionality, such as domain separation.

When a plugin is turned on, all the data and configuration that the application needs is loaded into the database, meaning that it is ready for work in just a few moments. Many also contain demo data, giving you examples of how it could work.

Each new version of ServiceNow brings new and improved applications and enhancements to the platform. These are packaged as updates to plugins.

ServiceNow tends to release twice a year, meaning it can be quite a task to keep up with the latest version! This book is written for the Helsinki version of ServiceNow, though most of the information is relevant for newer and older versions.

Aside from improved functionality and bug fixes, ServiceNow often creates improvements to the user interface. An instance provisioned with the Helsinki version of ServiceNow uses UI16 by default. The screenshots in this book show UI16, so if you use a different interface (perhaps for browser compatibility reasons or because of a different version), things may look slightly different, and all of the features may not work the same.

A typical ServiceNow-hosted instance is split over two physical datacenters, forming a high-availability pair. Each location runs independently of the other, creating a semi-clustered environment. In the event of a catastrophic disaster with one location being completely unavailable, the other nodes will just pick up the load, with almost no downtime. In fact, the process of switching between locations is used for maintenance procedures, enabling your instance to be well protected against hardware and other failures.

When you visit your instance, you are directed through several layers:

From an architectural perspective, a ServiceNow instance is made up of several application and database servers or nodes. These generally run on shared hardware, meaning although your instance is logically separate and independent, it is physically hosted alongside another customer. At each location, there are generally at least two application nodes, each running a copy of the ServiceNow platform and working together to share load. Additionally, there may be worker nodes installed to process the noninteractive jobs, such as sending out e-mails or dealing with integrations. Even though you'll never directly log in to these worker nodes, they perform some background processing, allowing the interactive application servers to respond more quickly to user requests. While there are generally lots of application nodes, there is only one active database server, running on a separate physical server. It does have a redundant pair hosted in the remote datacenter.

One of the first things that many people learn how to do in ServiceNow is to add a field. This is a straightforward operation: you add the new field to a form or list using the UI. Under the hood, the ServiceNow platform performs, among other operations, a simple SQL command to add a column to the table you are manipulating. When you add a field, you add a column to the table. When you remove a field, you drop it. There is no magic-the platform interface just makes it easy to do.

In order to work through the ServiceNow functionality, we will build a hotel management application for your new employer, Gardiner Hotels. It will involve building a simple data structure, but one that is highly interlinked.

Here is a representation of the tables we will create in this and the following chapters:

Firstly, let's create an app to hold our configuration in. Applications are a container for custom configuration in ServiceNow. It's a great place to capture our work and keep everything we do logically separate. Depending on what configuration you do with it, there may be licensing implications to deploying it in production. But this application will stay safely on our sandbox developer system. Applications are discussed in more detail in the next chapter, and in Chapter 10, Packaging with Applications, Update sets, and Upgrades.

Throughout this book there will be examples to show off features of ServiceNow. To make them as easy to follow as possible, it's best to use the same application scope as me. To make this possible, you should import the very starting point of my Hotel application. At the moment, it's an empty shell.

The easiest way to import the application is through an Update Set. Follow these steps:

Adding fields

Let's inspect the table that was just created. Navigate again to System Definition > Tables. Helsinki comes with over 2,000 different data tables, and all of them can be seen here. But we are only after one of them. Find Check-in (sort by Updated or filter the list) to see what has been made.

When you create a new table, you get some system fields. You may need to scroll down the Table form to see them. They include two dates (when a record was created and when it was last updated), two string fields (containing the user ID of who created it and who updated it), a unique GUID called sys_id, and a field that counts the number of updates to the record. They are all updated automatically, and it is generally good practice to leave them alone. They are useful just as they are!

The following screenshot shows how the system fields are represented within the tables:

Tip

The autogenerated fields are very helpful to the system administrator for finding records quickly. I always add the Updated on field to my lists, since it makes finding the records I've been working on (such as scripts) much faster.

In addition to these automatic fields, we need to create some of our own. We will need several, but right now, let's create something to store any requests that the guest may have. Perhaps they may have specifically requested a high floor. Scroll down the table form, and create a new field called Comments by double-clicking on Insert a new row.... Fill out the row, and save the record by clicking on the Update button. Either use the Tab key or double-click to enter the following data:

• Column label: Comments

• Type: String

• Max length: 500

The following screenshot displays how the list of columns looks before saving the changes:

ALTER TABLE x_hotel_check_in ADD `comments` MEDIUMTEXT

The dictionary is a metatable. It describes your table and fields-their names, how big they are, and any special attributes they may have, similar to information_schema views. For example, one field might be dependent upon another. A dictionary entry might also be referred to as an element descriptor, since it describes the how the field (or element) works.

The table is represented by an entry in the dictionary with a table value, type of Collection, and no column name. When the Comments field was added to the Check-in table, the platform also made a dictionary entry with the table and a column name. You can view it if you want by navigating to System Definition > Dictionary.

The options that are available in the dictionary depend on the type of field you are working with. Reference fields, which we will explore in a moment, have extra functionality that is controlled here, such as dynamic creation.

As we work through ServiceNow, we'll spot functionality that is enabled through the dictionary. However, much of it can be achieved in other ways, often in a better manner.

Older versions of ServiceNow have a read-only tick box available in the dictionary form by default. While it's included and can be used in later versions, it is a better idea to use security rules instead. They give you much more granularity and control than a binary checkbox. We will explore security rules in Chapter 7, Exchanging Data.

The ServiceNow database is a relational database. This means that one data element can relate to another. To ensure that every record or row can be referenced easily, every record has a unique identifier: a primary key.

In ServiceNow, this primary key is something that isn't related to the data itself. It is a globally unique identifier or GUID. This GUID is stored as a 32-character string, made of hexadecimal characters (the numbers 0-9 plus the letters a-f). The number of unique GUID values is so large that the probability of two accidently being the same is negligible. This is an example GUID: 5137153cc611227c000bbd1bd8cd2005.

Whenever you create a record in ServiceNow, the platform generates a new GUID. The characters generated are random-a mixture of several sources, including the date and time and details specific to the instance, meaning they're not sequential or predictable. The GUID is saved alongside the record, in a special field called sys_id. The sys_id field is heavily used in the ServiceNow platform-you will start seeing GUIDs everywhere!

As an example of how ServiceNow uses the sys_id field, conduct the following experiment: construct a URL similar to the one that follows, substituting <instance> with the name of your instance, and visit it with your browser: https://<instance>.service-now.com/sys_user.do?sys_id=5137153cc611227c000bbd1bd8cd2005.

In the new instance, you should happen across the user record of Fred Luddy (if the demo data has been removed, you will get a Record not found message).

It is useful to examine the structure of the URL. First, spot the sys_user table. Then, spot the GUID. With these two items, the instance knows exactly what data it needs to pull up and present to you.

Every record has a sys_id field. It is the only field that ServiceNow really cares about. It also looks after itself. You don't need to worry about it during day-to-day operations.

Every other field is optional and non-unique to the database platform. You can have two records that are otherwise identical but only have a differing sys_id field. (It is possible to enforce uniqueness in other fields too, as we'll see later.)

This means that, in general, you can change the value of fields to whatever you like and still maintain referential integrity; no system errors will occur. If you want to rename a user or a group, go ahead. Since everything related to that user will be associated to the user via the sys_id field, the user's name is not important.

Many other products do not use surrogate keys; data is linked together using user-provided data. If you change the name of a group, for example, this could remove all group memberships and task assignment. Not in ServiceNow, though!

It is a good idea not to interfere with this flexibility. When building functionality, don't refer to records using their names or sys_id values in scripts. Instead, use the properties or attributes of the record itself to identify it. So, rather than hardcoding the condition that a particular room in our hotel needs special treatment, create another field and use it as a flag. The VIP flag on the User table is a good example of this.

In addition to text, ServiceNow can also store binary data. This means that anything (images, music, or even a multitude of PowerPoint documents) can be saved in ServiceNow. Just like everything else, binary data is stored in the database. However, rather than using a BLOB field, binary data is split into 4-KB chunks and saved into the Attachment Documents (sys_attachment_doc) table. Each chunk of a file refers back to the Attachments (sys_attachment) table, where the filename, content type and size, and other metadata are stored.

A file is always related to another record (this is why they are referred to as attachments). Information on this other record is stored with the other metadata in the Attachments table. For example, if a record had a PDF of the booking form attached to it, the Attachment record would contain the filename of the document as well as the sys_id of the Reservation record.

One of the simplest ways to control the platform is to set properties. There are lots of things you can change by just clicking on a box or changing a value. And just like everything else in ServiceNow, the configuration properties that you set are stored in a table-the System Properties [sys_properties] table to be precise.

To see how many options you can choose, type Properties in the filter-text box of the application navigator. Many matches will be shown, including System Properties > UI Properties. This collection contains some very useful options, including how forms look and feel, whether list editing is enabled, and whether Insert and Stay is always available. You may want to spend some time and find out what they do.

Some properties are not categorized, but all are accessible by typing sys_properties.list in the filter-text box of the application navigator. This will give you a large list-over 1000 in Helsinki.

Let's think about something that the hotel application needs-a room directory. Each room has several attributes that defines it: its room number, how many beds it has, and which floor it is on. We can represent this information as fields in a Room record, all stored in a dedicated table.

We also need to store guest information. When designing a data structure, it's a good idea to reuse functionality wherever possible. ServiceNow already has a table that stores information about people: the user table. Let's use that for now to store guest information.

Once we have these items in place, we can modify the Check-in table to record which room has been taken by which guest.

Building out the data structure

Let's create the tables and fields we need step by step. Let's start with the Room table first.

1. Return to System Definition > Tables to create another new table. Use the New button on the list. Fill out fields as follows, click on the menu button, and then click on Save (don't click on Submit!):

   • Label: Room

   • Add module to menu: Hotel

   

   Tip

   I suggest using the Save button, accessible via the three-line menu icon (or right clicking on the header) rather than using Submit to commit records to the database. This ensures that the updated record is shown on screen after saving rather than redirecting to the previous page, like Submit does.

2. Now create a field to store the room number by scrolling down the Columns tab to Insert a new Row. Double-click again to enter the information.

   • Column label: Number

Note

Don't use the auto-number option; create a new field using the related list.

We need another field to store the floor it is located on:

• Column label: Floor

• Type: Integer

The final result should look like this:

1. Use Save to make the changes in the database.

2. Let's see what we've created. When we created the table, ServiceNow also created a module in the Hotel application menu that will show us all the room data in the instance. Navigate to Hotel > Rooms. You shouldn't be surprised to see No records to display- we haven't created any yet!

3. Using the New button, create a few example records, giving each one a different number. Make several on the same floor. One of them could be Room 101 on the first floor. As you do so, try using the Save and Submit buttons, and notice the difference between them.

Note that the platform does not force you to choose different numbers for each record. Unless you mark a field as unique or create a rule to check, the platform will allow you to create them.

Tip

To mark a field as unique, you can edit the dictionary entry of that field (you will need to configure the dictionary form and add the Unique checkbox). By ticking that field, you are asking the database to enforce it. It does this by making that field a unique key. This has two impacts. It creates an index on that field, which is good. However, if a user attempts to save a duplicate value, they will get a message saying Unique Key violation detected by database. This can be a little jarring for a non-technical user. Try to catch the error with a Business Rule first.

Linking the data together

Now that we have a list of rooms, we need to create the link between the Room and Check-in records.

A reference field can be referred to as a one-to-many relationship. This is because a room may be checked in to multiple times (you might have one particular guest one day, and the next day, another might sleep in the same room after our fabulous cleaners have done their work), but for a single check-in, you can only select one room. You can only sleep in one bed at a time!

Tip

A classic example of a one-to-many relationship is between a mother and her children. A child can only have one biological mother, but a mother can have many children.

The following diagram shows the relationship needed between the Room and Check-in records:

1. Go back to System Definition > Tables and find the Check-in table. Once there, create two new reference fields-one will be for the room, using the following data:

   • Column label: Room

   • Type: Reference

   • Reference: Room

     The other will be for the guest:

   • Column label: Guest

   • Type: Reference

   • Reference: User [sys_user]-be careful to select the right one here!

2. Save your changes.

3. Now is a good time to rearrange the new fields on the form so that they look good. To do this, click on Design Form in the Related Links section near the bottom of the form. It'll open a new tab or window.

4. Once in the form designer, drag the section containing the Room and Guest fields above Comments. Then, click on Save, and close the tab. If you have trouble, try using Form Layout, and move Comments to the bottom of the list, so it is under Guest and Room. The form should end up looking like the next screenshot.

5. Now, create a few example Check-in records. To simulate someone going into room 101, create a new entry in the Check-in table by navigating to Hotel > Check-in, and clicking New. Populate both the Guest and Room fields, and then click on Submit:

By default, a reference field can select from any record in the referenced table. However, often, you want to filter the results. For example, you may want to specify a guest as inactive, perhaps representing someone who won't be visiting Gardiner Hotels any longer. Therefore, let's filter out inactive users so they cannot be inadvertently checked in.

Reference qualifiers allow you to do this. When you edit the dictionary entry of a reference field, you can specify the filter you want to apply. These can be specified in three different ways:

For our Hotel application, let's use a simple reference qualifier. Navigate to Hotel > Check-In, and select a record. Right-click on the Guest field label, and choose Configure Dictionary. Fill out the fields as below, and Save.

Now, if you mark a user as inactive (by unchecking the Active checkbox and saving), they cannot be selected when checking in, neither through the magnifying-glass lookup window, nor using the type-ahead functionality.

Dot-walking is a very important concept in ServiceNow. It means you can access information through reference fields quickly and easily. It can be leveraged throughout ServiceNow-both through the interface and through code.

You've already used dot-walking. When you hover over the reference icon, you can see information from that record. That's the whole concept! We are using the platform's capability to "see through" reference fields and pull out information from that record. And, as we'll see in Chapter 3, Server-Side Control the same is possible through code.

Lists show several records in a table, line by line. Pretty obvious, but let's break out of the frames and examine some URLs again. Remember how we navigated to a specific record in a field? Let's instead show a list of User records. The table name is suffixed with _list, with the usual .do. Here's an example:

http://<instance>.service-now.com/sys_user_list.do.

We've already seen that the sys_id value can be used as a parameter to immediately jump to a record. There are other parameters that are useful, too. Here's an example that shows how you can specify a database query through a URL:

http://<instance>.service- now.com/sys_user_list.do?sysparm_query=user_name=fred.luddy.

If you navigate to this URL, you will be presented with a list of the records that match this query. If you remove the _list part from the URL, you will be presented with the first record that matches.

These URLs do not open up the familiar navigation interface, but simply show the content. You may want to have multiple browser tabs open, without the clutter to get in your way. Edit the URL directly, and get to where you want to go quickly. If you must have the Application Navigator and it's friends, try http://<instance>.service-now.com/nav_to.do?uri=sys_user_list.do.

In contrast to the simple concept of lists, a form generally contains more detailed information. It is where users usually interact with the data.

Try not to break away from the convention of having two columns of fields, with the labels to the left. Although it might be considered plain, it also means the forms are consistent, easy to read, and relatively uncluttered. The emphasis should therefore be on creating logic and a process to control the data while keeping the interface simple.

Annotations allow you to add text and even HTML to forms. They are especially useful for adding simple work instructions, but be careful to ensure that the forms don't get cluttered.

Finally, formatters allow you to include Jelly in your form. Rather than being a sugary treat, Jelly is a scriptable language used to build the ServiceNow interface. Chapter 11, Making ServiceNow Beautiful with Service Portal and Custom Interfaces, discusses custom interfaces in more detail.

If you find that you need to include lots of fields in a form or list, consider using views. They enable you to present a different set of elements specific to a situation. For example, in our hotel, a guest may be enrolled in our points program. In that case, we may want two views of user records: a simple uncluttered view for one-time guests (containing the minimum amount of information required to load quickly and without extraneous data) and a more detailed view for frequent visitors (containing extra information to help serve them better).

A system administrator (or a user with the view_changer role) can change views by clicking on the name of the table and choosing View. Otherwise, the view for the record is set through rules, through the view specified in the module link in the application menu to the left, or it is inherited.

To help you navigate applications in ServiceNow, the interface provides you with the application navigator-or, as I like to call it, "the menu to the left". At its heart, this is a series of links to either forms or lists of data. They can specify a view name directly, and lists can include a filter, enabling you to decide exactly what the user sees upon clicking on it. This gives you a great deal of control.

Do you lose things? Me too. I lose my hotel key all the time. Perhaps you are writing several difficult scripts that you want just a couple of clicks away, or you need to quickly navigate to a User record. Tags are a way to collect arbitrary records together, making them easy to find, while favorites let you save links very easily. History follows you about, so you can easily go back to where you were.

Connect is the way to be social with ServiceNow. It provides a real-time chat and messaging system that lets you send files, mention users, and get work done together. The idea of user presence extends even to the form, to encourage collaboration rather than conflict.

Connect uses the HTML5 notifications API to alert you about new messages, even when you aren’t actively using your browser. The method depends on your browser and OS, but typically, a little message appears in the top-right corner of your screen. This means that even if you have switched tabs away from ServiceNow at that moment, you can still be alerted that your colleague has found a new cat video.

Chatting over records

Opening the Connect sidebar is the first step. Click on the Connect icon near your name in the top right to see the sidebar. From here, you can add people from the user table and start a conversation, adding more people to make group chats. If you aren't around when someone starts chatting to you, ServiceNow can alert you through your browser or send an e-mail notification.

While Connect, and instant messaging, is freeform by nature, chatting about the recent political scandal won't help Gardiner Hotels serve guests better. To focus on the topic, you can use Connect in association with records that exist in the database. The staff at Gardiner Hotels love to discuss the peculiarities of the unique rooms, so let's enable conversation recording for the Room table. This is done by setting an attribute on the Room table's dictionary entry.

1. Navigate to System Definition > Tables (you set a favorite, right?), find the Room entry and open up the record.

2. Then, use the Menu button, and click on Show Dictionary Record.

3. Under Related Links, click on Advanced view.

4. Edit the Attributes field as follows, and Save.

   Attributes: live_feed=true (If hasLabels=true is already there, append with live_feed=true, separating the two with a comma.)

To see Connect in action, navigate to a Room record. There should now be a Follow button. Interested employees at Gardiner Hotel can now follow a room and chat about it.

Live record updates

The idea of working together extends to UI16's ability to show live record updates when two users change details at the same time. This incredibly powerful capability lets users identify whether they are working together and, if not, to start a chat conversation to work things out.

To see how this works, you need two sessions open. The easiest way for a single person to do this is to open a new browser window in private browsing mode(might be called Incognito) and log in again. If possible, and for maximum realism, use another user account, perhaps even another computer!

In both browsers, navigate to the same record-perhaps Room 101. When both of you are there, you should see the profile picture of the other user in the record header at the top of the form. Instantly, you'll know someone else is viewing the same record. In the screenshot below, David Loo is viewing the same record as me.

Next, in one of the browsers, make a change to a field in a record, such as altering the floor number, and click on Save. In the other browser window, a little blue circle will appear and the value of the field will be updated, giving them the latest data. Wow!

If the two users disagree on the update, a Connect chat session is the perfect way to resolve it!