Business rules, Client scripts and UI actions

Think of ServiceNow as a database of records (tickets, users, CMDB, etc.) with forms and pages to view, insert, and modify those records.

When a record is inserted or modified, Business Rules will run checks to ensure that the changes are consistent with how you want records in the database to be.

If a modification is found to violate any of your rules, it will be aborted and the records in the database will remain unchanged.

On top of aborting inconsistent changes to your database records, Business rules can also modify records based on user input, a query, or other related records.

For example, when the caller updates a closed ticket (either by replying to the closed email notification or through the Self-service form view of the ticket) you can have a Business rule that will also set a flag for the Servicedesk’s attention. This is how the Noted feedback feature described in Chapter 5 is implemented.

Out-of-Box there is also a business rule that runs every time that a ticket is reassigned. The Business rule then increments the reassignment count field automatically (Figure 12-1).

Figure 12-1. Out-of-box Business rule that increments the reassignment count field every time the assignment group changes.

The good thing about business rules is that they are applied consistently to records, regardless of whether the record modification is made through a form, list, email, or web service.

The down side is that the behavior of business rules is not transparent to users, and may easily overwrite or ignore their changes without them knowing it (see Figure 12-2). As discussed in Chapter 8 it is important that you make your application’s behavior obvious to its users. So before you allow the introduction of a new business rule, check that:

Figure 12-2. Info message shown when opening a Business rule in ServiceNow.

• your new Business Rule displays a message that clarifies to the user the modification or action taken by the Business Rule (as shown in Figure 12-3);

  

  Figure 12-3. Information message shown by an OOB BR when a ticket is reopened.

• Avoid tampering with out-of-box Business rules as that can have undesired consequences and conflicts when you upgrade your instance.

To discourage developers from inadvertently making your instance less maintainable, require explicit approval and justification before changes to out-of-box scripts are made. Otherwise developers should create new ones instead.

Even after you introduce a new Business rule, you may want to make its behavior predictable to the user even before she submits the form, and the BR applies. A typical example of this is the guidance messages dynamically shown as you choose a new password (see Figure 12-4) on a sign-up form.

Figure 12-4. Typical password field in a sign-up form shows immediate feedback to the user before she submits the form.

The server will never accept a weak password but the form uses immediate visible client-side indicators to inform the user up front, before she submits the form to the server.

The same can be done in ServiceNow with Client scripts (or another configuration) that runs transparently in front of the user.

UI actions

A UI action is any button, link, or right-click context menu item in a form that allows the user to perform an action on the record.

What is special about UI Actions is that they can specify checks and behavior to run in the browser (Figure 12-7) and if all is fine, submit the record to the server (Figure 12-8).

Figure 12-7. When clicking on the Resolve UI action, Close code and Close notes are visibly made mandatory, preventing submission of the record to the server until they are filled.

Figure 12-8. The Resolve UI action defines in the same script code to run on the client, as well as other code to run on the server.

To summarize, use Client scripts to interactively auto-fill fields in forms and Business rules for other settings that should apply to all records regardless of how the update is submitted (form, email, script). UI actions are buttons that can do things both on the form and on the server before BRs are run. Use them to make things easier for the user.

For more details about scripting in ServiceNow, check out ServiceNow’s official documentation on scripting.^{1 2}

Views and Access control rules

With Views in ServiceNow you can customize how a form in ServiceNow will look depending on where it is accessed from. If you are familiar with web design, this is similar to websites looking different if opened from a mobile view versus a desktop or a tablet.

For example, when an end user views an incident ticket she will see the Self-service view of the ticket (Figure 12-9); whereas when an ITIL user views the same ticket from his account he will see the default view for ITIL users. If the ticket is opened from a Visual task board the ticket will again look different (Figure 12-10).

Figure 12-9. Incident viewed in self-service view.

Figure 12-10. Incident viewed from a Visual task board.

Creating views is not a mechanism to control who sees what; It is just a way to define the form layout (Figure 12-11) that is shown to different users. Users could still change the view or see all fields she has access to see on a ticket, by previewing the ticket history (Figure 12-12).

Figure 12-11. From the Form layout page you can select which fields are shown in each view.

Figure 12-12. In the record’s History detail log users can see all the fields that they have access to see.

To control who can see what or modify particular fields in a ticket you need to define Access Control Rules (ACLs) .

ACL allows you to define which conditions must be met and which access role a user should have in order to view or modify a particular field in a form (Figure 12-13). Because of ACL rules even if you view ticket in a view that should show fields which you don’t have access to you will not be able see them.

Figure 12-13. List of ACLs defined for fields in the incident table.

Custom apps, Modules, and Application menus

If you want to create a new type of ticket distinct from existing tickets in ServiceNow you can create a new custom application in ServiceNow.

A custom application in ServiceNow (Figure 12-14) allows you to create new ticket types and define who can access them (ACL), what Business rules to impose on them, email notifications triggered for them, etc.

Figure 12-14. Options for creating new applications in ServiceNow.

Applications basically let you leverage all the ServiceNow ecosystem of email notifications, access control, forms, and scripts for a new process that you define.

Besides creating your own custom application, you could also browse, acquire, and install applications from ServiceNow third parties store.³

Each Application will have an Application menu section which is a section in the navigation menu.

You can, however, also create new Application menus that list links to multiple applications without all of them belonging to the same application. For example, the Self-service application menu in Figure 12-15 provides links to Incidents, the Knowledge base, and Visual task boards.

Figure 12-15. Self-Service is an Application menu. Menu items listed under it knowns as Modules .

Breadcrumbs, dot-walking, and saved filters

A very powerful tool that you have when searching and running reports in ServiceNow is dot-walking.

When previewing a list of records, or running a report on a particular table, you can select the fields that you want to see for the records in the table. You can also select the fields of records in another table as long as that table is reference from a field that you selected.

For example, say you want to view a list of all open tickets for callers whose accounts are inactive (they left the organization). There is no field called For inactive user in the incident ticket, but you could get the same information on the fly by dot-walking through the Caller field, as shown in Figures 12-16, 12-17, and 12-18.

Figure 12-16. To begin dot-walking, first select Show Related Fields from the drop-down menu.

Figure 12-17. Select the new option that appears with an arrow (=>) below the reference field that you want to dot-walk.

Figure 12-18. Finally in the dot-walk, select the field that you want.

The breadcrumb is the horizontal list of filters applied to the list of records that you are viewing. Filters on a list can be saved for future use as shown in Figure 12-19.

Figure 12-19. Filters in the breadcrumb can be saved so that you or colleagues can return to the same query again.

Update sets, Import sets, and Inbound actions

An Update set is ServiceNow’s way to package changes for deployment from one instance to another.

Just like the Track Changes switch in Microsoft Word, only the changes that are made after the update set has been created and set will be tracked in the Update set. So developers must first create an update set and set it as their current Update set before they start making transferable changes.

When importing an Update set into an instance ServiceNow will compare the changes to the existing instance’s code, show differences or conflicts, and prompt the administrator to either apply the changes or backtrack.

Importing data

Whereas Update sets were for importing code and configuration from one instance to another, Import sets are for importing data.

Data from external sources such as Excel sheets or LDAP servers is first imported into a temporary table in ServiceNow, an Import set. With the data in it you can apply rules and copy the data to a permanent record table that you specify.

The process of matching the data in an Import set with a table in ServiceNow is defined in a Transform map.

In a Transform map, you define which fields in the Import set should match which fields in your target ServiceNow table.

For example, if your Import set table contains User objects imported from your Active Directory, your transform map will map each User object field with the corresponding field in the User table (Figure 12-20).

Figure 12-20. Default Transform map for matching user fields in Active Directory with user fields in ServiceNow.

In a transform map you also specify a coalesce field. This tells ServiceNow that while it imports the data from the Import set, it should check if there is already in the target table a record that has the same value in the coalesce field as the one that is about to be imported. If one is found, rather than create a new record ServiceNow will update the existing one instead.

A typical coalesce field for a user’s Transform map is the user_name but it could also be the email address or the objectSID as discussed in Chapters 3 and 11.

Inbound email actions

Inbound Email actions are scripts (Figure 12-21) that define how to deal with incoming emails. Out of the box, they are configured to create and update incident tickets as was described in Chapter 5.

Figure 12-21. Script of the inbound email action “Update Incident (BP)”.

Task table, Sys_id and Dictionary overrides

Most of the tickets available in ServiceNow (Incident, Problem, Change Request, Catalog Task, etc.) all inherit fields and functionality from a parent Task table . This means that every Incident is by definition also a Task.

What this means for you is that if you want to run a report that lists both Problem tickets, Incidents, and Requests you can create a report on the Task table, as shown in Figure 12-22. It also means that if you want to have a feature, field, or common behavior on all your tickets you can define it at the Task level.

Figure 12-22. Reports can be created at the Task table level to report on multiple ticket types in the same report.

You could however override the property of a field inherited from the Task table by defining a dictionary override specific to a particular table. For example, you could have the Assigned to field labeled as Change owner in Change requests.

Every record in ServiceNow is assigned a unique 32-character ID: the sys_id.

It’s like the number field but it is unique across all ServiceNow instances in the world. It looks like this: 9c573169c611228700193229fff72400

Home pages and Gauges

A home page in ServiceNow is a landing page that a user can be shown when they go to ServiceNow. By default there is a Self-service home page that is shown to end users while users with the ITIL role are shown the ITIL home page.

Each user can create and customize her own home page while administrators can also create, set, and control the home page of others.

A gauge is basically a widget or list that can be added to the home page. It can be created from a query or from a report .

Tweet-ready takeaways

• Think of ServiceNow as a database of records (tickets, users, CMDB, etc.) with forms and rules to view, insert, and modify those records.

• ServiceNow’s Business rules run checks to ensure that changes are consistent with how you want records to be.

• Client scripts in Servicenow are useful for interactively auto-filling fields in forms.

• Creating Views in ServiceNow is not a mechanism to control who sees what; It is just a way to define a form’s layout.

• ServiceNow dot-walking: You can select fields from another table as long as that table is referenced from a field that you selected.