The first step is to set up an approval service item that will be used to do approvals. The difference from a standard approval would be an additional approval option. Instead of just "Approved" and "Denied", the approver will also have an option of "Delegate". When the approver selects this option, they are prompted to search for the individual they wish to delegate to.
Once a portion of a last name has been entered, if there is more than one match, whatever facility your theme/company uses to display that information can be used (SDR, Bridges, etc). This example uses the most basic method of a set fields external event because that is not the focus of this example, the tree/flow is.
And once a delegate is selected, the approver can submit the approval, but the item isn't approved, the approval is then sent to this new individual, and the same process should be used as was used the first time around to create the original approval--this is the perfect example of a use case for a recursive subtree/routine.
The actual approval's complete tree is extremely simple, it just completes the approval and continues the original request with certain return/result values.
<results> <result name='Validation Status'><%=@answers['Approved?']%></result> <result name='Reason'><%=@answers['Reason']%></result> <result name='Delegate'><%=@answers['Proxy_Login ID']%></result> </results>
The individual approval flow is created as a subtree/routine, then, if the approver delegates, we want to call that exact same process again, from within that individual flow. So the next step is to create the individual approval subtree/routine. The example here is a subtree (3.1.1). All information needed to process anything for the approval must be passed to the subtree, so these items are set up as inputs to the subtree. Since this is an individual approval, who the expected approver is meant to be is one of the inputs, as is the request being approved and the catalog the approval template is in (both needed for the approval itself), then there may be other inputs necessary for logic or notifications such as the requested for, submitter, or KSR # of the request being approved.
The outputs of the subtree need to be set up as well. The individual approval needs to return it's status (approved, denied, etc) and possibly a reason. Then it is up to the calling tree to process that information.
Then the flow of the individual approval can be built. The flow of the example provided is included and reviewed below.
The Needs Approval? Is a No-op node that allows for some logic at the beginning of the tree. the self-approval logic looks like this:
<%=@inputs['reqfor'] == @inputs['approver'] %>
The return node after it returns a Validation Status of Approved with no Reason. This prevents any approver from ever getting an approval for something requested for them, as an example.
Down the other path:
<%=@inputs['reqfor'] != @inputs['approver'] %>
Then, if the approval is delegated:
<%=@results['Individual Approval']['Validation Status'] == "Delegated"%>
The same subtree we are in is used as a node, where all the inputs to the delegate tree are the same as the current tree except the approver, which is the delegate selected in the approval (which is passed back from that approval as a result).
When the delegation subtree returns, this tree then needs to return those results as well.
Down the other path, if the approval wasn't delegated, the approval subtree can return its results from the approval node.
Once the approval subtree/routine is created, it can be used in the service request tree for the original approval:
So now the request calls the tree, which calls the approval service item, and depending on the results of that, calls itself again, so all of our components are hooked together and the tree is recursive.
An example request (which does nothing after the approval), approval, and individual approval subtree are included in the package on this article. They reference the klean theme, so you will have to point them to your theme files, and the catalog is not included in the export, so you will need to move the items into one of your development catalogs to work with them. Note the notification templates they rely upon. You'll want to replace those references or move those into the same catalog.
This example references/uses BMC Remedy CTM:People from the ITSM suite. If you do not use Remedy ITSM, you can still load the service items and tree to examine how they function. Changing them to use a different people source (if you wished to) would be changing one External Data Request in the Approval, one lookup in the subtree, and a couple of lookups in the service item/request.
These items/trees are not meant for deployment in any real/production environment. They are meant to be examples of a concept. Your system requirements may be very different from these. You may require an individual approver tree also send approvals to that individual's alternate approvers, or you may not allow automatic self-approval. Please evaluate these items for compliance with your company's process requirements before using them for anything beyond conceptual examples.
The service items/trees attached use these handlers: