Checklist Pro for Better Approvals

The ability to create approval requests for a digitized business processes in ServiceNow is one of the most important and powerful capabilities available on the platform. Putting checklists on these approval requests can make the platform even more powerful.

ServiceNow provides a convenient way to create User approvals and Group approvals.

Checklist Pro makes it easy to augment these approvals with the appearance of a Checklist on these approval records.

Let’s see how the combination of ServiceNow and Checklist Pro can be used to build a beautiful solution.

Suppose you want a governance process on who has what type of access to a particular system. A user needing more access to a Financial Management system like Oracle Financials wants to become an Expense Manager because of a new role in the organization.

With ServiceNow and Checklist Pro, this becomes easy to build and intuitive to use.

We created a Catalog Item (which also uses the Checklist) to pick a user and a system (both catalog item variables) and then the Checklist to model all the Oracle Financial roles & responsibilities available and those that the selected user has.

The user makes their adjustment to their list of Oracle Financial roles (controlled by the Checklist), provides a justification (reason) for the update, and submits the request.

In this example, the workflow sends this request to a review group responsible for determining if this request is acceptable or not and, because we have the roles and responsibilities represented as a checklist, they can modify the original request to ensure there are no conflicts of interests within the user’s selected responsibilities and then approve the request for continued processing.

Checklist Pro also provides additional functionality by allowing a custom Checklist processing button to be configured. In this same example, we defined the functionality of the button to allow the review team to "model after" another user in the system. The review group simply picks another user in the system and by clicking the “Apply Model” button provided by Checklist Pro and with a little custom coding, we were able to.

In summary, this example illustrates the power of Checklist Pro and the flexibility it provides your development team (Pro-Coders and Citizen Developers alike) to build world class solutions on the ServiceNow platform!

Creating Checklist Pro Checklists

One of the capabilities that Checklist Pro provides is the ability to include HTML text as a header to the checklist. This can be extremely useful for providing information to the approver that could be used for several purposes such as:

• Defining the criteria the reviewer should apply when determining if the request should be approved or rejected.

• Include convenience links to knowledge base articles, reports, dashboards or other important records or information that the reviewer may need.

Following the optional Checklist Pro HTML header is the actual checklist. Using Checklist Pro, you may pick from a variety of different checklist item types:

• Checkboxes

• Dates

• HTML objects

• Choice lists – having a set of user configurable choice options

• Numbers

• Reference fields

Checklist Configuration Steps (video here)

1. Create a Checklist Template Configuration (we created a video showing how to do this). This is just a top-level container for all the checklist item template records that will appear in your checklist.

2. Create a Checklist Configuration (see image above)

3. Define conditions for when the checklist should be created (“Create Conditions”).

4. Define conditions for when the checklist is editable (“Edit Conditions”).

5. [Optional] Define conditions for when the record hosting the checklist is considered “closed” (“Close Conditions”). This is needed for enforcement of “Required” checklist items and for any checklist item validations that need to be performed (Watch the Checklist Pro – Business Rule Setup video).

Prerequisite Steps

• Before a checklist can appear on a record, it must first be added to the form view for that record. In the case of Approval Requests, since those may be accessed via the Service Portal, you should also add the “Checklist Pro” widget to the Approval Form Service Portal page (Watch the Checklist Pro – Form and Portal Setup video)

Checklist Pro - Programmatic Checklist Creation

In the “How Does Checklist Pro Do It?” blogpost, we talk about how Checklist Pro creates a Checklist. We discuss two options:

• “Programmatically” - through a Checklist Pro API call.

• “Conditionally” – when someone browses to a record where a checklist is defined.

Since the above-mentioned blogpost covers the “Conditionally” created option, this blogpost will cover the “Programmatic” option.

We will also discuss why you may want to do one vs the other.

