Mastering Servicenow Administration Pdf Free Download

Chapter 1. ServiceNow Foundations

This opening chapter lays out the foundational aspects of ServiceNow, from the bottom up. Understanding the fundamentals of the ServiceNow platform is important. It provides insight into the concepts that determine how all the applications built on top work.

Tip

Although long, the chapter is not exhaustive and expects basic familiarity with the ServiceNow interface. Remember to refer to the ServiceNow documentation and any training material you may have.

Perhaps you've decided to build a new hotel, and you want to ensure it won't fall down. The architect's drawings need to be understood and the right building materials ordered. It's costly (and career limiting!) if it collapses in the opening week!

In this chapter, we review the blueprints. We will understand the important design aspects of ServiceNow so that we can build on them later. The data structure available to us is critical, since it enables us to model information and processes in the right way.

In this chapter, we will cover:

The physical components of the ServiceNow architecture
How everything you see and do is in the database
A review of the most important field types
The magic of reference fields
Using and building a good interface

Diving into the infrastructure

An instance is several things. It could be part of a URL (something like https://<instance>.service-now.com/), software running in the cloud, or your copy of the ServiceNow platform.

ServiceNow provides a platform and suite of applications as a service. They worry about the hardware, Internet connectivity, and operating system security, and provide you with the URL. All you need to get going is a modern web browser.

To follow the examples in this book, you need admin access to an instance. It'll be better if you have your own, dedicated instance rather than one being used by many people. It allows you to make system-wide configuration changes, and you won't affect anyone else.

Note

It is especially important not to use the production instance assigned to your company. This book uses the examples to teach you about ServiceNow, and you will not want all of these experiments being used by your whole company.

ServiceNow runs a developer program, through which you can obtain your own instance. It is lower powered and restricted in capabilities compared to normal instances, but it is an excellent resource to test out ideas. Be sure to read the FAQ to understand the limitations.

You can access the developer program at https://developer.servicenow.com.

Keeping up with the examples

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.

Being in charge

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.

Tip

ServiceNow's greatest advantage is also its biggest disadvantage. The power and flexibility can be intoxicating! Just because you can do what you want, doesn't mean you should it! This is discussed in detail throughout the book.

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.

Note

Chapter 9, Diagnosing ServiceNow – Knowing What is Going On , discusses how you can use your instances for tasks such as building functionality, testing it, and then making it live.

Changing your instance

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.

Knowing the platform

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.

Choosing functionalities with plugins

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.

Note

Chapter 9, Diagnosing ServiceNow – Knowing What is Going On , talks about plugins and upgrading ServiceNow in more detail.

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.

Running the latest version

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.

Digging into the hosting

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.

Note

The free developer instances are not replicated, and run only on a single node. A customer's production instance has many more resources!

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

By looking up DNS records, you are directed to the currently active datacenter for your instance.
The load balancer, by reading a cookie, directs you to the application server you have your session with.
If you aren't logged in, you get directed to the least busy application server.
Your application server then uses the database currently determined as active.

Knowing the nodes

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.

Tip

Chapter 5, Getting Things Done with Tasks , explores the concept of event queues in more detail.

Exploring the database

So you've got an instance and have logged in. Great! What can we see? The answer: database records.

Almost everything in ServiceNow is an entry in a database. When you look at the user interface, virtually everything you see-from the data typed in by a user to log files and how the views are structured-is stored in the instance's relational database. The scripts you write are kept in a string field, and the files you attach to records are stored in chunks, all in the database.

All this data is organized into many tables . A table is a collection of records, with each record being a row. A field is a column in that table.

Everything is built on top of this structure. You don't need to reboot the server to apply new functionality; you just update data records. You don't need to reload configuration files-any properties you set will be read on the next operation. Even the database metadata-information about the fields themselves-is stored in another table.

This gives you a great deal of control. You organize, configure, and manage almost everything the same way, searching for a script like you search for users: by simply querying the right table. This means you can focus on designing and building great business applications, since the platform just works.

Tip

ServiceNow may be considered a high-level platform based on the Model-view-controller ( MVC ) concept. When building a ServiceNow application, you can first think of the data structure. You determine what information you need to store and how it all links together, creating tables and fields. This is the model aspect.

Automatically, you get a simple view of this data, with forms and lists showing your information.

You can then build simple ways to manipulate and change the data, through automation and simple manual updates, giving you the controller .

Introducing the Gardiner Hotel data structure

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.

Tip

ServiceNow allows you to add fields to every table in the system. If you decide that adding another is a good idea, you have the power to do so!

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:

Guests : The reason Gardiner Hotels exists! Our guests' details are the most important information we have. We definitely need their names and, optionally, their e-mail addresses and phone numbers.
Room : This details where our guests will sleep. We store the room number and the floor it is on.
Check-in : When guests want their room key, they check in. We record who checked in to a room and when and who made the entry.

We will create a link to the Room table so we can easily see information about the room, such as which floor it is on.
Reservation : Our guests like staying with us, and they often book months in advance. One reservation might be for many guests, especially if an entire family is coming. A big family might need a big room. We need to record where exactly they might stay.

Note

Over the course of the book, we will expand and further develop the application. Its primary use is to show you as much of the capability of ServiceNow as possible, so some of the examples may be better done in other ways.

Creating tables

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:

Download the Update Set from https://www.gardiner-hotels.com/sets/00-HotelApp.xml Save it to disk.
Navigate to System Update Sets > Retrieved Update Sets . Click Import Update Set from XML .

Tip

The convention for navigating through ServiceNow uses the following structure: Application Menu > Module . For modules with separators, it will be Application Menu > Section > Module . The easiest way to find a particular link is to type it in the Application Filter field at the top-left corner of the menu. Make sure you are choosing the right one, though, because some modules are identically named.
Click the Browse button, and choose the XML file you downloaded. Click Upload .
Click on the Hotel Bootstrap record, then click on the Preview Update Set button.
Once analyzed, click on Commit Update Set . Click Close once done.
If you navigate to System Applications > Applications , you should see the Hotel entry in the list.
Now, let's create our first table. Navigate to System Definition > Tables, and click New.
Fill in the following values, and click on Create , then OK to confirm. Some fields (like Name ) will automatically populate.
- Label : Check-in
- New menu name : Hotel
Note

Notice the auto-generated table name. If you imported the Update Set, the name should be x_hotel_check_in. It's made up of several parts: the vendor prefix, the application name, and the table name itself. More about this in Chapter 2, Developing Custom Applications .
Click on Submit to create the table.

Tip

Many technical items in ServiceNow have a label and name that are used in the database and in scripts. In this case, the database table is called x_hotel_check_in, while an entry in the Field Labels (sys_documentation) table contains the mapping between the name and the label. I'll use the Label (database_name) format throughout the book.

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:

Knowing what's happening

Once you've clicked the Update button, the instance gets busy. Behind the scenes, the application server is running SQL commands against the database. Specifically, at the time of creating the field, the following is executed:

ALTER TABLE x_hotel_check_in ADD `comments` MEDIUMTEXT

Tip

If you wish to see these commands, navigate to System Diagnostics > Debug SQL . This will place lots of information at the bottom of the page. Other diagnostic tools such as this are discussed in Chapter 8, Securing Applications and Data .

This demonstrates a key concept: whenever you perform an action in ServiceNow, it results in a string of database commands. The database is altered and the platform's internal state is updated. These actions are generally carried out quickly, with the whole process completed in about half a second. No downtime is necessary.

Introducing the dictionary

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 .

Tip

The easiest way to navigate to a dictionary entry is by right-clicking on the label of the field (not the text-entry box) and choosing Configure Dictionary . You can see some details about a field, such as which table it is in, by choosing the Show option from the menu that appears on right-clicking.

The globally unique identifier

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.

Tip

This type of identifier is sometimes known as an OID or object identifier. It has no special significance; it just uniquely identifies a data row. It can also be called a surrogate key.

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

Tip

If the system sees -1 as a sys_id, it'll assume it is a new record, and will generate a new GUID.

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.

Note

Reference fields, as we'll see, are very reliant upon the sys_id fields. When we get into scripting in Chapter 2, Developing Custom Applications , you'll be seeing more of them.

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!

Tip

An important exception to this behavior is with roles. Roles are referred to by name in scripts, so if you change the name, all scripts that use it will need to be altered (though security rules do refer to the role through the sys_id field). In general, it is a good idea to keep the names of roles the same.

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.

Storing data

There are various types of fields provided by the ServiceNow platform. We will explore some of the simpler ones before moving on to the fundamental backbone of the data structure with reference fields:

String : These fields are simple text fields. The UI displays a string field as an editable text box. If the Max length attribute in the dictionary is more than 255, then a multiline field is shown. Most fields in ServiceNow are enhanced versions of the string field.
Choice : These fields are string fields, but rendered as HTML select fields. The value that is stored in the database is plain text. Another table, the Choices [sys_choice] table, stores the options and labels. This lets the platform convert wip in the database to present Work in Progress to the user. Any values that don't have a label are highlighted in blue in the dropdown.
Integer choice : These fields use numbers instead of text to achieve the same result as normal choice fields. They are useful for representing states, since they allow you to use greater-than or less-than conditions, but they have proven difficult to work with since the numbers don't mean much!

Tip

Use caution when dealing with the out-of-the-box integer choice fields, such as State on the Task table. If you reuse them (which is a good idea), you should always align your states to the existing ones. For example, 3 should represent Closed. If you do not align them, then users will be confused when reporting. This is discussed in detail in Chapter 4, Client-Side Interaction .
Date : There are several date fields in ServiceNow. The time is stored as UTC in the database, and the appropriate display value is calculated by the user's profile.
Currency : These are string fields that combine the currency and amount. USD;1000 represents $1,000. The platform uses this information to provide conversions between different currencies. For example, if I prefer to see amounts in GBP, the platform will, if it has the latest currency rates, display £675 .
True/false : These fields are simple boolean values in the database. They are rendered as tick boxes.
URL : These fields provide space to enter a link, which can toggled to be clickable.
Email : Similar to URL, the email field lets you type an e-mail address and provides a button to launch your e-mail client through a mailto: link.
HTML and Wikitext : Other fields, such as these, provide different interfaces to manipulate strings. It is tempting to use HTML fields in lots of places, but they do come with overhead, and browsers have different capabilities. Test carefully if you want to use capabilities such as these.

Storing files as attachments

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.

Tip

We'll see in later chapters that there are often better ways than manually adding attachments containing booking information. Why not have the e-mail come directly into ServiceNow? (We'll see how in Chapter 5, Getting Things Done with Tasks .) Or, even better, why not have the guests perform the booking directly with ServiceNow? (Chapter 10, Packaging with Applications, Update Sets, and Upgrades , will show us how to do this.)

