Chatta subito con l'assistenza
Chat con il supporto

Identity Manager 9.2 - IT Shop Administration Guide

Setting up an IT Shop solution
One Identity Manager users in the IT Shop Implementing the IT Shop Using the IT Shop with the Application Governance Module Requestable products Preparing products for requesting Assigning and removing products Preparing the IT Shop for multi-factor authentication Assignment requests Delegations Creating IT Shop requests from existing user accounts, assignments, and role memberships Adding system entitlements automatically to the IT Shop Deleting unused application roles for product owners
Approval processes for IT Shop requests
Approval policies for requests Approval workflows for requests Determining effective approval policies Selecting responsible approvers Request risk analysis Testing requests for rule compliance Approving requests from an approver Automatically approving requests Approval by peer group analysis Approval recommendations for requests Gathering further information about a request Appointing other approvers Escalating an approval step Approvers cannot be established Automatic approval on timeout Halting a request on timeout Approval by the chief approval team Approving requests with terms of use Using default approval processes
Request sequence
The request overview Requesting products more than once Requests with limited validity period Relocating a customer or product to another shop Changing approval workflows of pending requests Requests for employees Requesting change of manager for an employee Canceling requests Unsubscribe products Notifications in the request process Approval by mail Adaptive cards approval Requests with limited validity period for changed role memberships Requests from permanently deactivated identities Deleting request procedures and deputizations
Managing an IT Shop
IT Shop base data Setting up IT Shop structures Setting up a customer node Deleting IT Shop structures Restructuring the IT Shop Templates for automatically filling the IT Shop Custom mail templates for notifications Product bundles Recommendations and tips for transporting IT Shop components with the Database Transporter
Troubleshooting errors in the IT Shop Configuration parameters for the IT Shop Request statuses Examples of request results

Criteria for approval recommendations for requests

The following criteria are taken into account when determining recommendations for approving requests.

  1. 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

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

  1. In the Designer, set the QER | ITShop | PeerGroupAnalysis configuration parameter.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Create an approval workflow in the Manager and insert an approval step with the following data as the first approval level:

    • Approval procedure: EX

    • Event: RecommendationAnalysis

    The event starts the QER_PersonWantsOrg_Recommendation process, which runs the QER_PersonWantsOrg_Recommendation script. The script runs automatic approval.

  7. Add an approval level to manual approval.

  8. 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.

  9. (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.

  10. Create an approval policy and assign it to the approval workflow.

    • Use this approval policy in the IT Shop.

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

Appointing other approvers

Once an approval level in the approval workflow has been reached, approvers at this level can appoint another identity to handle the approval. To do this, you have the options described below:

  • Rerouting approvals

    The approver appoints another approval level to carry out approvals. To do this, set up a connection to the approval level in the approval workflow to which an approval decision can be rerouted.

  • Appointing additional approvers

    The approver appoints another identity to carry out the approval. The other approver must make an approval decision in addition to the known approvers. To do this, enable the Additional approver possible option in the approval step.

    The additional approver can reject the approval and return the requests to the original approver. The original approver is informed about this by email. The original approver can appoint another additional approver.

  • Delegate approval

    The approver appoints another identity to carry out the approval. This identity is added to the current approval step as the approver and then makes the approval decision instead of the approver who delegated. To do this, enable the Approval can be delegated option in the approval step.

    The current approver can reject the approval and return the requests to the original approver. The original approver can withdraw the delegation and delegate a different identity, for example, if the other approver is not available.

Email notifications can be sent to the original approvers and the others.

For more information, see the One Identity Manager Web Designer Web Portal User Guide.

Detailed information about this topic
Related topics
Related Documents

The document was helpful.

Seleziona valutazione

I easily found the information I needed.

Seleziona valutazione