Re-Routing ITIM Approvals

The ITIM workflow engine can be really quite powerful once you have mastered it but getting the very best of it can require some out-of-the-box thinking.

Take, for example, the ability to re-route approvals. Why would you ever want to do that, you might ask. Well, we might provide a mechanism for an end user to select a particular user population for approving requests which would, of course, mean that the end user will habitually select the wrong user population!

Let's take an example:

Massive Corporation provides a suite of services which are accessed by staff and 3rd parties. Of the 3rd parties, many are users requiring read/write access to data but some are journalists who require access to press releases. Read/Write users should be approved by Read/Write approvers; Journalists should be approved by the Press Release approvers.

Now, let's consider that a journalist attempts to register for access but accidentally selects the Read/Write access. When his request is routed to the Read/Write approvers, the approvers have the ability to either Approve or Reject. What if they wanted to route the request to the Press Release approvers instead?

One solution to this problem might be to embed the approval process in a loop and capture rejections within the loop with an "Are You Sure?" RFI node:

So what's going on here? The Approval node should be understood as should the connection from that node to the script marked APPROVED. This route assumes that approval has been granted.

The rejection route, however, connects to an RFI node. The RFI node could be configured to route the request to some "central" team who has responsibility for validating rejections and routing requests appropriately. The RFI could ask this team to confirm the rejection or select a new approver and, in effect, try the process again.

Rejection confirmation would cause the LOOP to exit, but the selection of a new approver would cause us to go around the LOOP once more. And we can LOOP ad infinitum, if required.

Of course, an RFI is a Request For Information which requires data attributes to be populated on the entity object for the workflow. We would have to attach 2 new attributes to the entity:

• reject
• approver

Reject could be a boolean attribute wherease approver is a container for a role within the system - a role which can be selected using a Search Match.

Now, we have a simple and robust mechanism for re-routing approvals following a rejection. With an RFI node after a rejection, we can even capture Reject Reasons and "sanitise" them just in case we publish the reason back to the user!

Of course, this is just one solution to the problem. There are others. How would you tackle the problem?