The IT Shop distinguishes between single or multiple requestable products. Single request products are, for example, software, system roles, or Active Directory groups. These products cannot be requested if they have already been be requested for the same time period.
Furthermore, an employee may need several of one type of company resources, for example, consumables. You can find company resources such as these mapped in One Identity Manager as Multi-request resource or Multi requestable/unsubscribable resources.
Request sequence of multi-request resources
-
A customer requests a multi-request resource in the Web Portal.
-
The request goes through the appropriate approval process and is approved.
The request is only saved in the PersonWantsOrg table. No entry is created in the PersonInITShopOrg table.
-
The resource can be canceled immediately. The request contains the Unsubscribed status (PersonWantsOrg.OrderState = 'Unsubscribed').
The resource cannot be canceled by the customer.
Request sequence of multi-requestable/unsubscribable resources
-
A customer requests a multi-requestable/unsubscribable resource in the Web Portal.
-
The request goes through the appropriate approval process and is approved.
The request is only saved in the PersonWantsOrg table. No entry is created in the PersonInITShopOrg table.
-
The request contains the Assigned status (PersonWantsOrg.OrderState = 'Assigned').
The resource can be unsubscribed by means of the Web Portal.
TIP: A customer-specific implementation of a process with the PersonWantsOrg root object for the OrderGranted result can be made in order to start a specified action when a multi-request resource is approved. For more detailed information about defining processes, see One Identity Manager Configuration Guide.
Related topics
Customers keep their requested products on the shelf until they themselves unsubscribe from them. Sometimes, however, products are only required for a certain length of time and can be canceled automatically after this time. Products that are intended to have a limited shelf life need to be labeled with the validity period. For more information, see Products for requests with time restrictions.
When a product with a limited request period is requested, One Identity Manager calculates the date and time at which the product is automatically unsubscribed (Valid until/expiry date of the request) from the current date and validity period specified in the service item. This deadline can be adjusted when the request is made.
As soon as a request is approved by all approvers, the expiration date is recalculated from the actual date and the validity period. This ensures that the validity period is valid from the day of assignment.
A Valid from date can also be entered at the time of request. This specifies the date that an assignment starts to apply. If this date is given, the expiry date is calculated from the Valid from date and the validity period. If the validity period has already expired when approval is granted, the request can no longer be approved. The request is canceled and an error message is displayed.
Cancellations can include a validity period, which means a deadline for the cancellation is set for unlimited requests. Use this method to change the expiry date for requests with a validity period. Once the cancellation has been granted approval, the cancellation's validity period is taken as the new expiry date of the request. The request cannot be extended beyond the validity period.
The request recipient receives a message before reaching the expiry date and has the possibility to extend the period. For more information, see Sequence for limited requests. The request is aborted once the expiry date has been reached.
The customer has the option to renew a request. If the customer uses this option, the extension (as in the original request) needs to approved through an approval process. If the extension is denied, the original request runs out at the given date. You can also limit renewals in the same way.
A limited request might look like the following a sequence:
| Service item |
Validity period: 90 days |
| Requested on: 1/2/2017 |
Valid until: 4/1/2017 11:59 PM |
| Approved on: 1/5/2017 |
Valid until: 4/5/2017 11:59 PM |
| Renewed until: 3/31/2017 |
Renewal valid until: 4/30/2017 12:00 PM |
| Approved on: 4/2/2017 |
Valid until: 4/30/2017 12:00 PM |
| Canceled on: 4/10/2017 |
Unsubscribed as from: 4/14/2017 11:59 PM |
| Approved on: 4/11/2017 |
Valid until: 4/11/2017 11:59 PM |
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 aborted; the resulting assignments removed.
NOTE: Ensure that times in the One Identity Manager tools, for example, the Web Portal, are in the user's local time.
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. For more information, see 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 55: 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 56: 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
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
