Learning ServiceNow
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

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 in Chapter 6, 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 chapters.

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:

  1. 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.
  2. 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.
  3. Enter Beth Anglin in the Assigned to field (this is a random default user included with the demo data in your development instance).
  4. Click the magnifying glass next to the Configuration item field, and select any random configuration item from the built-in demo data.
  5. 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.
  6. Click Submit. This will return you to the list view.
  7. 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 Number field, which is a string type.
  • The Assigned to field, which is a reference type (that points to the Users table).
  • The Short description field which is a string type that spans two layout columns.

    Note

    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 characters or fewer, 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.

Note

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 drop-down (Open, Closed Complete, 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 our Major incident field! Let's fix that, by following the steps below:

  1. Right-click on the form header, and go to Configure | Form Design. This will open the Form Designer, a handy little app within ServiceNow.
  2. 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.
  3. 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.
  4. 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.
  5. 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 Chapter 5, Tasks and Workflows.

At this point, your Form Design 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 (as we saw in the preceding section). 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:

  1. Right-click in the header of the Virtual War Room form again, and go to Configure | Form Layout.
  2. 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.
  3. Click on Major incident to highlight it, and a new icon will appear above the two arrow 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.
  4. 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.
  5. 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.
  6. 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 (through 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!

Note

If you have an editable derived (dot-walked) field on a form, and a user edits it, keep in mind that they will actually be editing the field on the record that it was dot-walked from! This can have unexpected consequences, so it's usually a good idea to make derived fields read-only.

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

Tip

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.

  1. 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.list into the application navigator text filter box, and pressing Enter!
  2. Click on any Incident record in that list to open the Incident form for that record.
  3. Right-click on the header for that form, and go to Configure | Related Lists:
  4. Scroll down in the Available box, until you see Virtual War Room | Major incident, then double-click on it, and click Save.

Tip

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.

Note

In the Form Designer section of this chapter, 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 ol' 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.

Note

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. You can prevent this by removing the option to create new records from the list control of the related list, but we'll go over this in a later chapter.

When the form reloads, you'll see a reference icon (Related lists) 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!

上一章目录下一章