Parts of the Process
Approvals in Kinetic Request are static, dynamic, or a combination of both. By using task dependencies and/or qualifications, you can have just a static one person approval for all requests, or an approval that depends on both static and dynamic values from the request. Kinetic Request also allows backup approvers.
The first part of the approval process is the request. If your approval is static, this section just needs to collect up the information you need about the request. If your approval will be based on information collected during the request, make sure everything you need is present.
The second part is to determine how to display the requested information to the approver. You may use the same service item as the original submission, or set up a different service item to be used for approval display (using Review Request). This method is particularly useful for large service catalogs and using the Review Request functionality makes this simple and provides a nice display for the approver. Kinetic Request uses a “Submit Type” global variable to sense when a service item is being displayed during an approval.
The third part of the approval process is the approval task creation. Before creating the approval task tree, you need buy-in from everyone that will be required to approve requests. This may be as simple as looking up the requester’s manager or may be more complex based on your specific approval routing requirements.
The fourth part of the process is notifications. Will showing the approval on a launcher page be enough for your customers, or will they need email or some other form of notification? You may end up creating multiple message templates per request.
Approval Tree Basics
Because any submitted request can start a task tree process, you need to identify the type of the current submission. Kinetic Request uses the field Submit Type (on the KS_SRV_CustomerSurvey_base form) to identify if the current request is an approval or not. You can use this information to limit which submissions will process all or parts of your task tree, by adding a qualification to your connectors.
Here is an example of a qualification the limits the task tree to run only on the initial submission:
<%=@dataset['Submit Type'] != "Approval"%>
The connector will check the dataset value of the field Submit Type and compare to a value of “Approval”.
Normally a qualification like this is placed on the first connector from the Start node.
Designating someone as an approver can be as easy as typing in their name and a few other details. Or, your approver could be identified by the person filling out the request, or by a combination of values in your request. It could be as complicated as the service item and your internal processes dictate.
Add tasks to perform lookups to establish who the approver should be. Lookups to locate alternate and backup approvers should also be done prior to the execution of the approval creation task.
On occasion, a Task Handler may need to be created to accommodate complex approval routing rules.
Adding the Approval Task
Creating an approval task is similar to any other task node configuration.
This is a basic approval task that will send a notification to someone asking for the service item submission to be approved.
Initial Status is set automatically to “In Progress”, and the other messages are defined by you. These should be informative to your approvers. If the approval creation is dynamic, selection criteria is placed on the Connector leading into the approval Task Node.
Adding reminders to your approval process will ensure that approvals and submissions are not forgotten. Using the Wait task gives you the ability to configure a deferral that waits for hours, days or weeks.
Creating the Approval Submission Branch
While the Approval Node will create an approval record, once the approval is complete you are responsible for checking the answer, and creating a trigger that prompts the original tree to complete the approval node and continue processing.
A typical Approval Submission branch has the following nodes:
- Evaluate Approval
This is an Eval node from the System Utilities Category. In the Code field, you will create Ruby code that checks the answer to the approval question, and outputs a result that can be used by fields and connectors further down the branch.
Here is an example of the code:
"<%=@answers['Is this request approved?']%>" == "Approved" ? "Approved" : "Denied"
The first section (to the left of the question mark) returns the approval question answer and compares it to a text value. If the comparison is true, it returns the value before the colon. Otherwise it returns the value after the colon.
If you just want to use the answer from the approval question for comparison, that is fine, you can leave this node out. The Eval node is useful if you have a more complex decision to check for the approval. For example, you code have an approval question with more than just approved|denied as possibilities.
- Approval Trigger
This is a create Trigger node from the System utilities category. The Action Type is set to “Complete”. The Deferral Token field is set to a Data Set value that references the field ng_EndpointSecret (normally called Deferral Token – your name may be different). The Deferral Results field contains an XML string that is passed to the approval node for use as results. Here is an example of an XML results string:
<result name='Validation Status'><%=@results['Evaluate Approval']['result']%></result>
The inner node (the <result> tags) includes the name of the result (Validation Status in the example) and the code to reference the result from the Eval node - <%=@results['Evaluate Approval']['result']%>.
If you want to pass more than one result, simply build up more XML nodes.
- Close Submission
The last required trigger sets the Request Status on the approval submission to Closed, and allows you to set the Validation Status to the value you want. By default it only closes the currently active submission (request). In most cases you will set the validation status to the result of the Eval node, but this decision is up to the task builder and the requirements of the business process.
The nodes described are the same if you are using the same service item or a separate service item for your approval. If you are using the same service item for the approval, you need to restrict the approval submission branch from the start node by putting a qualification on the initial connector. Here is an example of that qualification:
<%=@dataset['Submit Type'] == "Approval"%>
Customizing Approval Branches
The nodes described above are just the basics, you can certainly add more nodes to match your own business process.
- Notifications of approval or denial
- Ticket creation
- Work Note creation