Chat now with support
Chat with Support

Identity Manager On Demand - Starling Edition Hosted - 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

Automatically approving requests

Approvers may be involved in an approval process more than once, for example, if they are also requesters or determined as approvers in various approval steps. In such cases, the approval process can be speeded up with automatic approval.

NOTE: Automatic approvals apply to all fallback approvers but not to the chief approval team.

Use configuration parameters to specify when automatic approvals are used. You can specify exceptions from default behavior for individual approval steps. Specify the behavior you expect in the following configuration parameters and approval steps.

  • QER | ITShop | DecisionOnInsert configuration parameter

  • QER | ITShop | AutoDecision configuration parameter

  • QER | ITShop | ReuseDecision configuration parameter

  • No automatic approval option in the approval step

Summary of configuration options

Approval steps are automatically approved or denied if:

  • The QER | ITShop | DecisionOnInsert configuration parameter is set.

    The No automatic approval option is not set.

    - OR -

  • The QER | ITShop | AutoDecision configuration parameter is set.

    The No automatic approval option is not set.

    - OR -

  • The QER | ITShop | ReuseDecision configuration parameter is set.

    The No automatic approval option is not set.

Requests are manually approved or denied if:

  • The QER | ITShop | DecisionOnInsert configuration parameter is not set.

    - OR -

  • The QER | ITShop | AutoDecision configuration parameter is not set.

    - OR -

  • The QER | ITShop | ReuseDecision configuration parameter is not set.

    - OR -

  • The No automatic approval option is set.

Detailed information about this topic
Related topics

Configuring automatic approval

Scenario: An approver can grant or deny approval in several approval steps.

An approver may be authorized to approve several levels of an approval workflow. By default, the request is presented to the approver in each approval level. You can allow automatic approval so that the approver is not presented with a request more than once.

To allow an approver's decisions to be met automatically in several sequential approval levels

  • In the Designer, set the QER | ITShop | AutoDecision configuration parameter.

    The approval decision of the first approval levels is applied to subsequent approval levels for which the approver is authorized.

    The configuration parameter takes effect if the No automatic approval option is not enabled for the approval step.

To attain automatic acceptance of an approver's approval decisions for subsequent approval levels

  • In the Designer, set the QER | ITShop | ReuseDecision configuration parameter.

    If the approver granted approval to this request in an earlier approval step, the approval decision is passed on irrespective of how the approval steps in between were approved. If the approver did not grant approval in an earlier approval step, the request is presented for approval again.

    The configuration parameter takes effect if the No automatic approval option is not enabled for the approval step.

    Important: If the approver is also an exception approver for compliance rule violations, requests that violate compliance rules will also be automatically approved without being presented for exception approval.
Scenario: Requester is also approver

Approvers can run requests for themselves. If a requester is determined to be approver for the request, their approval steps are immediately granted approval.

To prevent automatic approval for an approver's requests

  • In the Designer, disable the QER | ITShop | DecisionOnInsert configuration parameter.

    If a requester is determined to be the approver of an approval step, the request is presented to the requester to be approved.

The QER | ITShop | DecisionOnInsert configuration parameter is set by default and takes effect if the No automatic approval option is not enabled in the approval step.

If the QER | ITShop | PersonInsertedNoDecide configuration parameter is set, the requester does not become an approver and cannot approve the request. Also, the request cannot be decided automatically.

Preventing automatic approval in individual cases

For single approval steps, you can configure exceptions to the general rule in the configuration parameters.

To prevent automatic approvals for particular approval steps

  • Enable the No automatic approval option in the approval step.

    The QER | ITShop | DecisionOnInsert, QER | ITShop | ReuseDecision, and QER | ITShop | AutoDecision configuration parameters are not considered in this approval step. In each case, requests are to be presented to the approver of this approval step.

Related topics

Approval by peer group analysis

Using peer group analysis, approval for requests can be granted or denied automatically. For example, a peer group might be all identities in the same department. Peer group analysis assumes that these identities require the same products. So, if a company resource has already been assigned to a majority of employees in a department, a new request for this company resource is automatically approved. This helps to accelerate approval processes.

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

The proportion of identities of a peer group who must already own the company resource, is set in the QER | ITShop | PeerGroupAnalysis | ApprovalThreshold configuration parameter. The threshold specifies the ratio of the total number of identities in the peer group to the number of identities in the peer group who already own this product.

You can also specify that employees are not allowed to request cross-functional products, which means, if the requested product and the primary department of the request recipient are from different functional areas, the request should be denied. To include this check in peer group analysis, set the QER | ITShop | PeerGroupAnalysis | CheckCrossfunctionalAssignment configuration parameter.

Requests are automatically approved for fully configured peer group analysis, if both:

  • The requested product is not cross-functional

  • The number of identities in the peer group who already own this product equals or exceeds the given threshold.

If this is not the case, requests are automatically denied.

To use this functionality, the One Identity Manager provides the QER_PersonWantsOrg_Peer group analysis process and the PeergroupAnalysis event. The process is run using an approval step with the EX approval procedure.

Detailed information about this topic
Related topics

Configuring peer group analysis for requests

To configure peer groups

  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. To specify a threshold for the peer group, set the QER | ITShop | PeerGroupAnalysis | ApprovalThreshold configuration parameter and specify 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 request can be approved.

  4. (Optional) To check whether the requested product is cross-functional, enable the QER | ITShop | PeerGroupAnalysis | CheckCrossfunctionalAssignment configuration parameter.

    1. Assign the service items and departments to functional areas.

      Only functional areas that are primary assigned service items are taken into account.

      For more information about functional areas, see the One Identity Manager Identity Management Base Module Administration Guide.

    2. Assign identities to primary departments.

  5. In the Manager, create an approval workflow with at least one approval level. For the approval step, enter at least the following data:

    • Single step: EXWithPeerGroupAnalysis.

    • Approval procedure: EX

    • Event: PeerGroupAnalysis

    The event starts the QER_PersonWantsOrg_Peer group analysis process, which runs the QER_PeerGroupAnalysis script.

    The script runs automatic approval and sets the approval step type to Grant or Deny.

Detailed information about this topic
Related topics
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating