Chat now with support
Chat with Support

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

Checking request validity periods

If a customer has requested a product with a limited validity period, the validity period must be tested for validity in subsequent requests for this product for the same customer. If the validity period is not in effect, the request is not permitted. By default, new requests are permitted if they fall in a time period that is not covered by another pending request. However, the validity periods of different requests may not overlap. You can define the desired behavior for the validity period over configuration parameters. The configuration parameters are set by default. In this check, all requests of the same product for the same request recipient are taken into account even if the product came from different shelves.

To define differing behavior

  • In the Designer, enable the desired option for the QER | ITShop | GapBehavior | GapDefinition and QER | ITShop | GapBehavior | GapFitting configuration parameters.

Table 53: Effect of the QER | ITShop | GapBehavior | GapDefinition configuration parameter

Option

Description

0

Only pending requests are taken into account by the check. (default)

1

Only approved requests are taken into account by the check.

2

Only assigned requests are taken into account by the check.

Table 54: Effect of the QER | ITShop | GapBehavior | GapFitting configuration parameter

Option

Description

0

Validity periods can overlap. (default)

A new request is accepted if its validity period fits into at least one free time slot between two existing requests.

1

Validity periods cannot overlap.

A new request is accepted if its validity period fits exactly into a free time slot between two existing requests.

2

The validity period is not checked.

A request is accepted even if there is already a request for the same validity period.

If the configuration parameters are disabled, One Identity Manager behaves as in option 0.

Figure 10: Example of possible validity period for GapDefinition = 0 and GapFitting = 0

Figure 11: Example of possible validity period for GapDefinition = 1 and GapFitting = 1

Related topics

Relocating a customer or product to another shop

If a customer requests a product from a shop or shopping center and then changes to another at a later date, the product request is closed and the product is canceled. The same applies if a requested product is moved to another shelf.

You can label product service items with Retain service item assignment on relocation to retain their requests when they relocate. All pending or approved requests in the shop are transferred to any shop in which the identity is a customer and that contains the requested products. In connection with this, pending requests are reset, which means the requests have to go through the approval process from the beginning again.

Detailed information about this topic
Related topics

Changing approval workflows of pending requests

When approval workflows are changed, a decision must be made as to whether these changes should be applied to pending requests. Configuration parameters are used to define the desired procedure.

Scenario: Another approval workflow was stored with the approval policy

If changes have been made to the approval, renewal, or cancellation workflow in an approval policy, any pending approval processes are continued by default with the original workflow. The newly stored workflow is only used in new requests. You can configure different behavior.

To specify how to handle pending requests

  • In the Designer, enable the QER | ITShop | OnWorkflowAssign configuration parameter and select one of the following values.

    • CONTINUE: Ongoing approval processes are continued with the originally applicable workflow. The newly stored workflow is only used in new requests.

      This behavior also applies if the configuration parameter is not set.

    • RESET: In ongoing approval processes, all approval decisions already taken are reset. The approval processes are restarted with the newly stored workflow.

    • ABORT: Ongoing approval processes are stopped. All pending requests are closed. The customer must request, renew, or cancel the product again, if required.

A working copy of the originally applicable workflow is saved. The working copy is retained as long as it is used in ongoing approval processes. All unused working copies are regularly deleted using the Maintenance approval workflows schedule.

If the assigned renewal or cancellation workflow is deleted, any ongoing approval processes are stopped.

Scenario: A change was made to an approval workflow in use

If changes have been made to an approval workflow that is being used in pending requests, any pending approval processes are continued by default with the original workflow. The changes to the approval workflow are only implemented for new requests. You can configure different behavior.

To specify how to handle pending requests

  • In the Designer, enable the QER | ITShop | OnWorkflowUpdate configuration parameter and select one of the following values.

    • CONTINUE: Ongoing approval processes are continued with the originally applicable approval workflow. The changes to the approval workflow are only implemented for new requests.

      This behavior also applies if the configuration parameter is not set.

    • RESET: In ongoing approval processes, all approval decisions already taken are reset. The approval processes are restarted with the changed approval workflow.

    • ABORT: Ongoing approval processes are stopped. All pending requests are closed. The customer must request, renew, or cancel the product again, if required.

A working copy of the approval workflow that contains the original version is saved. This working copy is retained as long as it is used in ongoing approval processes. All unused working copies are regularly deleted using the Maintenance approval workflows schedule.

Related topics

Requests for employees

In the Web Portal default installation, approvers can request and cancel products for other users. Approvers can only request products for users of shops they manage and where the user is an customer. Furthermore, department managers and their deputies may edit the data for employees belonging to their department.

The responsibilities are evaluated through the following database view (View).

QER_VEditEmployee

This view displays the department manager, their deputies, and employees whose data can be edited.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating