Basic concepts for List and forms

Ganesh Pardhe · ‎05-14-2020

This article for all but specially freshers who is new to service now because when I was new to service now it was very difficult to understand the flow related forms list or configuration respect to it so base on this I have created this article to get some help from in it.

If it is worth to you please mark helpful or you can bookmark it for future reference.

Basic Concepts-Lists ,Forms and Tables.

Hello users specially fresher’s in service now this article is about basic concepts in service now, we'll discover how lists in ServicenNow are similar to tables in any other relational database, and just what exactly that means for our data. We'll learn how relationships between data are created and stored in these lists, and get a brief introduction to the data-types in ServiceNow. While we're at it, we'll also learn how to either personalize or configure how list data is displayed, and edited.

As an integral part of understanding data structures in ServiceNow, we'll also learn about forms and form views, the types of data that you'll see in forms and lists, and how to personalize or configure what data shows up where.

In this article, you'll also learn how to create a custom table as part of the foundation for your first application: a virtual war room for major incidents. This application will be used to demonstrate various pieces of functionality throughout the ServiceNow platform for the earlier chapters of this book, so it would be a good idea to follow along!

Remember: lists are where data is displayed, and forms are where work is done in ServiceNow. As you might imagine, there's a lot to say about them! In this article, we'll learn about the following topics:

The list view, and list components
List v2 vs. List v3
Creating custom tables
Creating update sets to track your work within tables (and elsewhere)
Adding fields, and filtering tables

In Helsinki and later versions of ServiceNow, there are two versions of lists available: List v2, and List v3. For the most part, we'll use the example of List v3 in this book, but will attempt to call out important differences in case you're on List v2. If it's not already active, you can activate the List v3 plug in from System Definition | Plug ins.

List v2 versus List v3

Before we get into a deep discussion about tables and how they work, you should be aware that there are two common versions of the list view in use presently: List v2, and List v3. You can see if the List v3 plugin is enabled in your instance, by going to System Definition | Plugins, and searching for the term list. If it is enabled, the Status column will show Active with a little green circle. Otherwise, it'll just show Inactive.

While List v3 is the latest generation and thus, what we're going to focus on in this book, it is important to understand List v2 as well. This is because all embedded lists, list reports, and lists for tables that have hierarchical lists enabled such as the update set (sys_update_set) table list, all display in List v2 by default, since List v3 does not support those features.

A quick and easy way to tell if you're looking at a List v2 or a List v3, is to check for the Personalization gear button If you see that, then you're looking at a List v2 list. On the other hand, if you see the Grid and Split buttons at the top of the list to the right of the search box, then you're looking at a List v3 list.

To an admin/developer, probably the biggest difference between the two list versions is how you access configuration data (business rules, client scripts, UI actions, and so on) for the table that the list is related to.

On List v2 lists, you right-click the header row of the list, and go to Configure, then select the type of configuration data you'd like to configure:

However, on List v3 lists, you click on the hamburger menu at the top-left of the page and click Configure:

This opens up the List v3 Configure modal dialog with the same options you would find in the Configure sub-menu in List v2 lists:

You can also disable List v3 on specific lists one-by-one, by clicking the hamburger menu at the top-left of the list, then clicking on List Control and checking the Disable list v3 checkbox. In this menu, you can also choose the default view mode (grid or split) for List v3.

Lists and Tables

Lists in ServiceNow can be equated strongly to tables in databases. For the most part, this would be an accurate comparison. Viewing a list, is viewing a representation of a subset of records within a table on ServiceNow's servers. The columns of that list correspond to fields within the table, and often fields which would show on the form (if configured to do so).

Each table in ServiceNow has a label (a friendly name), and a name. The label is defined in the table dictionary and can contain spaces and other characters not allowed in the table's name. The name is often more difficult to remember, but more specific. The label "task" may refer to the base task table, problem tasks, catalog tasks, or a multitude or system or custom tables. However, the name sc_task makes it clear which table we're referring to (the catalog task table, in this case).

Creating a custom table

Let's start out by creating a custom table. This table will be the home for records created within our application of at least one type, but before we do that, we need to create an update set!

Creating an update set

The Interface, we briefly mentioned the update set selector at the top-right of the ServiceNow UI. In this article, we're going to create one ourselves, in order to capture and track our work, and so we can export it and save it in between clones, or just for a backup. Here's how:

Start by clicking on the System Settings gear menu at the top-right of the ServiceNow frame, in the banner. Then, click on the Developer tab from the left.

Just so we can keep an eye on it, let's add the update set picker to the banner section of the ServiceNow frame by toggling the Show update set picker in header option to On.

Now we'll see a little drop-down menu just to the left of our profile link and picture. This will help us keep an eye on which update set we have selected, and easily switch if we need to.

With that toggle switched on, click the middle icon that looks like a list after the Update set drop-down in the System Settings menu. This will take you to the Update set table. To create a new update set, click the blue New button and fill out some details as before.

Because we're creating our update sets in the same order as we're doing our development, so long as we also deploy/push them in the same order, we won't have any issues of overlap. update set and then modify it in , that's fine. But if we then tried to migrate those update sets in the reverse order then the chapter 2 update set would have us modifying a record that doesn't exist! It is important to maintain the integrity of your update sets, by understanding the order in which they were developed, and the relationship between the sets.

After clicking Submit and Make Current, you should be directed back to the Update set table list. Let's demonstrate list editing by closing our previous update set now that we're done with it. To do so, follow these steps:

Ensure that the State column is displayed in the list view for the Update set table. If it isn't, follow these steps to add it:

Click on the Personalize gearicon at the top-left of the list view. If you have Lists V3 enabled, and don't see the gearicon, click the hamburger menu preceding the filter icon at the top-right of the list, and click Personalize List Columns.
In the Personalize List Columnsdialog, select the Statefield, click the right-arrow button, and then click OK:

This change only applies for you, since it is a personalization!

The list should reload, and the Statefield should be displayed.
To the right of the row representing the update set, double-click in the State column, where it says In progress. This should cause the field to become editable within the list view:
In the drop-down that appears, select Complete, and click the green checkmarkbutton to save your update.

Not all records can be edited from the list view. Certain tables don't allow it, and ACLs (security rules) still apply. However, it is possible to bypass certain preventative measures implemented as client-side scripts and policies by editing from the list rather than the form (which is why some tables have list editing disabled). For example, if a client script exists which would remove the Complete option from the State drop-down for The Interface update set if we viewed it through the form, we would still have been able to make this change through list editing, because that script would not have run on the list view.

Creating the table

Now that we've created an update set and marked it as current, we're ready to begin development. As is the case with many (though not all!) ServiceNow applications, we begin our application by creating a new table to house our data. In this case, we're creating a virtual war room application, so we'll create a table to hold virtual war room tickets.

First, in the application navigator, navigate to System Definition | Tables, and you'll be presented with the list view for the sys_db_object table; or you might say, the Tables table.

Click on the blue New button at the top-left of this list to get started. On the New record form, enter Virtual War Room for the label, and press Tab. Once you've done that, the Name field should auto-populate with the value u_virtual_war_room. The u_ indicates that this is a custom, user-defined table, as opposed to a table that's built-in with ServiceNow.

It is generally good practice to give your tables singular labels (Virtual War Room as opposed to Virtual War Rooms) and names (u_virtual_war_room, as opposed to u_virtual_war_rooms). Most built-in tables in ServiceNow adhere to this standard as well, except for the Properties (sys_properties) table. ServiceNow will try to figure out the best way to pluralize the label of a record type (though you can custom-define the plural form if you prefer), for use in places like the label at the top-left of a list. The singular form would then be used as the label on a form displaying one record.

Next, in the Extends table field, we have to determine whether we want our table to extend another table (and thus, inherit the existing fields, labels, and certain business logic). We'll go over what this means in more detail, in a later. For now, since we are going to want access to some of the task-related goodies built in to ServiceNow, let's set our virtual war room table to extend the task table by entering Task into the Extends table field.

There are multiple tables with a label of Task, but only one with a name of task. A similar table containing catalog tasks for example, also called task-is named sc_task. More info on the Task table can be found Tasks and Workflows.

Since we want to create a new application menu item and module for our application, we'll leave Create module and Create mobile module checked. We'll also leave the Add module to menu option set to -- Create new --, and underneath that field, we'll leave the New menu name field set to the same as our table label: Virtual War Room.

You'll notice that the Columns tab or form section contains a list of Table Columns, which is currently empty. We'll leave this section alone for now, as many columns are going to be automatically created for our table once we save the new table record, since we're extending another table.

Moving to the Controls form tab/section, we've got several more options:

Extensible: This indicates that other tables are able to extend this table. This might be useful if we were creating a parent table that would have child-tables that needed to share the same custom fields we created, but for our purposes we're going to leave this box un-checked.
Live feed: This checkbox determines whether live feed is enabled on this table. The live feed is part of the newer social IT applications, and serves as a place where users can post and share certain content. If live feed is enabled, you can have a sort of twitter-stream like view of tickets you're interested in, and activity happening on them. Let's go ahead and check this box.
Auto-number: This allows you to define a prefix (incidents, for example, use INC by default), and the system will automatically number each record in your table, beginning at the number you specify. Let's check the auto-number box, set the prefix to WAR, and leave the Number and Number of digits fields default.
Create access controls: This allows you to create a new role to control access to your application. It might make sense down the line, for us to have a separate role that we can grant only to certain major-incident managing groups or users, so go ahead and leave that box checked. The User role field beneath it allows us to select an existing role, or create a new one. The field background color should be green, which means the value currently in it is new, and will create a new role when saved.

Application Access: This tab/section allows us to control application-scope specific settings, but we're not concerned about that right now so go ahead and leave everything there default.

Whether the Columns, Controls, and Application Access sections display as tabs or stacked form sections, depends on whether you have the Tabbed forms toggle switched on, in the Forms tab of the System Settings cog menu. Just a reminder, this setting is a preference, meaning that it is user-specific, and won't affect other users' experience.

Finally, right-click in the header and click Save. We could also click the Submit button, but that would redirect us back to the previous page we were on, and we're not ready for that just yet.

After saving the new table record, if you go back into the Columns section, you'll notice that somewhere in the ballpark of 60-70 new columns have been created automatically! A few of these are default fields created on every table (fields like Created, Updated, Sys ID, and a few others), but the vast majority of the fields you'll see, came from the Task table:

By default, you'll see that the Table columns list inside the Columns section of the form has several fields shown: Column label, Type, Reference, Max Length, Default value, and Display. Since these are rather universal, let's go through each column and make sure we know what it means:

Column label: This is the friendly name for the column (or, on the form, the field label).
Type: This is the type of field. This dictates the default max length (which you can change), what field properties and attributes are available for this field, and what sort of values will be accepted. Changing a field type after it's been created is very difficult, and not recommended after users are actively using your application, as all data from that field will be lost, in all existing records.
Reference: This field is only relevant to certain types of columns which reference records on other tables. We'll go into reference field types,Understanding Data and Relationships.
Max Length: You can probably guess at what this field governs. That's right, it's the maximum length (in characters) that the field will accept. The default value for this is 40 for most column types, 32 for reference fields, 4,000 for journal fields, and so on. You can specify whatever length you like here.
Default value: Also fairly self-explanatory, this is the default value for the column, to be used before the user has selected one.
Display: Each table can have only one display value. The display value is the single column which is displayed to represent a record as a whole. On the Incident table for example, the display value is the Number column, but some users change it to Short description. On the Users table, you might want User ID, or Name to be the display value.

Adding a field

Now that we've got a table, let's go ahead and add some additional fields to our virtual war room table, within this list of table columns (which is actually a list formatter within a form). To do that, we have two options:

Since List edit insert row (a property of this list formatter) is enabled, option 1 is that we can actually scroll to the bottom of the list and double-click in the bottom row, where it says Insert a new row..., and it'll let us insert a new table column record just by specifying a few values here:

Any values we leave out will just be set to their default values, or blank. The only down-side to this, is that it doesn't allow you to see and edit all of the fields that might be relevant when creating a new table column; only those which are shown in this list formatter.

