Chat now with support
Chat with Support

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

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

Requesting change of manager for an employee

Managers can edit main data of their employees in the Web Portal. In the same context, it is possible to define a new manager for an employee. To do this, the previous manager requests assignment of another manager. If the other manager agrees to the assignment, they are assigned to the employee as manager.

Prerequisites

The following objects are made available in the One Identity Manager database by default:

Table 57: Default objects for the change of manager

Objects

Description

New manager assignment multi-request resource

Is used to request the other manager in the IT Shop. The product is canceled the moment the new manager has been assigned.

The New manager assignment service item is assigned.

New manager assignment service item

Product that is ordered when another manager is assigned.

The New manager assignment approval policy is assigned.

Identity & Access Lifecycle | Identity Lifecycle IT Shop structure

The service item is assigned by default to the Identity Lifecycle shelf in the Identity & Access Lifecycle shop.

New manager assignment approval policy

This specifies the approval workflow by which the change of manager is approved.

It is assigned to the approval workflow, New manager assignment.

New manager assignment approval workflow

This determines the other manager as an approver.

If this is denied, the request is returned to the previous manager.

VI_ESS_PersonWantsOrg_Set_New_Person.Manager process

Allocates the other manager to the employee as manager as soon as the change of manager was approved and the validity period of the request is reached.

Procedure for changing managers

  1. The previous manager edits the main data of the employee the other manager is going to take on. They select an employee as manager and specify a date from which the changes take effect.

    Table 58: Changes that are requested

    Property

    Description

    New manager

    Employee to be assigned as a new manager for the employee.

    Effective date

    The date on which the change takes effect.

    Changes to be run after approval is granted

    Changes that should be run after approval has been granted and the new manager has been assigned, for example, deleting user accounts or removing memberships in system entitlements.

    The previous manager can decide which of the changes listed should be run.

  2. A request with the following properties is triggered.

    Table 59: Properties of the manager change request

    Property

    Description

    Requester

    Previous manager.

    Recipient

    Employee.

    Additional request data

    New manager.

    Approver

    New manager.

    Valid from

    The date on which the change takes effect.

    Additional data

    Additional changes to be run.

  3. The request is assigned for approval to the new manager, who can also specify what other changes should be made after the manager has been replaced.

    1. If the manager denies approval, the request is returned to the previous manager.

      This manager can select another manager and approve the request. The request is assigned to this other manager for approval.

      The previous manager can deny request approval. The change of manager is closed. The employee’s manager is not changed.

    2. If the new manager grants approval to the request, they are assigned as manager to the employee from the validity date of the request. All selected additional changes are also run on the validity date.

  4. Product is unsubscribed. The request is closed.

For more information about assigning a new manager, see the One Identity Manager Web Designer Web Portal User Guide.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating