Approval recommendations for requests
A further way to accelerate the approval process by making automatic approval decisions, is with approval recommendations. This uses different criteria to determine whether it is reasonable to grant or deny approval for a request. A peer group analysis is performed to determine approval recommendations and other criteria are analyzed. Based on the recommendation, requests can be automatically granted approval. If a denying approval is recommended or a clear recommendation cannot be made, the requests must be submitted to additional approvers. These approvers are shown the approval recommendation and the details of the recommendation so that they can use this information to make an approval decision.
Detailed information about this topic
Criteria for approval recommendations for requests
The following criteria are taken into account when determining recommendations for approving requests.
-
Peer group factor
The number of identities in a peer group that already own the requested product is determined. If this number exceeds the specified threshold, granting approval is recommended. The threshold is specified in the QER | ITShop | Recommendation | PeerGroupThreshold configuration parameter.
Peer groups contain all identities with the same manager or belonging to the same primary or secondary department as the request's recipient. Configuration parameters specify which identity belong to the peer group. At least one of the following configuration parameters must be set.
-
QER | ITShop | PeerGroupAnalysis | IncludeManager: Identities that have the same manager as the request's recipient
-
QER | ITShop | PeerGroupAnalysis | IncludePrimaryDepartment: Identities that belong to the same primary department as the request's recipient
-
QER | ITShop | PeerGroupAnalysis | IncludeSecondaryDepartment: Identities whose secondary department corresponds to the primary or secondary department of the request's recipient
-
Assigned functional area
The requested product and the primary department of the request recipient are checked to see if they are assigned to the same functional area.
-
Compliance rule violations
The request's recipient is checked for violation of current compliance rules if their request is granted approval. Once a rule violation is detected, denying approval is recommended.
-
Risk factor
The risk factor of the request's recipient is calculated. The risk index of the requested product is already taken into account. If this risk index exceeds the specified threshold, denying approval is recommended. The threshold is specified in the QER | ITShop | Recommendation | RiskIndexThreshold configuration parameter.
-
Approval rate
This determines the proportion of approvals for this product in previous requests. For this, all approval procedures with manual approval that are also used in the currently running approval workflow are determined in the approval sequence (PWODecisionHistory). The proportion of approvals for the same product is determined from the entries in the approval sequence.
If the approval rate exceeds the specified threshold, granting approval is recommended. The threshold is specified in the QER | ITShop | Recommendation | ApprovalRateThreshold configuration parameter.
-
Assignment rate
The number of company resource assignments to the request recipient is determined (PersonHasObject) and compared to the average number per identity. If the assignment rate is less that the average per identity, denying approval is recommended.
Recommendation for granting approval
All criteria are fulfilled. That means:
-
The peer group has members and the peer group factor is higher than the threshold (PeerGroupThreshold).
-
Requested product and primary department belong to the same function area. The product is therefore not cross-functional.
-
There are not rule violations.
-
The risk index of the request recipient is lower than the threshold (RiskIndexThreshold).
-
The approval rate is higher than the threshold (ApprovalRateThreshold).
-
The assignment rate is higher than average.
Recommendation for denying approval
At least one of the following criteria applies.
-
The peer group has no members or the peer group factor is lower than the threshold (PeerGroupThreshold).
-
There is at least one rule violation.
-
The assignment rate is less than average.
If at least two of the following criteria apply, denying approval is also recommended.
-
The product is cross-functional.
-
The risk index of the request recipient is higher than the threshold (RiskIndexThreshold).
-
The approval rate is lower than the threshold (ApprovalRateThreshold).
In all other cases, no recommendation is given.
Related topics
Configuring approval recommendations for requests
To use approval recommendations, add an additional approval level to the approval workflows and configure the thresholds. Based on the recommendation, requests can be automatically granted approval. If a denying approval is recommended or a clear recommendation cannot be made, the requests must be submitted to additional approvers. If requests are not approved automatically, define a manual approval level in the event that granting approval is recommended.
The approvers are shown the approval recommendation. They can follow the recommendation or make their own approval decision independently.
TIP: For approval recommendations with automatic approval, One Identity Manager provides the sample workflow Recipient's manager (with approval recommendation). You can use this approval workflow as a template and adjust to suit your requirements. To do this, copy the workflow and add approval levels with manual approval steps.
To configure approval recommendations
-
In the Designer, set the QER | ITShop | PeerGroupAnalysis configuration parameter.
-
Set at least on of the following subparameters:
-
QER | ITShop | PeerGroupAnalysis | IncludeManager: Identities who have the same manager as the request's recipient
-
QER | ITShop | PeerGroupAnalysis | IncludePrimaryDepartment: Identities who belong to the same primary department as the request's recipient
-
QER | ITShop | PeerGroupAnalysis | IncludeSecondaryDepartment: Identities whose secondary department corresponds to the primary or secondary department of the request's recipient
Thus, you specify which identities belong to the peer group. You can also set two or all of the configuration parameters.
-
Specify the threshold for the peer group factor in the QER | ITShop | Recommendation | PeerGroupThreshold configuration parameter. Enter a value between 0 and 1.
The default value is 0.9. That means, at least 90 percent of the peer group members must already have the requested product so that the granting approval can be recommended.
-
Set the threshold for the risk factor in the QER | ITShop | Recommendation | RiskIndexThreshold configuration parameter. Enter a value between 0 and 1.
The default value is 0.5. That means, the request recipient's risk index must be less than 0.5 for granting approval to be recommended.
-
Set the approval rate threshold in the QER | ITShop | Recommendation | ApprovalRateThreshold configuration parameter. Enter a value between 0 and 1.
The default value is 0.5. That means, if more than 50% of all previous requests of this product were approved using the same approval procedure, granting approval is recommended.
-
Create an approval workflow in the Manager and insert an approval step with the following data as the first approval level:
The event starts the QER_PersonWantsOrg_Recommendation process, which runs the QER_PersonWantsOrg_Recommendation script. The script runs automatic approval.
-
Add an approval level to manual approval.
-
In case denying approval might be recommended or no recommendation can be made, connect this approval level to the deny connection point at the first approval level.
-
(Optional) If the request is not to be approved automatically, connect the connection point for granting approval at the first approval level to an approval level for manual approval as well. This means that requests have to be approved manually even if granting approval is recommended.
-
Create an approval policy and assign it to the approval workflow.
Related topics
Gathering further information about a request
Approvers are able to gather additional information about a request. This ability does not, however, replace granting or denying approval for a request. There is no additional approval step required in the approval workflow to obtain the information.
Approvers can request information in form of a question from anybody. The request is placed on hold for the period of the inquiry. Once the queried identity has supplied the necessary information and the approver has made an approval decision, the request is taken off hold. The approver can recall a pending inquiry at any time. The request is taken off hold. The approver’s request and the identity's answer are recorded in the approval flow and are therefore available to the approver.
NOTE: If the approver who made the query is dropped, hold status is revoked. The queried identity must not answer. The request procedure continues.
For more information, see the One Identity Manager Web Designer Web Portal User Guide.
Detailed information about this topic
