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 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.
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.
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!
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.
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.
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.
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.
Free Chapter
