サポートと今すぐチャット
サポートとのチャット

Identity Manager On Demand 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 the 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 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 Managing an IT Shop
IT Shop base data Setting up IT Shop structures Setting up a customer node Deleting IT Shop structures Templates for automatically filling the IT Shop Custom mail templates for notifications Request templates 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

Setting up approver restrictions

To prevent recipients of requests becoming approvers

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

    This configuration parameter takes effect if the Approval by affected employee option is not set on the approval step.

To prevent requesters becoming approvers

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

    This configuration parameter takes effect if the Approval by affected employee option is not set on the approval step.

For individual approval workflows, you can allow exceptions to the general rule in the PersonInsertedNoDecide and PersonOrderedNoDecide configuration parameters. Use these options to allow the requester or recipient of requests to make approval decisions themselves in single approval steps.

To allow request recipients or requesters to become approvers in certain cases

  • On the approval step, enable the Approval by affected employee option.

Related topics

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 for 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 for an approver's decisions for all non-sequential 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 transferred. 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 employees in the same department. Peer group analysis assumes that these employees 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 employees with the same manager or belonging to the same primary or secondary department as the request's recipient. Configuration parameters specify which employee belong to the peer group. At least one of the following configuration parameters must be set.

  • QER | ITShop | PeerGroupAnalysis | IncludeManager: Employees that have the same manager as the request's recipient

  • QER | ITShop | PeerGroupAnalysis | IncludePrimaryDepartment: Employees that belong to the same primary department as the request's recipient

  • QER | ITShop | PeerGroupAnalysis | IncludeSecondaryDepartment: Employees whose secondary department corresponds to the primary or secondary department of the request's recipient

The proportion of employees 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 employees in the peer group to the number of employees 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 employees 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
関連ドキュメント

The document was helpful.

評価を選択

I easily found the information I needed.

評価を選択