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

Group Role Approval Workflow Description

In this section we explain the steps and flows, taken by IDHub, to execute the “Group Role 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.

Users belonging to the role Approver Group1, can either REJECT or APPROVE the request. Below are the steps for both scenarios.

*Flow steps are below, if the task has been REJECTED by a user with the role Approver Group1.

  • In this case, we have the Approver1 Reject action node, which denotes that the task has been rejected by users belonging to the role Approver1.

  • 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 a user with the role Approver Group1.

  • In this case, we have the Approver1 Approve action node, which denotes the task has been approved by users belonging to the role Approver1.

The workflow will now determine whether Approver Group2 is ABSENT or PRESENT. Below are the steps for both scenarios.

*Flow steps are below, if Approver Group2 is ABSENT.

  • In this case, the request workflow for Approver Group2 is ABSENT, so the workflow would go directly to the “Complete Approval” operation node (discussed below).

*Flow steps are below, if Approver Group2 is PRESENT.

  • In this case, we see the Approval Task2 operation node. This means, the request has been sent to the users belonging to the role Approver Group 2. Therefore, the next step is Waiting for Group Approval state node, which means the status of the request is now “Waiting for Group Approval”.

Users belonging to the role Approver Group2, can either REJECT or APPROVE the request. Below are the steps for both scenarios.

*Flow steps are below, if the task has been REJECTED by a user with the role Approver Group2.

  • In this case, we have the Approver2 Reject action node, which denotes that the task has been rejected by users belonging to the role Approver2.

  • 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 a user with the role Approver Group2.

  • In this case, we have the Approver2 Approve action node, which denotes the task has been approved by users belonging to the role Approver2.

The workflow will now determine whether Approver Group3 is ABSENT or PRESENT. Below are the steps for both scenarios.

*Flow steps are below, if Approver Group3 is ABSENT.

  • In this case, the request workflow for Approver Group3 is ABSENT, so the workflow would go directly to the “Complete Approval” operation node (discussed below).

*Flow steps are below, if Approver Group3 is PRESENT.

  • In this case, we see the Approval Task3 operation node. This means, the request has been sent to the users belonging to the role Approver Group3. Therefore, the next step is Waiting for Group Approval state node, which means the status of the request is now “Waiting for Group Approval”.

Users belonging to the role Approver Group3, can either REJECT or APPROVE the request. Below are the steps for both scenarios.

*Flow steps are below, if the task has been REJECTED by a user with the role Approver Group3.

  • In this case, we have the Approver3 Reject action node, which denotes that the task has been rejected by users belonging to the role Approver3.

  • 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 a user with the role Approver Group3.

  • In this case we have the Approver3 Approve action node, which denotes that the task has been approved by users belonging to the role Approver3.

  • The request now moves to operation node “Complete Approval”, discussed below.

Complete Approval Operation Node

  • Complete Approval operation node is a JSON object, which completes the Approval Process. Secondly, we have Complete Request operation node.

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