Setting properties

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 [s ys_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.

Reference fields

When designing the data structure for a hotel, you want to know which room a guest has checked in to. It won't be good for business if we don't know who is sleeping where! This is exactly what a reference field does: it creates a link between two records, one pointing to another.

When we examined the URLs earlier, we saw they contained two parts: the table and the sys_id value of the record. These are the two items needed to reference a record. So when you create a reference field, you need to select which table it should point to, which is stored in the dictionary. And the contents of the field will be a 32-character string. Sound familiar? Yep, you will be storing a sys_id in that field.

Reference fields are one of the most important items to understand in ServiceNow. The database sees a string field containing the sys_id value, a foreign key. However, this is meaningless to a person. Therefore, the platform allows you to pick a field that will be displayed. For a person, this might be their name. Other records might have a user-friendly reference number, like TSK0001. This is usually an incremental number-there are scripts that generate one automatically. You can choose which field to show by ticking the Display field in the Dictionary entry. But remember: only the sys_id value is important to the platform.

Reference fields are used throughout ServiceNow, just like a proper relational system should be. Scripting, lists, and forms all understand references fields, as we'll see while we work through the chapters.

Creating a reference field

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.

Tip

It is sometimes a difficult decision to should reuse an existing table. The benefits are obvious: you save time from not duplicating work, both in configuration and maintenance. But sometimes, you need the table to work slightly differently for two different scenarios. We'll see one way to deal with this in Chapter 2, Developing Custom Applications .

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.

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

Use Save to make the changes in the database.
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!
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:

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!
Save your changes.
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.
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.
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 :

Looking from different perspectives

You can view the relationship between Room and Check-in entities from both directions. If you are on the Check-in form, you can see which room is in use through the reference field. The reference icon is very useful for viewing more details about the record-just hover over it.

Tip

If you hold down the Shift key while you move your cursor over the reference icon and then go into the pop-up window, the information will remain until you click on the Close button. This is quite useful when copying data from that record without losing position.

You can easily view the relationship from the other perspective, too. When you create a reference field, you can add a related list to the form, or a list of the referenced tables. This will let you see all the records that are pointing to it.

Navigate to Hotel > Rooms, and select a room that you have created a check-in record for. (I made one for room 101 for David Loo, as above.) On the Room form, click on the menu button (or right-click on the header bar), and then go to Configure > Related Lists . The one we want will be named in this format: table->field-in our case, it's Check-in > Room . Add that to Selected list, and click Save .
To make things look better, right-click on the list headings, go to Configure > List Layout , and remove Comments . Click Save .

The related list gives you a New button. When you click on it, you will see the Check-in form but with the reference field already filled in. So, if we know which room we want to check a guest in to, we can navigate to the Room record, click on the New button in the Check-in related list, and need not type in the room number again.

Using reference qualifiers

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:

Simple : This lets you specify which records should be returned using a condition builder.

Tip

Simple is the default reference qualifier. Click on Advanced view in Related Links to see the other options.
Dynamic : This lets you pick from prebuilt scripts. The choices they provide often differ depending on the context of the record or the session. A good example is Me , one of the dynamic filter options. This will return whoever is currently logged in, meaning that users who use the reference field will have personalized results. A dynamic filter option is the most reusable

Tip

You can build your own dynamic filter options by navigating to System Definition > Dynamic Filter Options . This will be covered in Chapter 2, Developing Custom Applications .
Advanced : This is the original way of creating reference qualifiers. It accepts an encoded query. JavaScript can be embedded in these queries, by prefixing them with javascript.

Tip

An encoded query is a field-operator-value triplet, separated by the caret (^) symbol. This string represents part of the where clause of the resulting SQL query. For example, active=true specifies all records where the active field is true, while active=true^last_name=Smith represents active being ticked and the contents of the last_name field being Smith.

One easy way to obtain an encoded query is to build a filter in the list view, right-click on the result, and choose Copy Query .

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 .

Reference qual condition : Active - is - true.

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 through data

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.

Using derived fields

Dot-walking can be used throughout the user interface. Another example is adding derived fields to lists, forms, and queries. A derived field is a field from another record that is found through a reference field.

For example, we could add the floor number of the room to the check-in form as a derived field. The floor number doesn't belong to the check-in record, and if we change the room on the form, the system will dynamically change the floor number displayed.

Note

With scripting, you have the option to copy data through the reference field onto the record you are dealing with. That data then becomes part of the record. Derived fields will exist through the link only.

This concept is important to understand. If the referenced record gets deleted or changed, it will then affect our current record. For example, if we delete the room record, the check-in form won't be able to show which floor it is on. If we change the floor value on the room record, our check-in form will show the new value.

The simplest example of derived information is the display value, which was mentioned earlier. If the display value of the referenced record changes, you'll see it altered everywhere. Since sys_id is the primary key for a record, you can easily rename groups, alter the names of users, or update virtually any record without penalty.

Navigate to the Check-in form ( Hotel > Check-in , then choose a record) . Use the menu icon and choose Configure > Form Layout .

Tip

Derived fields can only be added via Form Layout (rather than Form Design )

Even though the Room field has already been added to the form, it is still in the "available" list. It should have [+] as a suffix to the field name, showing it is a reference field that can be dot-walked to, for example, Room [+] .
On selecting it and clicking on the Expand selected reference field icon, you get to see the fields in the Room table. Choose the Floor field, and add it to the form. It should be labeled Room.Floor , showing that you are dot-walking. Click on Save .

The Check-in form should now have several fields in it: the Room reference field, the Floor derived field, and a simple Comments field. Here they are:

Tip

Notice how the Floor field is editable. If the value is changed and the Submit button is clicked on, it is actually the Room record that will be altered.

Building the interface

We've already spent some time with the ServiceNow interface. But some of the fundamentals of how the platform is used and what it provides deserve repeating.

If we rewind to our opening consideration that everything is in a database, ServiceNow provides two basic interfaces that we spend the majority of our time with: forms and lists . The form and the list are the two major views of data within ServiceNow. You can, of course, create custom user interfaces, and we'll cover those in Chapter 11, Making ServiceNow Beautiful with Service Portal and Custom Interfaces.

Lists

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.

Tip

You might be wondering what the .do extension is all about. This is the typical suffix that is used by Apache Struts, which has become the go-to framework for developing Java web applications such as ServiceNow. This provides a hint to the technologies used within the ServiceNow platform.

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.

Choosing the fields to show

A list in ServiceNow can include any of the fields that are on the table. But a list works best when you show only the most relevant information. Adding in lots of columns makes it take longer to load (more data to get from the instance, to be sent across the Internet, and parsed by your browser) and often only adds to clutter and complexity.

Tip

Typically, a good list includes something that identifies the individual record (usually a name and number and maybe a short description) and when it was last updated. If there is a categorization field, that should be included too. It is very helpful to sort or group records by these values. The Go to quick search option also allows you to search these fields.

The number of records shown on a list is configurable by the user. The system administrator sets the choices they have in UI Properties . Keep the maximum number low, again to minimize the amount of data that needs to be worked with. Setting it to 1,000 is useful to be able to perform mass deletion, but if everyone has it selected, it will impact performance.

Having reference fields on lists

Reference fields are treated slightly differently in a list view. The majority of fields are shown as simple text, but a reference field is always shown as a link to the referenced record. The first column in the list is also converted into a link, this time linking to the record itself.

Never put a reference field as the first column on a list. While the system will understand this and consequently make the second column the link to the record, it is incredibly confusing to the user. People become very used to clicking on the first column, and they expect to see that record in the list.

Tip

You can always get to the record by clicking on the icon to the left of a particular column.

The varied capabilities of lists

Users of ServiceNow often forget about the extra functionality lists provide. Functionality such as list editing and the powerful context menus (such as Show Matching when you right-click on a list) should be thought about carefully and explained to users of the system to ensure they use the interface in an efficient manner.

A hierarchical list is not used that often, but it is very powerful. It allows you to display the related lists of records in the list view. So, even while looking at the Reservations list, the guests can be inspected. You can turn on this functionality in List Control when you right-click on the headers and choose Configure .

Here are some tips to keep in mind when creating lists:

Try not to include journal, HTML, or other multiline fields in the list. They grow big and the interface truncates their display.
Think carefully about List Control . Do you want New or Edit buttons? This matters especially for related lists.
When running a query on a list, if you click on the New button, the values you searched for will be copied into the form.

Forms

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.

Creating useful forms

By following some best practices, you can make the ServiceNow interface a more pleasant place to be:

Every table needs a form, even if it is basic.
Forms should read from top to bottom, with important fields at the top left.
The reference name or number of the record is normally at the top left.
Lay out the fields in the order you'd fill them in. Users can tab between fields.
Mandatory fields should be obvious-again, usually towards the top.
Keep to the standard layout for consistency-two columns at the top and full width at the bottom.
Keep forms as short as possible. Don't include unnecessary fields. Views can be very useful for providing targeted designs.
Use annotations to create section separators (not form sections) to partition content on the page and provide a logical hierarchy or workflow of the data.
For larger forms, use form sections. These are useful for creating tabs.
Fields with multiple lines (such as descriptions or comments) should expand across the whole page, not half of it. This means they go at the bottom of the form.

Adding related and embedded lists

We've already covered related lists when discussing reference fields, but they come with a few disadvantages. Embedded lists remove some of those constraints:

Embedded lists can be placed anywhere on the form, rather than just at the bottom.
Since related lists show related records, they will only be displayed on a saved record. If it is unsaved, no records can be linked. Embedded lists will show at all times.

Embedded related lists are not always appropriate, though. They are designed to have an interface where you often create new related records with minimum information. There is no way to disable the creation of new records, for instance. Chapter 2, Developing Custom Applications has an example of embedded related lists.

Defining your own related lists

Defined related lists provide a list of any records you want at the bottom of the form. For example, a simple defined related list that lists other rooms on the same floor may be placed on the Room form. This helps you quickly navigate between them.

Note

In order to create a defined related list, we'll need to use a little JavaScript. We'll work through this in more detail in Chapter 3, Server-Side Control .

Navigate to System Definition > Relationships and click on New . Use the following details, and Save.
- Name : Rooms on the same floor
- Applies to table : Room [x_hotel_room]
- Queries from table : Room [x_hotel_room]
- Query with :
```
(function refineQuery(current, parent) {     current.addQuery('floor', parent.floor);  })(current, parent);                      
```
This code extracts records where the floor field is the same as the record we are viewing. Two JavaScript variables are being used here: current is the table you are extracting the records from and parent is the record that is being displayed in the form.
Navigate to the Room form ( Hotel > Rooms , then choose a record) and add the new related list to the form ( Configure , then Related Lists , then select Rooms on the same floor). You'll now see the other rooms listed as well-useful!

Enjoying views

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.

Tip

The view of a record is inherited as you navigate through the interface. If you follow reference links, the system will attempt to be consistent and use the same view as before. If there isn't one with the same name, it will show the default one. Be aware of this behavior when you are naming and configuring forms.

Controlling views

View rules (available under System UI > View Rules ) are a great way to force the display of a particular view. They work with a condition that uses information on the record itself. For example, you may decide to create a VIP view that shows extra fields. The VIP view is then only shown when the VIP field is ticked.

If you need more control, then create a script that can use other information to make the correct choice. A great use case for this is selecting a view based on the role of the logged-in user. Learn how to do this by going through the Special function calls section in Chapter 3, Server-side Control .

Views are often useful, but they can become frustrating. You end up managing several forms; for example, if you create a field and want it on all of them, you must repeat yourself several times and change each form separately. And since the view you are using is maintained as you navigate through the interface, be aware of which view you are editing: you may end up creating new views on forms unintentionally.

Menus and modules

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.

Tip

What is shown in the application navigator is only natively controlled by roles. However, modules, like all configurations, are stored in a database table-the sys_app_module table, to be exact. This gives rise to the possibility of restricting who sees modules in other ways. One example is creating a query business rule on this table to filter modules by group. Chapter 8 , Securing Applications and Data , explores how that is accomplished.

Setting a filter

When providing links to lists, it is a good idea to include a filter. Not only does it let you find the data you are looking for more quickly, but it also reduces the need to immediately create a filter yourself. Often, you aren't interested in records that are 6 months old, for instance, so filter them out of the link. If you always filter the list (to find guests who have recently checked in, for example), why not create a new module so you can jump straight to them?

Tip

Speak to the users of the system and understand what they are looking for. Not only can you make their interaction slightly easier, but you can also reduce the load on the instance by only displaying appropriate information. Adding modules is really easy, and it can make a dramatic difference to usability.

Let's create a new module that shows check-ins that have been made today.

Navigate to System Definition > Modules and click on New . Use these details, then Save.
- Title : Check-ins created today
- Application menu : Hotel
- Table : Check-in [x_hotel_check_in] (In the Link Type tab)
- Filter : Created - on - Today
- The menu on the left should refresh, and a new option should be available. Try out Hotel > Check-ins created today .

Building the right modules

Menus and modules should be appropriately named. The navigation filter at the top is incredibly useful for selecting from the enormous list available to you as an administrator. It is also helpful to power users. But the filter only matches on the Name parameter. For example, one of the module names that really frustrates me is the name of the link to view all the items in the system log: All . The text to find this precise entry will therefore be all. Using log or all or other strings will either produce a lot of completely irrelevant entries or nothing at all, which to me is quite unintuitive. Besides that, All is not very descriptive! Something like All log entries will help in every respect.

Making the most of the UI

ServiceNow is constantly improving the user interface to help you use the platform more effectively. The version used for fresh instances in Helsinki is UI16, and it takes advantage of modern browsers to provide a clean look while giving some really useful features, some of which are touched on here.

Old browsers (such as IE 7 and 8) can't use UI16 and default back to UI11. Instances that were upgraded from an older version must activate the plugin manually. The product documentation has much more information:

https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/navigation-and-ui/concept/c_NavigationAndTheUserInterface.html.

Finding your way around the interface

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.

Adding a favorite

The All Applications view of the application navigator is very busy, with lots of modules. Start building up some the items you use often so that you can access them quickly. Just click on the start icon next to module you use a lot in the All Applications view ( Tables in System Definition is a good one!), and it gets placed in the favorites list. Then, view it by clicking on the star icon in the Application Navigator. You can edit your favorites and change colors and icons through a link at the bottom.

Even better is the ability to drag links (usually from a list) onto the favorites panel. This saves them for one-click access.

Tip

Your favorites are displayed front and center when using your instance through the ServiceNow mobile app.

Since ServiceNow is a real web application, you can obviously add bookmarks through your browser. As you navigate through the platform, you might see the URL change in your browser change. However, you can right click both form headers and list breadcrumbs and choose Copy URL to get a cleaner, more precise link.

Seeing back in time

The history list tracks where you have been. Access it through the clock icon in the application navigator. A useful list of records and lists is shown, letting you jump backwards quickly and easily.

Defining a tag

Tags collect records together. To create one, go to a record form. Click on the "more options" button (three dots), and click on Add Tag . Type in a label, and hit enter.

Find your tags by navigating to Self-Service > My Tagged Documents . You may want to add this to your favorites!

Tag configuration is possible by going to System Definition > Tags . This includes global tags (which show for every user) and dynamic tags (which try to automate the selection of labels for you-for example, the most recently used records or records that meet a certain filter criterion).

Tags can be shared between multiple users and used for filters and in reports. There are also many ways other ways you can add tags, such as through the list context menu and inline editing. The product documentation provides more information:

https://docs.servicenow.com/use/common_ui_elements/concept/c_Tags.html.

Connecting with people

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.

Navigate to System Definition > Tables (you set a favorite, right?), find the Room entry and open up the record.
Then, use the Menu button, and click on Show Dictionary Record .
Under Related Links, click on Advanced view .
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!

Summary

This chapter explored the key design principles that ServiceNow is built on, ensuring the foundations of the platform are well understood. A ServiceNow instance is a single-tenancy design, giving you a great deal of control and independence over how the platform works for you. The architecture of the system relies upon its database to store all configuration and data, so the hosting of ServiceNow gives a redundant pair for maintenance, disaster recovery, and performance reasons.

Creating tables and fields is a fundamental part of administrating ServiceNow. There are many field types available, from strings to URLs and choice fields. The dictionary stores information about each field and can make the values of the field either unique or act as the record's display value.

In a relational system, linking records together is a key part of data design. Reference fields provide links between two records and provide a great deal of capability and configuration choice, such as the ever-useful dot-walking.

The ServiceNow interface is built on lists and forms. These relate to the database tables they display and provide a great deal of functionality, from hierarchical lists to tags and views to filtered modules. UI16 contains some great features to make it really easy to work in, such as favorites, history, Connect, and live form updates

The next chapter will build on the data structure we've started here. We will progress into some of the advanced features of ServiceNow and begin by exploring the developer studio, the one-stop shop for your application. Application scope will start coming into its own, and we will dive into some complex relationships, such as many-to-many.

Source: https://www.packtpub.com/virtualization-and-cloud/mastering-servicenow-second-edition

Posted by: salliesalliekareshnerea0251979.blogspot.com