IBM Business Automation Workflow Review Framework

Simplify your review and approval tasks and improve review consistency with this review checklist framework.

Checklist
Glenn Carstens-Peters © stocksnap.io

Authors: Leonard Blunt , Greg Ekaprana, Okka Sudaryanto, Diorella Mari Tom

Code Repository

Approval and QC Toolkit Git Repository

Introduction

When talking about business process flow, review and approve processes are a common requirement. This article provides details of a review and approve framework that combines coach views with data for review with a reviewer’s check that is customized based on role.

A template coach view provides a checklist for the approver simplifying the expertise needed for the review but also helping to alleviate the issue of manual reviewers forgetting what should be checked. The checklist model creates a visible aid to ensure a higher degree of consistency in the review procedure. The reviewers can use the checklist that is customizable based on the review and the role of the reviewer.

The developer in setting up the template will bind the data of role and review type (QC Type). Also, on the review template is a series of context boxes in which the developer can place custom content. This is a coach view(s) such as data entry or attached documents that contain the data to be reviewed. Examples may be document viewers, a Coach View of data to be reviewed and so forth.

Approval Process Flow

Before we learn about how the template can be implemented, let’s see how the template be used in a process flow. There is an example of a mock process you can find the process definition inside the toolkit named “Simple Hiring Approval”
Figure 1 shows the “Simple Hiring Approval” process flow that shall be used to demonstrate the review framework in action.

Figure 1: Simple Hiring Approval Process Definition
  1. Input Data Task: a human task where the HR admin will input applicant’s data for the manager to approve
  2. Approval Task: a human task where the HR manager will review the applicant data. In this task we will see how the Review Template will be implemented
  3. Approval Gateway: an exclusive gateway to decide the process flow based on approval task results
  4. Hiring Process: a linked process to the supposed hiring process of the approved applicant. In the toolkit example this linked process is for the purpose of giving context and illustration for the process example and thus it is empty.

Let’s simulate the process flow and see how the approval works. Figure 2 shows the process flow when ran and reach the first task.

Figures 2: Input Data task

In the task, there will be input fields for the HR admin to be approved for the HR manager. The data will be passed over to the next task in the process. Figure 3 shows the screen on approval task.

Figure 3: Approval Task

In the task, we can see the previous data inputted by the HR admin in previous step. On the right panel we see an approval checklist which the HR Manager uses as a guide to the review making sure they especially check these items. This screen is using the Review Template from the Review Template toolkit, how it works will be explained next.

Approval Container Layout

The approval container coach view is made up of four content boxes which allows the developer to build up the data needed by the reviewer. These content boxes surround the reviewer checklist. Figure 4 shows the template in use this can be found in the example toolkit in the CSHS named “Approval & QC Template Example”.

Figure 4: Approval Container CV in a coach
  1. Main body of the CV: Consist of panels and table that contain the checklist items and textbox to put the comment
  2. Content-box 1: located on top of the coach across other content bellow, can be used to put title for the coach or templates that used in other coach
  3. Content-box 2: located at the left on the main body, here is the recommended place to put the data which the reviewer needs to asses and reference before making the decision for each checklist.
  4. Content-box 3: located on top of the main body, the upper margin is same level as the Left Content-box. Can be used to put additional data for the reviewer
  5. 5. Content-box 4: located on bottom of main body. Can also be used to put additional data.

The use of the content-boxes is optional, Figure 5 shows how it will look when all content box is used, you can run the CSHS “Approval & QC Template Example” in the toolkit

Figure 5: Approval Container CV if the context box is filled with panel

Data Binding

The reviewer’s acceptance/rejection action on the checklist items is mapped onto a business object named QCAcceptanceBO. A variable of this type needs to be bound to the “Approval Container CV” this is shown in Figure 6. This data object retains the outputs and can be used to determine next actions.

Figure 6: CV data binding

Figure 7 shows the variable structure for the “QCAcceptanceBO”

Figure 7: QCAcceptanceBO Parameters
  1. isPassed: Contains the final result of the QC/Approval, if all checklist is passed then the value is true, if one of the checklists is rejected, then the value is false

2. checklist: Contains the checklist items data

  • itemId: ID of the checklist (if available)
  • itemName: Displayed name of the checklist
  • isPassed: true if accepted, false if rejected
  • failedReason: Reason/Comment of each checklist

Configuration Options

The Approval Container CV also requires configuration. There are three configuration sections, let us review these now.

