Fischer provides a function to build out escalation conditions. Escalate conditions can be defined for specific access requests, or you can define global escalation conditions that can be used across multiple approval workflows. The scenario to consider here is when utilizing an escalation path, in many cases, the same group of people or individuals may be responsible for any escalations. In this case, you can build a global escalation workflow configuration and leverage the global escalation path for N access request workflows. This provides you with the ability to define a single escalation path and apply it to multiple request / approval workflows. If necessary, you can define distinct escalation paths for different approval workflows. Your thought process must include and consider the resources to be approved as you determine if a global escalation or distinct escalation workflows are required to meet your business requirements. The good thing about Fischer is you can easily define both and scale to meet your business requirements rather simplistically.
Defining escalation conditions starts with access the "Escalation Conditions" configuration as seen below:
The configuration process begins by clicking "Add", and you will be re-directed the the configuration screen:
Configuring an approval escalation is a combination of defining the approver lists to be associated with this particular escalation as well as setting a series of approval workflow settings that will control how the escalation will act at run time. The item to configure is the approver lists (as seen above). Click "Add" will take you to the approver list definitions. Note that you can select one more multiple approver lists to be a part of this escalation path. If you define more than one approver list to be a part of the escalation workflow note that notification will be controlled by the "Routing Manner" configuration under "Condition Details".
Routing Manner
| 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. |