In prior examples, we created a “Cascading” checklist that would appear conditionally on an incident table if the incident was in a “New” or “In-Progress” state and if the category was “Inquiry / Help” and the subcategory was “Antivirus”. Under those conditions, if you navigated to a record where those conditions were true, then Checklist Pro would create a checklist (if one did not already exist).

However, if we wanted to simply create that “Cascading” checklist on an incident (any incident we wanted), then we would use the Checklist Pro API library to programmatically create our checklist.

Creating a Checklist Programmatically

In this example, our “Cascading” checklist is in a Checklist Configuration record called “INCIDENT – Cascading Checklist”.

In this Fix Script, we’ll create the checklist, adding it to some open incident record.

WARNING – if there is already a checklist associated with a particular record, this API call will add an additional checklist, so you may want to add logic to check if there is an existing checklist. See the modified code example below:

Now, when we visit the incident that the checklist was added to, we see the checklist there. We forcefully created the checklist on our desired record even though it does not have “conditions” matching that which would be required for it to be created by the Checklist Pro engine.

So, what are the advantages and disadvantages of creating checklists “Conditionally” (Checklist Pro Engine) and “Programmatically” (Checklist Pro API)?

A common situation for checklist creation is that you need to be sure the checklist exists even if nobody has opened the record where you want the checklist to appear. That could be the case for a checklist on an approval request or some task from a workflow.

Creating a checklist programmatically (via the API), would guarantee the checklist is on the record. If your checklist had “required” items that were assumed to be completed later in the workflow (for processing), then programmatically creating the checklist items may be the way to go. This would prevent someone from just closing a task (from the list view) or approving a request (again, from the list view without ever actually opening the record) and then not having the checklist exist because the record was never opened.

Checklist Pro (v1.9.11)

Version 1.9.11 of Checklist Pro is now available. This version has several new and interesting features as well as important bug fixes:

New Features

• Hide and read-only. Provides a way to selectively hide a checklist item (and all of its descendant items) or make them read-only based on 8 different built-in functions:

• In Group

• Not In Group

• In Department

• Not In Department

• At Location

• Not At Location

• Is VIP

• Is NOT VIP

Also includes option for hiding or making read-only based on condition builder

queries against the record that the checklist is on. Click to Watch Video.

• CLP License Database View. Interested in knowing if a user record is a "Fulfiller", "Business Stakeholder" or "Requester", the new "CLP LIcense" Database View (x_tygr_check_dv_license) joins the User Table, with the License Role and the User Role table so that you don't have to (because every DB View you create, counts against your alotted custom table count - so we're doing you this favor)!

· Additionally, we added two new API calls to a new script include:

x_tygr_check.LicenseUtil().getUserLicenseType (user_sys_id)

o You pass the sys_id of the user and the function

returns “Fulfiller” | “Business Stakeholder” | “Requester”, depending on what

that user is.

x_tygr_check.LicenseUtil().isUserLicenseType(user_sys_id, license_type)

o valid license types are “Admin”, “Approver”, “Business Stakeholder”, “Fulfiller”,

“Requester”.

o returns “unknown” (if user cannot be found) | “true” | “false”.

• Checklist Overview Dashboard. Reports showing any open Checklist Records assigned to you, unassigned open Checklist Records assigned to your groups and all open Checklist Records by group.

• Improved Checklist Record. We added the "number", "state" and "short description" fields to the Checklist Record Portal page. The “Completed” button now says “Complete” and has hover-over text. The “Incomplete” button has been changed to “Cancel” and includes hover-over text. An instructional blurb was added under the “Assigned To” field to inform users that the action buttons will appear once a user is selected and the “Save” button is pressed.

• Added Validation Routines. URL, Zip Code, IP address (ipv4 and ipv6), Is Date on Weekend, Is Date on Weekday.

• Improved Logging.

Bug Fixes

• Textbox checklist items would lose focus 1.5 seconds after you stopped typing.

• Checklist Configuration condition builder corrected issue with “^NQ” (logical OR) queries.