Parts of the Process
There are many different ways to use approvals in Kinetic Request and Kinetic Task. However, all most all break down into a similar process, a request triggers a tree that has an approval included, an approval service item with information about that original request is sent to a designated approver(s), the approver(s) responds, and the response is sent back to the original request/tree for follow-up actions.
The first part of the approval process is the original request. Important to make sure you have all the information needed about any and all approvers. Often this is just the ID (email, user ID, etc), but it could be related to a product or site. Most of the information about approvers is collected in the task tree, so make sure that it is available and can be accessed.
The second part is to add the approval task node (and any accompanying process) to your task tree. There is an Approval Task handler available for download that covers all the basics. Many new customer have been taking advantage of the sub-tree functionality for approvals. This is often the most difficult part of the process because it involves both business and technical inputs.
The third part is determining how to display the requested information to the approver. Our "normal" process is to use a generic approval service item. It includes a review request section and all of the questions an approver needs to indicate if the request is approved, denied, or something in between.
The fourth part of the approval process is the approval task tree creation. This is normally a small tree, but includes some vital functionality.
The last 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.
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.
Example of basic approval process
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
Here is an example of the approval task.
This is a basic approval task that will send a notification to the designated approver.
The approval request is an almost exact duplicat of the original requesters request. It has a Submit Type of Approval, and the Originating ID and the Lookup ID are set to the instance Id of the original request. All the attributes are copied to the new approval request.
Creating the Approval Submission Branch
While the Approval Node will create an approval record, once the approval is complete you are responsible for creating a trigger that prompts the original tree to complete the approval node and continue processing.
A typical Approval Tree:
Create 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 - <%=@answers['Approve?']%>.
If you want to pass more than one result, simply build up more XML nodes.
Example Create Trigger:
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. Bu default it only closes the currently active submission (request). In most cases you will set the validation status to the result of the approval question, but this decision is up to the task builder and the requirements of the business process.
There is a wrap up activity to create a service item and the approval.