Approvals are sometimes misrouted or an approver may not have the necessary information to act on the request. This example enables them to assign their approval to someone else.
Add another option to the approval question:
Is this request approved?
- Assign to someone else
When the approval is assigned to someone else, allow the approver to choose another approver. This will effectively close the first approval.
This task tree is based on the typical approval task tree used in Kinetic Request version 5.03 and above when the approval is a separate service item deferred from the original.
Very simply, if the approval question is answered with "Reassign", we want to use a Create Approval node and return the flow to close this approval. The "Assign to proxy" connector has the condition:
We must make the "Create Approval" handler smart enough to know if it was spawned by the original request or another approval. It must be capable of the following no matter how many times its been reassigned:
- Creating another approval if it's reassigned to someone else.
- Returning control to the original request if approved or denied.
For this we need to modify the node.xml file of the handler and change the way that certain parameters are used with it.
If we are creating an approval from another approval, the lookup Id parameter must use the Lookup Id from the existing approval instead of the Customer Survey Instance ID.
Create Approval node from the task tree
Our new approval is also deferred, which means that is must know where it comes from so that it can return control to the tree. Deferred tasks are given a token for this purpose but in the case of a reassigned approval, the new approval must be given the original token so that it can return control to the original task tree.
All of this means we must have a place to store the original token, no matter which approval we are dealing with. So, we are going to add a source label name to our dataset called 'Original Deferred Token'. In this case, we use field 'Multi-Purpose Info'. Normally tokens are stored in a field called "ng_EndpointSecret" but we also want to store it in Multi-Purpose Info so we will modify the node.xml file of the handler for this purpose. (Don't forget to remove Multi-Purpose Info from the "Cloned Fields" section)
<!-- Store the deferral token so that the approval workflow can close the deferred task upon completion. --> <field name='ng_EndpointSecret'><%= @task['Deferral Token'] %></field> <!-- Store the deferral token from the original approval so that subsequent approvals will still continue on the original service item --> <field name='Multi-Purpose Info'><%= @base['Multi-Purpose Info'].nil? ? @task['Deferral Token'] : @base['Multi-Purpose Info'] %></field>
The first two lines are already included in the node.xml file. This is the usual way that the deferral token gets passed to the service item created. We have added a mapping here for 'Multi-Purpose Info' that will also push the deferral token into it, but only if it's nil. Otherwise, it just uses 'Multi-Purpose Info' from the parent service item (in which case it would be an existing approval). This way 'Multi-Purpose Info' always has the token from the original approval create. We will need this token when the final approver either approves or denies the request so that we can pass control back to the original tree.
"Continue Original Request" node from the task tree
- Add an option to reassign an approval on the approval service item
- Choose a field to store the original deferral token from the first approval
- Modify the node.xml of the create approval handler so the original deferral token is always stored in this field
- Create or modify your approval task tree so that you can create another approval if it's reassigned, and include a "Create Trigger" node that uses the original deferred token if it's not reassigned.