In this document we discuss, “Manager Approval Workflow”, which is one of the out-of-the-box workflows provided by IDHub.

Manager Approval Workflow Description

In this section we explain the steps and flows, taken by IDHub, to execute the “Manager Approval Workflow”.

  • The first step is a “State Node”. A state is one of the several states/statuses in IDHub. This represents a request state in the workflow. This node does not perform any function. A flow is stopped when this node is reached. When a request is submitted, by default, the state is “Request Submitted”. The first step in this workflow is “Request Submitted” state node.

  • In the next step, we have the “Action Node”. The Action Node denotes a task action, or a workflow action. It is present immediately after the state node, and it is used to trigger a flow. In our case, the action node would be “Start”.

  • Thirdly, we have the “Operation Node”. This node is used to perform small atomic operations, required to complete a transition. Operation Nodes are custom developed nodes, used to perform a particular function.

    • Manager Approval Task operation node, means the request is submitted to the manager of the beneficiary user.
      Next we have the state node, and the state of the request workflow which is Waiting for Manager Approval.

At this point, the manager of the beneficiary user, would make the decision to Reject or Approve the task. Depending on the decision, IDHub would process the flow accordingly. Below are the steps for both scenarios.

*Flow steps are below, if the task has been REJECTED by the manager of the beneficiary user.

  • In this case, we have the Manager Reject action node, which denotes that the task has been rejected by the manager.

  • The request is now deemed complete, and we have the state node “Request Completed”.

*Flow steps are below, if the task has been APPROVED by the manager of the beneficiary user.

  • In this case we have the Manager Approve action node, which denotes that the task has been approved by the manager.

  • After that we have the Complete Approval operation node. This is a JSON object, which updates the request, and makes the statues of the request as “Waiting for Dependent Request”.

Fulfill Action Node

Next, We have the Fulfill action node. At this point, the system would follow the flow, depending on whether the application is connected or disconnected. Below we discuss the flow steps for each scenario.

*Flow steps are below, for DISCONNECTED Applications.

  • In this case, the request workflow would be generating a Fulfillment Task for the fulfiller. Therefore, we have the “Fulfillment Task” operation node.

  • Next, we have the “Waiting for Fulfillment” state node.

*Flow steps are below, for CONNECTED Applications.

  • If the application is connected, there is no fulfillment task generated, and the workflow directly converts the state of the request to “Waiting for Fulfillment”.

Accept or Reject By Fulfiller

Now the fulfiller can either fulfill the request and provision the application, or the fulfiller can reject the request. Below are steps for both scenarios.

*Flow steps are below, if the task has been REJECTED by the Fulfiller.

  • In this case, we have the Fulfillment Reject action node, which denotes that the task has been rejected by the Fulfiller.

  • The request is now deemed complete, and we have the state node “Request Completed”.

*Flow steps are below, if the task has been APPROVED by the Fulfiller.

  • In this case, we have the Fulfillment Approve action node, which denotes the task has been approved by the Fulfiller.

  • The request is now deemed complete, and we have the state node “Request Completed”.