However, we've also got option two: Simply clicking the New button at the top-left of the list formatter. This will take us to the new record form for this particular table (which happens to be the Dictionary table, as all table and column definitions are stored there). This form has built-in logic to (for the most part) show us only fields which are relevant to what we're trying to create.

For our first custom field, let's create one to hold a reference to a particular incident ticket, since major incidents are the sorts of tickets that we want to result in war rooms being created for triage and remediation:

If you haven't already, click on the blue New button at the top-left of the table columns list, on the Virtual War Room table definition form.
Click on the magnifying glass on the right side of the Type field.
At the top-left of the Field Classes list window (next to the filter icon), click on the magnifying glass again. Then, under the Label header, enter Reference and press Enter. The breadcrumb text next to the filter icon will update, and you should see one field type matching your query, called Reference.
Click on Reference in the field classes list window, and the Type field will be populated. In that field, you'll see the word Reference. You'll also notice that several new fields have appeared, based on your selection.

Interestingly, the Type field is, itself, a reference field!

In the Column labelfield, enter Major incident. The column name should then auto-populate, and contain u_major_incident.

The Max length field can remain blank, as it will automatically be set to its default value for the reference field type (32 characters) after we save. However, we do want to ensure that virtual war rooms are not created or worked on without being associated to a major incident; so over on the right side of the form, tick the box marked Mandatory.

In the Reference Specification form tab/section, there's a field called Reference. This is where you should enter the table in which the records you're referencing can be found. Since we're dealing with Major incidents in our virtual war room application, let's have this field reference the Incident table.

Rather than clicking the magnifying glass this time, try just typing incident into the field. You'll notice a drop-down list appears after a brief moment. You must select the one from that drop-down that is just Incident. It'll have the label (Incident) on the left, and the table name (incident) on the right, but it won't be called incident_task or anything else:

.

If the Reference field turns green, it means you didn't select a reference table from the drop-down, and ServiceNow will attempt to create a whole new table for you to reference. This is definitely not what we're looking for. If that happens, re-type incident in the Reference field, and make sure to select one of the options that appears later in the form.

Remember when we clicked on the magnifying glass to the right of the Type field? The window that popped up showed us records from a specific table. This is the table specified in the Reference field in that particular field's dictionary.

Right-click on the header of the Dictionary Entry form, and click Save. This will submit the record to the database, without returning you to the previous page, so you can continue to work on the record.

Before I save a record, I usually glance up at the top-right of my screen, to make sure that I'm still in the correct update set. However, if you tend to work in multiple windows or tabs, it's easy to change your update set in one tab, but have it not reflect in the other tabs. Since which update set your work is stored in, is determined server-side, you may need to be proactive about ensuring you're still in the right set. To check if you're really in the update set that shows in your banner frame, click on the System Settings gear menu at the top-right, and go to the Developer tab. Click on the far-right Refresh icon next to the Update Set picker drop-down, and check to make sure that the selected update set doesn't change after 1-5 seconds.

As you may recall, this virtual war room application is really meant for only Major incidents. Each company might have different criteria for exactly what constitutes a major incident, but ITIL implies that generally incidents with the highest priority and the highest impact, are major incidents.

We did make the Major incident field mandatory, but there's nothing currently preventing someone from creating a virtual war room and associating it with a low-priority incident. Luckily, ServiceNow gives us an easy way to filter the types of records that can be selected from a given Reference field, using a Reference qualifier, also known as a Reference qual condition or simply refqual. This is a condition that is applied to the Reference field, so that only records which match that query can be selected.

In order to ensure that only incidents with the highest priority and impact are selectable, we simply add conditions using the condition builder below the Reference field in the Dictionary Entry form. The conditions should look something like this:

Right-click on the header of the content frame, and click Save again. After the frame reloads, it should look something like this:

To return to the table record and column list, you can click the left-facing back arrow at the top-left of the page. In the next section, we'll head over to our application to make sure the new field shows up in the default list view for everyone, as its value is a pretty important bit of information!

List view

In the application navigator filter text box, type Virtual War Room, and you'll see the virtual war room application header, as well as the Virtual War Rooms module (automatically pluralized based on our table label). Click on that module, and you should see the Virtual War Rooms list view.

You may want to click the star next to the Virtual War Rooms module to save it as a favorite, so it'll show up in your favorites list, and so it'll show up first whenever it would show up as a result when filtering the application navigator using the text filter.

The columns displayed in the list view of a given table, such as the request item (sc_req_item) table, can be either personalized (modified just for you) or configured (modified for all users). You can choose to display any field within a given table in the list view, or even derived fields (fields with data from related records).

If you don't see the Major incident column in the Virtual War Room list view, click on the hamburger menu at the top-left of the content frame, and click on List Layout. On the next page, find the Major incident field in the list marked Available, and either double-click it, or select it and then click the right-arrow to move it over to the Selected box. Next, make sure you have that field selected and click the up-arrow on the right, until it's listed right after Short description.

While we're here, let's remove some superfluous columns as well. Get rid of the Task type and Priority columns by double-clicking them in the Selected box, so that they move back over to Available. Finally, click Save.

Congratulations, you've just created your first custom field on your first custom table in your first custom application. You're catching on quick!

If we wanted to modify the list layout just for us instead of for everyone, we could have clicked the hamburger menu at the top of the content frame, and click Personalize List Columns.

Users who have personalized the columns that show up in a list, or the order they show up in, will not see the changes made to a list using the following steps, even though the steps below should modify the view for everyone! This is because user preferences generally override system configuration.

In order to see the configured list view, users will need to click the hamburger menu, go to Personalize List Columns, and then click Reset Columns at the bottom-left of that dialog.

Condition builder

Another major component of lists is the ability to filter them using the condition builder (also sometimes called the query builder). The condition builder is one of the most powerful, and most useful tools in all of ServiceNow, and it can be found doing more than just filtering lists.

Condition builders can be included on forms as a field to store a condition value, and we've already seen how they can be used to filter the options that one can select from a Reference type field, while we were creating the Major incident field for our virtual war room application. Let's try out some examples of how the condition builder works. We'll use the incident table as an example, since it should contain a good amount of demo data in your instance, and it's got a lot of different type of fields.

To get started, navigate to Incident | All from the application navigator. In the list that appears, click on the filter icon at the top-left. Let's walk through several example filters, and how to build them using the condition builder.

Building a filter

For this example, let's build a query that will only show records like this:

Incidents assigned to me that are not closed or cancelled, sorted by when they were last updated (oldest first).

First, let's break this down into components:

Assigned to is me (the current user, whoever it may be)
State is not either closed or cancelled
Sort by updated (high-to-low)

You should be looking at two drop-down fields and one string input field, arranged in a row, like this:

Just like in math and programming, these three fields each represent a component of a condition criteria that looks something like <Field> <Operator> <Value>.

Click on the Keywords drop-down. In this drop-down, you'll see a list of fields on the Incident table. The first thing we want to do is filter based on to whom the incident is assigned, so type assigned to into the filter box at the top of the drop-down list, and then click on Assigned to.

The second field is the operator. This determines the type of comparison we're doing. In this case, we want records where the field is equal to a certain value, so for the operator, we might want to select is. However, if we try to enter a value into the value field on the right side of the condition, we'll see that it expects us to select a user from the Users table (since Assigned to is a Reference field that points to that table). We could select our own user account, but we want this filter to show tickets assigned to whatever user views it, so that won't work.

Luckily, for this situation, we have dynamic operators. On Reference fields, we can select the operator is (dynamic) (as opposed to just is), which gives us some dynamic options for the value. The first dynamic option is Me. This runs a script on the server, which replaces Me with whatever user is viewing the list.

These condition value fields accept JavaScript code, as long as it is preceded by JavaScript: If you were so inclined, or if you didn't have the is (dynamic) operator, you could use the GlideSystem API to get the sys_id of the current user for your query. You'd select is for the operator, and enter: javascript:gs.getUserID();.

So our first condition should look like this:

In order to add a second condition, we need to click the AND button. If we wanted to add a one or the other type of condition, we could use OR, but we want all of these conditions to match in order for a record to show up based on this filter.

After clicking AND, a new query condition line will appear. For the first part of this query line, select State from the drop-down. For the operator, choose is not one of. Finally, for the value(s), hold CTRL, and select both Closed, and Canceled. Your condition builder should not look pretty similar to this:

Finally, click on Run to filter the list of incidents. After running the filter, we then need to sort the list. There are two ways to sort a list:

If the field you'd like to use to sort is displayed on the list view, you can simply click on that field header to sort by a to z (low to high). Clicking again sorts in the opposite direction. The down-sides to this method are that you can only sort on columns which display in your list view, and you can't do multi-level sorting.
Alternately, after your query is in place, you can open the condition builder and click on Sort Filter. In the modal window that displays, you can select one or even multiple levels of sorting. For example, you could sort just by when the incident was updated, or you could sort by who the caller is, and sub-sort by how long ago the last update was.

For our purposes, we'll just need to sort by one field, and that field happens to be in our list view. To sort the incident table by when each ticket was last updated, we just have to click on the Updated column header once. That will sort it from low to high. Dates further in the past are considered lower than more recent ones, which are lower still than dates in the future.

Note that although you cannot do multi-level sorting just by clicking on the column headers, you can do something similar by grouping records together based on certain values. For example, if you wanted to see the results of the query we just built using the condition builder, grouped by Priority, but still sorted, within those groups, by the Updated date, you could simply right-click on the Priority header, and choose Group by Priority.

Dot-walking

The earlier lab walked you through creating a query in the condition builder using values stored on the records within the table you're viewing. This is extremely useful functionality, but what if we wanted to filter the list using a data point that is not on the incident itself, but is on one of the related records in a Reference field? For example, what if we wanted to show only incidents where the user in the Caller field is a currently active (meaning that they haven't left the company and had their user account disabled).

In order to accomplish this, we'll need to make use of dot-walking. We'll explore more about dot-walking and how to do it via JavaScript later in this book, but let's have a look at how to do this in the condition builder.

In your existing My Incidents filter, click AND to add another condition. In the list of fields below, you'll see some fields with a little arrow inside a circle on the right:

In List v2, in order to dot-walk, you need to first scroll to the bottom of the list of fields, and click Show Related Fields, then re-open the field drop-down, and select a Reference field from the list, that's followed by an arrow => and then a table name. When you re-open the drop-down list again, you'll see the fields from that table.

This arrow indicates a Reference field that can be dot-walked through. Find the Caller field in that list, and click the arrow to the right of it, and you'll see another list show up to the right. If this list also contains reference fields, you can continue dot-walking through them as well, up to several layers. If possible, it's recommended not to go beyond 3 or 4 layers of dot-walking, for performance reasons.

Forms

As you've seen, forms are where data is displayed in ServiceNow, but you wouldn't want to display every single field in your table to all of your users! For this reason, forms have views that limit which fields are shown, and to whom.

Form views can be configured, or personalized, split into sections, and can contain and display all manner of different kinds of data. Data can be made to be displayed, made read-only, or made editable in forms based on various conditions that we'll discuss later UI and Data Policies. In this section, we'll briefly go over how to configure and design forms, how to personalize them, and make them your own, and how to configure form sections and related lists. More details on the specific components that'll show up in forms will be covered in later.

Form designer

Let's start by creating a virtual war room record. Follow the following steps to create a record in our application that we can use to create and modify views using the form designer:

In the application navigator filter text box, type Virtual War Room, and you'll see the virtual war room application header, as well as the Virtual War Rooms module.
Click on that module, and then click New at the top of the list, to see the virtual war room form and create a new record.
Enter Beth Anglin in the Assigned to field (this is a random default user included with the demo data in your development instance).
Click the magnifying glass next to the Configuration item field, and select any random configuration item from the built-in demo data.
Enter something for the Short description like test war room and something for the Description like this is a test ticket for the war room application.
Click Submit. This will return you to the list view.
Click on the Virtual War Room ticket you've just created, to go back to the form.

All of the fields you'll see on that form, are actually fields derived from the Task table. In fact, aside from the base system fields (Created, Created by, Updated, Updated by, and a few others) and our newly created Major incident field, all other fields were derived from the Task table.

You'll notice on this form, a number of fields and field types, including but not limited to the following:

The Numberfield, which is a String
The Assignedto field, which is a Reference type (that points to the Users table).
The Short description field which is a Stringtype that spans two layout columns.

The difference between the Short description and Description fields, is the maximum length value from the field's dictionary entry. If a String field has a max length of 255 or less, it will appear as a Single line or small field. However, if its max length is 256 or greater, it'll be a multi-line field on the form.

The Active field, which is a True/false (AKA boolean) type.
The State field, which is an Integer field with a drop-down choice list.

Though the State field is technically an Integer type (meaning that the actual value in the database is an integer), the choices that can be selected are actually stored in another table, labeled Choices (with the name sys_choice). This table has records that, like the table itself, have both a label, and a value. The label is what you see in the State field stop-down (Open, Closed, Work in Progress, and so on) but the value is what is actually stored in the field, and in the database.

For the virtual war room, we're not going to need all of these fields - and anyway, this form doesn't even display out Major incident field! Let's fix that, by following the steps below:

Right-click on the form header, and go to Configure| Form Design. This will open the Form Designer, a handy little app within ServiceNow.
Since we want all virtual war rooms to only exist for major incidents of the highest priority, we don't really need a Priority field on the war room itself. Go ahead and click the little x icon to the right of the Priority field when you hover over it.
Use the same method to remove the Active field, as well as Parent, Short description, and Description. We are going to want a short description and description on the form, but we'll get it from the Major incident.

Now let's add our Major incident field to the form. Filter the list of fields on the left to find it, and drag the Major incident field to the right, placing it right underneath State.
1. Finally, add the Activities (filtered) (Formatter) just under Work notes at the bottom. This is going to display your journal. More on this and activities in Tasks and Workflows.

At this point, your form designer window should be looking something like this:

Go ahead and click the blue Save button at the top-right of the page, and return to the tab you were on previously. Right-click the header, and reload the form, and you should see your new, brilliantly designed form. Well done!

Form layout

In addition to the form designer, there is also Form layout in the Configure menu when right-clicking the header. This allows you to modify nearly everything that you changed through the form designer, though it isn't as user-friendly. In exchange for that lack of user-friendliness though, the trade-off is that you can easily add derived fields based on related records in reference type records.

Let's walk through an example, so you can see what I'm referring to:

Right-click in the header of the Virtual War Room form again, and go to Configure | Form Layout.
Scroll down to the Major incident field that we created. It should be highlighted in green, and have a little [+] next to it. This indicates that it is a Reference field.
Click on Major incident to highlight it, and a new icon will appear before the other two buttons, in-between the Available and Selected lists. Clicking this button allows you to dot-walk to access the fields on the Incident table, and add them to our Major incident table.
After clicking that icon, you should see a new list of options in the Available box on the left. From that list, double-click on Short description.
Use the arrows to the right of the Selected box to move the two new fields up or down so that the Major incident. Short description field is right before Work notes.
Click the blue Save button on the form layout window, and you should be returned to the form.

Now you've got the Short description field from the Incident table (via the Major incident field) displayed on your virtual war room form. If you want to see this value populated, just click the magnifying glass icon to the right of the Major incident field, and select any incident from the list that pops up. The Short description will populate automatically, displaying the short description from the incident you've selected!

Related lists

Related lists are powerful tools in ServiceNow, both for displaying data, and for doing work. They show up below a form, and can display any records you'd like, that are in some way associated to the one you're viewing in the form.

There are multiple ways to associate one record to another, including a custom-defined relationship that you can create using javascript. The simplest and most common way of relating two records though, we've already done. It's with a Reference field!

To understand how related lists work, you first must understand a key component of ServiceNow: Keys!

See what I did there?

In a database, it is important to be able to differentiate one record from another, with some key piece of information. This is a unique value that resides in a database column. This column is referred to as the primary key for that table. In ServiceNow, the primary key is called the Sys ID, stored in the database column sys_id. This is a 32-character alphanumeric value that is unique in the entire database. No two records (no matter the table) should ever share a Sys ID.

A Reference field is a database column that is meant to accept the primary key (Sys ID) from another record, often in another table. In this way, the two records are related. This is known as a one-to-many, or a parent-child relationship. In fact, there is one field on the Task table which our Virtual War Room table inherited, that's called Parent, and is designed for exactly this type of relationship; though we aren't using it in this case.

In database parlance, when your table has a column meant to accept the primary key from another record, that column is referred to as a foreign key.

When we created the Major incident Reference field on the Virtual War Room table, we created a relationship between records in the Incident table, and records in the Virtual War Room table. We can easily see the related incident from the virtual war room form, by looking at the Major incident field; but what if we want to see any related virtual war rooms, from the incident form? For that, we need to use a related list.

To get started, navigate to the Incident table. Don't save your changes to the virtual war room ticket.

Try navigating there by typing incident.listinto the application navigator text filter box, and pressing Enter!
Click on any Incident record in that list to open the Incidentform for that record.

Right-click on the header for that form, and go to Configure| Related Lists
Scroll down in the Availablebox, until you see Virtual War Room | Major incident, then double-click on it, and click Save.

Some of the most useful pieces of information in ServiceNow, are what something used to look like, when it was updated, and who updated it. For any records in a table that is audited (any table that's tracked in update sets), you can find the versions related list under Configure | Related Lists on the form.

You should now see the virtual war rooms related list at the bottom of the incident form, and it should be empty. That means that this particular Incident doesn't have any virtual war rooms associated with it. Let's go ahead and fix that by clicking the blue New button under that related list.

You should be taken to a new record form for the Virtual War Room table, and the Major incident field should be auto-populated with the number of the incident we were just on. Be aware that although you can make the Number field unique in the incident table so that there can be no duplicates, it is not the primary key. That's the Sys ID.

In the Form Designer section of this article, we learned how the State field on the Task table (and tables that extend it) is actually an Integer field, and each of those integer values has a label, like Open, or Work in Progress, but the actual value in that field is still an integer. Reference fields are similar, in that-although you see the display value of the record in the Reference field-the actual value that it contains, is a Sys ID. Since the Incident table's Number column is set as the display value, we see the incident number in the Major incident Reference field. If, however, we were to change the Short description field to be the display value instead, then we would see that instead of the number, in this and any Reference field which contained the Sys ID of an incident.

Just like we've done before, fill out the virtual war room record with any old information. You should notice that the Short description field has also auto-populated with the short description of the incident. Let's see what happens if we change the value of a field that is derived from another record. Go ahead and add the word testing to the end of the short description.

Once you've finished filling out some info and changing the short description, right-click on the header and click Save.

Notice that when creating an incident in this way, we've effectively bypassed the reference qualifier we created on the Major incident Reference field! If we clear out the value in that field, the system won't let us re-populate it, but it's important to be aware that when coming at it from the child-ticket and creating a parent record in this way, we can bypass a reference qualifier.

When the form reloads, you'll see a reference icon to the right of the Major incident field; it'll look like a lower-case letter "i" inside a circle. Click on that icon to be taken to the incident that we were on previously, and scroll to the bottom. You should now see our newly created virtual war room! This is because there's now a record in the Virtual War Room table that matches the default query for this related list, which you can see just to the right of the filter icon.

This is all great, and you can imagine the myriad of uses for the functionality of related lists, but we will only be using virtual war rooms on major incidents, and those are pretty rare. Luckily, we can control when related lists show up easily! To see how, right-click on the list column header row in the related list, and go to Configure | List Control.

On the right side of the list control form, you can choose which roles are required to see the New or Edit buttons, the filter, or even links in the related list. On the left side, you can see several options for omitting the new button altogether, omitting the edit button, and other components. The option we're interested in though, is the Omit if empty checkbox. Tick that box, and click Submit to return to the incident form.

Now, when visiting an incident that doesn't have a virtual war room associated with it, you won't see the related list!

Summary

In this article, we learned about lists-both version 2 and version 3,of ServiceNow-as well as tables and forms. We created custom tables, table filters, custom fields, and learned about dot-walking through Reference fields.

Lists and forms are fundamental to ServiceNow, so don't be afraid to come back and reference this article as you

Regards,

Ganesh

blanca12 · ‎04-27-2021

Thanks for sharing.

Tutuapp 9Apps ShowBox