1. Behavior

Figure 8: Configuration Options — Behavior

Allow Comment for OK Item: If unchecked (default), Reason/Comment field will be disabled if the respective checklist item is accepted as shown in Figure 9.

Figure 9: Allow Comment for OK Item Unchecked

And when checked, user can still comment for accepted item

Figure 10: Allow Comment for OK Item Checked

Confirm Message: Message display to confirm when reject or accept all items, the {} will be replaced with “Approve” or “Reject”

Figure 11: Confirmation Modal

2. Appearance

Figure 12: Configuration Options — Appearance

Checklist Table Label: Display name for the Checklist items panel
Left Panel Size: Width size for left section content box
Right Panel Size: Width size for right section where the checklist items located

3. Approval / QC Checklist

Figure 13: Configuration Options: Approval / QC Checklist

Get Checklist Service: Service that will run automatically when the coach started, any service flow can be used, but must use “QCAcceptanceItem” Business Object as the output

Get Checklist Service Input: Variable that will be used as input parameter for the service, it is defined as ANY, so can be bind with any variable type

Checklist Items: Configuration to bind checklist items, use this as alternative for “Get Checklist Service”. If this param is bind and have in it, the checklist will use the value from this parameter and will not run “Get Checklist Service”

Get Checklist Service Example

In the Process Flow example, there is only one approval screen which is the Manager. But there are cases where the business needs a series of approval with a different set of checklist items depends on the role of the approver. These sets of checklist items can be all different or can be similar to some fields be reused across some roles.

For example, let’s say in our process flow example there is additional approval after the HR Manager which is HR Director. The Director role here is to check overall eligibility of the applicant. In this case, the director will have different checklist items for approval.

For example, let’s say in our process flow example there is additional approval after the HR Manager which is HR Director. And in the HR Director screen, it has the same approval checklist. In this case, the HR Manager and HR Director have the same role as an approver. We can handle this by storing the roles and its checklist items in the database and utilize the ability of the review template that can use service flow to get the checklist items, here’s an example.

Figure 14 shows the tables that use for storing roles and checklist items.

Figure 14: QC Tables Diagram

QCFIELD table stores all field items that will appear on approval screen, it stores the FIELD_ID which we can use as an identifier for each item in our code and FIELD_NM is the display name of the field that appears on the screen.
QCROLE table stores the role that differentiate the checklist items set, ROLE_TP is used if we want to categorize more on the role, for example, our roles on recruitment approval are type 1 and roles for reimbursement approval are type 2.
QCFIELDROLE table is to connect between QC field and QC role and where we create the set of fields for that role. Multiple records of the same ROLE_ID can have different FIELD_ID, and FIELD_ID can appear several times for different record with different ROLE_ID, that’s how we can reuse a checklist item on different roles.
You can find the DDL for creating the table on git

Next we see how the table is use in a service flow, you can find the example service “Retrieve QC Acceptance Items By Department And QC Type” in the provided toolkit.

Figure 15: Get Checklist Service Example

In the example service, it uses direct query to get the checklist data from database.

In “Configuration Section” of this article and in figure 13, we show you where to bind the service flow and service inputs. Figure 16 shows an example of the service input that will be the parameter for the query to the database located in Init script.

Figure 16: Service Input

The service input here using ANY data type and it will be passed with a stringified JSON object. In the example, the JSON will consist of department (role) and QC Type which will be used as the input for the query to the database.

Figure 17: Variables in the Service Example & Parsing JSON from Input Variable

Figure 18 shows the SQL query to retrieve the item checklist based on the role.

Figure 18: SQL Query for checklist items

Next step, the Output from the query should be parsed to the output variable of the service, make sure that the output is using “QCAcceptanceItem” Business Object.

Figure 19: Using QCAcceptanceItem as SQL returnType

Using Checklist Item Configuration

If you choose not to use the service to get the checklist, you can do so by binding the checklist items to the CV. Make sure the data you bind is using “QCAccpetanceItem” Business Object.
Here’s example of a script that defining the checklist items.

Architecturally speaking, we recommend the checklist comes from an external data source and is not hard coded. Part of what this framework offers when using external data source for the checklist is a freedom for the business to define and refine the checklist items.
Figure 20: Checklist Item with Business Object

Approval Checklist

In any business involving Approval and QC, there should be a checklist on what the approver should check on. When designing the requirement, please specify the checklist with user depending on their business needs.

Figure 21: Approval List Example

--

--