Explicit exception approval
If the QER | ComplianceCheck | EnableITSettingsForRule configuration parameter is set, properties can be added to compliance rules that are taken into account when rule checking requests.
Use the Explicit exception approval IT Shop property to specify whether the reoccurring rule violation should be presented for exception approval or whether an existing exception approval can be reused.
Table 48: Permitted values
|
Enabled |
A known rule violation must always be presented for exception approval, even if there is an exception approval from a previous violation of the rule. |
|
Not set |
A known rule violation is not presented again for exception approval if there is an exception approval from a previous violation of the rule. This exception approval is reused and the known rule violation is automatically granted exception. |
If several rules are violated by a request and Explicit exception approval is set for one of the rules, the request is presented for approval to all exception approvers for this rule.
Rules that have Explicit exception approval set result in a renewed exception approval if:
In case (a), the request for the IT Shop customer is presented to the exception approver. If the request is approved, case (b) applies to the next request. In case (b), every request for the IT Shop customer must be decided by the violation approver, even when the request itself does not result in a rule violation. The result you achieve is that assignments for employees who have been granted an exception, are verified and reapproved for every new request.
For more information about exception approvals, see the One Identity Manager Compliance Rules Administration Guide.
Rule checking for requests with self-service
Self-service (SB approval procedure) is always defined as a one-step procedure. That means you cannot set up more approval steps in addition to a self-service approval step.
To realize compliance checking for requests with self-service
Approving requests from an approver
By default, approvers can make approval decisions about requests in which they are themselves requester (UID_PersonInserted) or recipient (UID_PersonOrdered). To prevent this, you can specify the desired behavior in the following configuration parameter and in the approval step.
-
QER | ITShop | PersonOrderedNoDecide configuration parameter
-
QER | ITShop | PersonInsertedNoDecide configuration parameter
-
Approval by affected employee option in the approval step.
If the requester or approver is not allowed to make approval decisions, their main identity and all subidentities are removed from the group of approvers.
NOTE:
-
The configuration parameter setting also applies for fallback approvers; it does not apply to the chief approval team.
-
This configuration parameter does not affect the BS and BR approval procedures. These approval procedures also find the requester and the request recipient if the configuration parameter is not set. For more information, see Finding requesters.
Summary of configuration options
Requesters can approve their own requests if:
Recipients can approve their own requests if:
Requesters cannot approve if:
Recipients cannot approve if:
Example
A department manager places a request for an employee. Both of them are found to be approvers by the approval procedure. To prevent the department manager from approving the request, set the QER | ITShop | PersonInsertedNoDecide parameter. To prevent the employer from approving the request, set the QER | ITShop | PersonOrderedNoDecide parameter.
Approving requests from an exception approver
Similarly, you specify whether exception approvers are allowed to approve their own requests if compliance rules are violated by a request. For more information, see Restricting exception approvers.
Related topics
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
Related topics
