Hi All,
In SailPoint IIQ, one of the important things to understand more is approvals mode. Approvals are used at the time of approving work items, like access request items, identity refresh items, or any provisioning activity if you configure for approvals. The approver will receive the item to take a decision accordingly, either approve or not.
We have approval mode types when we configure multiple users as approvers approver (You can also customize it if you want). Those are like the following.
- Serial
- SerialPoll
- Parallel
- ParallelPoll
- Any
Navigate the option: Go to the LCM Provisioning workflow → Process Variables → Approval
We have 4 options available to select for approvers as shown in the above diagram.
Navigate the option: Go to the LCM Provisioning workflow → Process Variables → Approval → Advanced View → approvalMode.
A string that specifies how we should handle the approvals. By default, this is serial since most of these requests, with the exception of manager transfers, will have only one approver. Parallel approvals are processed concurrently, and there must be consensus.
Serial: Approvals are executed one after another in sequential order. If the first one approves it, it goes to the second one. If the second one is approved, it goes to the third and so on until all child approvals are completed (Assume work items have multiple approvals).
Approvers are specified in one order, and the work item is being passed to each approver in that order only. If any approver in the chain rejects, then the item is also rejected automatically.
Ex: Approvals has 3 owners.
The initial approval will be on the owner 1, on Approve. The next approver will be on the owner 2, on Approve. The next approval will be on the owner 3.
In between approvals, any approver rejects, the work item is also be rejected.
SerialPoll: Approvals are executed one after another in sequential order. If the first one approves/rejects it, it still goes to the second. If the second one approves/rejects it, it goes to the third, and so on. Until all the child approvals are completed. i.e., we are conducting a poll among the approvers either to vote for approval or rejection one after another.
Approvers are specified in order, and the item is passed to each approver in that order. Data is collected on approvals and rejections, but rejection by one does not mean rejection of the item: action decision is expected to be specified in the AfterScript logic. Like, based on certain approvals, either reject or approve.
Ex: Approval has 3 owners.
Initial approval will be on the owner 1, on Approve/Rejection. Next approval will be on the owner 2, on Approva/Rejection. Next approval will be on the owner 3.
In between any approvers rejects, the work item is not being rejected. The action decision is expected to be specified in the AfterScript logic.
Parallel: In the Parallel, all approvals for work items will get a time to approve or reject. So, if the first person approves, then it will wait for the next one’s decision. If the second person is approved, then it will wait for the next approvers and so on. If any one of them is rejected, then the entire work item will be rejected. So that means everyone has to approve it, and then only the work item will be approved. Otherwise the work item will be rejected.
ParallelPoll: In ParallelPoll, everything is the same as Parallel, but the difference is, if you rejected it, then the work item will not be rejected. It will go for the next approvals if you mentioned it in the AfterScript logic.
The Approval step also includes a very important AfterScript, which tells the workflow what to do when the approval finishes. In the default workflow, the after script calls a rule library and a workflow library method to “assimilate” the approval decisions back into the workflow’s master approvalSet object and into the identity request. The default logic in this assimilation process is that if any reviewer rejected the item, the item is marked as rejected in the workflow’s master approvalSet and therefore ultimately will not be provisioned for the target user. This after script also creates audit events to record details about the decisions in the audit logs, depending on which audit events are enabled for the environment. We can see or include this AfterScript in the approval step of the workflow.
Any: In Any mode, we can define to take a decision by anyone on the list. For example, all the members of that AD group should get the work item, but anyone from that group is supposed to approve/reject the work item. So, we can get the group members from the ManagedAttribute object and specify them as the owners of the work item as a comma-separated identity list in the script by having approvalMode set to “any.”.
For testing the above approval modes, you can do the Manage Account thing for quick testing (make sure you configure it like above explained). Like raise an account request for any application to any identity and check in the tracky my request. You will get all those things one by one after approvals are done.
For more information about it check the LCM Subprocess Workflows: https://community.sailpoint.com/t5/Technical-White-Papers/LCM-Subprocess-Workflows/ta-p/75856