When you define approval conditions you are configuring the Fischer product to invoke a specific business process (approval workflow). Approval conditions are required in order to define a master approval. You can access the approval conditions configuration from here:
To add your own approval condition configuration, click "Add". Once you click add, you will be directed to the approval condition configuration interface:
Approver Lists
This section is where you will pull in your defined approver lists. Keep in mind what you are building this particular approval for, as that will dictate which approver list(s) you should select. The below sections will outline in more detail how the approver lists will be leveraged depending upon how you've configured your approval condition details.
Condition Details
| Serial | |
The serial routing manner refers to a serialized process. Notifying each approver (as defined in the approver lists selected) will be notified in a serial manner. This means that each approver list itself will receive notification for action in whatever order you define. Note that the serialized routing manner will start at the top of the included approver lists and work its way down the lists. It is also important to remember that there may be more than one individual that is defined within each approver list. In the scenario where you select a serialized routing manner, this does not necessarily mean that within a given approver list, Fischer will notify each approver 1 by 1, rather in this context it uses the list of people resolved and will notify everyone on the list. If you want to serialize so that individual people get notified 1 by 1, you should consider using approver lists that only resolve to a single individual. |
|
| Parallel (Quorum) | |
| The second supported routing manner is parrallel or what some may call a quorum. When an approval is defined to leverage a quorum-based routing manner, ALL approvers that are attached to a given approval layer will be notified simultaneously (in parallel). | |
| Type of Approval | |
|
If the quorum routing manner is selected, Fischer will dynamically determine based on the defined approvers list(s) defined within the approval. If more than one approver is associated with the approval, Fischer will enable the "Type of Approval" option. This combo box has 3 options. (1) Any User (2) All Users (3) At Least The options provide governance over each distinct approval configuration and can be defined depending upon the actual resources the approval will be employed to protect prior to granting access. If Any User is selected, this means that if any approval authority in the quorum approves the request, the request will be considered approved at that particular layer of approval. Multiple Approval Layers Note that multiple layers of approval workflows can be configured and associated with a single approval process. Furthermore the routing mannger and type of approval as well as a few other settings to be discussed below, specifically Quorum for Approval Action and Approver Timeout Duration, as well as the settings already discussed above can be set differently at each distinct approval layer. |
|
| Quorum for Approval Action | |
|
If the quorum routing manner is selected, and "At Least" is the "Type of Approval", the Quorum for Approval Action input box will enable. This field is intended to provide IGA Administrators with the ability to set the total number of approvers that must approve a request within the quorum before the request will be considered approved. An example would be if 10 approvers are assigned to a given approval process, and the Type of Approval is Quorum and the organization decides that the majority of the approvers must approve the request, then you would set the value to 6, since 6 creates a quorum (or it meets the threshold of more approvers approved the request than denied it) therefore this approval layer will complete and this particular layer of approval's response to the process would be "Approved" What happens to the request for the other approval authorities that did not approve the request? In the example of above where 6 out of the 10 within the quorum approve the request, the 4 individuals that did not take action will see the approval status change to complete (or denied depending on the decision made). The 4 approvers that did not take action, will not have to take action since the quorum of 6 out of 10 has been met. |
|
| Approver Timeout Duration | |
| IGA Administrators can set time-out thresholds for each distinct layer of approval. This helps to ensure that approvals do not go stale or unseen. Approvals are an important step of the governance process as they provide authorized personnel with the ability to control who has access to what. When approvals are initiated, it is important for IGA products to offer automated mechanisms to ensure the approval request is seen and acted upon. Fischer's timeout feature can force the approver to take action or risk the request being escalated up the hierarchy. This feature should also be deployed as a stop gap from a business process point of view as it will make certain that no request is left behind. | |
| Exception Behavior | |
| Exception behavior is available when dynamic, hierarchical and external LDAP approver lists are defined. Fischer will auto-detect the approver list type defined within the escalation condition and enable this feature if some form of dynamic filtering is defined to determine the approvers at run time. This feature is to provide exception handling in the case where the approver list does not resolve to a person. |