Canceling or unsubscribing requests
DBQueue Processor checks whether the request's expiry date has passed using a scheduled One Identity Manager task, which compares it against current UTC time. If the expiry date has passed, the request is canceled; the resulting assignments removed. You can configure this behavior.
If necessary, temporary requests can be unsubscribed. If the expiry date has passed, the unsubscription workflow stored at the decision guideline is run in this case. The unsubscription must be approved; only then will the assignment be permanently removed. If another request exists for the product, perhaps with the status Pending, the expired request will be canceled and replaced by the pending request.
To unsubscribe temporary requests on expiry
If the configuration parameter is set, requests with the status Assigned or Renewal will be unsubscribed. The unsubscription workflow entered in the approval policy runs through if no other request exists for the product, which now takes effect. Once the unsubscription is approved, the assignment will be removed. Expired requests with the status approved, pending, request are canceled.
NOTE: If the unsubscription is denied, the approver must enter a new Valid until date. Otherwise, the request is given Assigned status and the unsubscription workflow runs again.
Related topics
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
Table 54: Effect of the QER | ITShop | GapBehavior | GapDefinition configuration parameter
|
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 55: Effect of the QER | ITShop | GapBehavior | GapFitting configuration parameter
|
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
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
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
