Managing Workflows

4 Managing Workflows

Managing workflows include understanding and configuring workflow rules, managing request approval in an upgraded deployment, moving workflow policies from test to production, and running Oracle Identity Manager without workflows.

This contains the following sections:

4.1 Understanding Workflow Rules

Understand workflow rules, request process flow with or without workflows, and request lifecycle for single and bulk requests.

This sections describes about the approval workflows in the following topics:

4.1.1 About Workflow Rules

Request generation and approval depends on the usage and configuration of workflow rules.

Request generation and approval is governed by the following:

Whether Oracle Identity Manager is running with or without workflows. By default, workflows are enabled in Oracle Identity Manager. For information about running Oracle Identity Manager without workflows, see "Running Oracle Identity Governance Without Workflows".
Approval workflow rules defined for the supported operations.

Note:

Approval policies have been deprecated in favour of workflow policies. Request generation and approval is governed by workflow policies, as described in this document.

If you have upgraded Oracle Identity Manager from an earlier release, then approval policies continue to work, as described in Managing Approval Policies in the Administrator’s Guide for Oracle Identity Manager for 11g Release 2 (11.1.2.2).

However, Oracle recommends that you migrate all existing approval policies to workflow policies.

Workflow rules determine the following:

Whether or not approvals are required for an operation
Which workflow must be invoked for a specific operation

4.1.2 About Request Process Flow

The process flow of a request depends on whether or not the operation is allowed, single or bulk operation, and the deployment is with or without workflows.

The process of request generation and approval, which is governed by approval workflow rules, is depicted in Figure 4-1.

Figure 4-1 Request Process Flow

Description of "Figure 4-1 Request Process Flow"

The request process flow is as follows:

Authorization checks are performed based on the admin roles granted to the user. This check determines whether or not the user is allowed to perform the operation.
If the operation is not authorized, then an error is returned and the flow ends.
If the operation is allowed, then it is checked if the operation is a bulk operation or future-dated operation.
If it is a bulk or future-dated operation, then a request is created, approval is initiated based on workflow rule evaluation, and the operation is completed after approval.
If it is not a bulk or future-dated operation, then approval workflow rules are evaluated. The result of this evaluation determines whether request is created or not.
- If the result is Direct, then no request is created, and the operation is performed directly.
- If a SOA Workflow ID is returned as the result, then a request is created, and the workflow returned by the policy evaluation is invoked.

Bulk requests are processed in the following way:

An allowed bulk operation always results in a request being created.
Approval workflow rules configured for the bulk operation are evaluated.

If rule evaluation results in a workflow ID, then bulk request is created and corresponding SOA workflow is initiated.

If rule evaluation results in no workflow ID, then bulk request is created and it is auto-approved.
After the bulk request is approved (auto-approved or SOA workflow approval), child requests are created.
Child requests go through approval workflow rule evaluation (non-bulk), and are processed based on the outcome.

4.1.3 About Request Lifecycle

Each request goes through a specific lifecycle after it is created in the system. The lifecycle transits the request through various stages. The stage a request is in determines what action the controller takes in that step, what operations are available on the request at that time, and what the possible stage transitions are.

Request lifecycle is described in the following sections:

4.1.3.1 Various Request Stages

Table 4-1 describes how a request functions at various stages through its life cycle and how a request attains these stages.

Table 4-1 Request Stages

Request Stage	Description
Request Draft Created	After saving the request as a draft by clicking the Save as Draft button on the Cart Details page, the request moves to the Request Draft Created stage. A requester can save a request for modifying, submitting, or deleting it later. This is useful if the requester is awaiting additional information before submitting the request. The draft request cannot be withdrawn or closed. Note: The request data saved in draft mode does not include sensitive information such as passwords, even if they were entered before saving the request as draft.
Request Created	After successful submission of the request, the request moves to the Request Created stage.
Provide Information	This is a task assigned to requester (accessible from Inbox) for the entitlement request to search for and select the account for which the entitlement needs to be provisioned.
Request Awaiting Approval	After the request is created, the request moves to the `Request Awaiting Approval` stage automatically if there are approvals defined for this request. At this stage, the corresponding approvals are initiated through the request service. If a request is withdrawn or closed at this stage, then the request engine calls cancel workflow on each workflow instance. Notifications are sent to approvers about the withdrawn tasks. After the request successfully completes these statuses, it will attain the Request Approved stage. If an SoD validation check is plugged-in after the request has been successfully created, the request is associated with the following statuses. SoD check not initiated A request attains this stage, if the SoD validation is not initiated for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval. SoD check initiated A request attains this stage, if the SoD validation is initiated asynchronously for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval. SoD check completed A request attains this stage, if the SoD validation is completed for provisioning resource based request. The request engine moves the request to this stage after submission of request and before Obtaining Approval. Note: These SoD request statuses are possible if the request is any of the following request types: Provision Application Instance Modify Account Provision Entitlement Revoke Entitlement Assign Roles Remove from Roles
Request Approved	Only after a request is approved, it moves to the next stage and is updated with the current status. The outcome is Approved, Rejected, or Pending.
Request Auto Approved	Only after a request is approved, it moves to the next stage and is updated with the current status.
Request Rejected	Each time a workflow instance is updated, request service updates the request engine with the current status of that instance. The outcome that the request engine expects from request service is Approved or Rejected. If any of the workflow instances that are instantiated are rejected, then request engine moves the request to Rejected stage. If any workflow instance is rejected, then the controller calls cancel on all the pending workflows and moves the request to Rejected stage.
Operation Initiated	After the request is approved, the request engine moves the request to the Operation Initiated stage and initiates the operation. The following request statuses are associated with this stage: Operation Completed After completing the actual requested operation, the request engine moves the request to the Operation Completed stage. This happens after Operation Initiated status and is associated with Completed stage. Post Operation Processing Initiated After the actual requested operation is completed, if there exists any additional operation that needs to be executed as post-processing, the request engine moves the request to the Post Operation Processing Initiated stage, before initiating those operations. This happens after Operation Completed status. Note: In case of a bulk operation, child requests are created after request level approval, and the parent request moves to the "Request Awaiting Child Requests Completion" status.
Request Failed	When the associated operations specified in the request fails to execute, the request cancels any pending operations and moves the request to the Request Failed stage. The following request statuses are associated with this stage: Request Failed When all associated operations specified in a request fail, the request is moved to the Request Failed stage. Request Partially Failed When any associated operation specified in a request fails, the request is moved to the Request Partially Failed stage.
Request Withdrawn	A request can be withdrawn by the requester. At this stage, the request is associated to the Request Withdrawn status, and the initiation of all approvals are canceled. Note: A request can be withdrawn before Operation Initiated stage. After the request attains the Operation Initiated stage, the request cannot be withdrawn. A request saved in draft mode cannot be withdrawn. A request can always be withdrawn by a requester only, which is done by using Identity Self Service. An administrator can close requests, which is similar to the withdraw function.
Request Closed	A request can be closed by the requester. At this stage, the request is associated to the Request Closed status, and the initiation of all approvals are canceled. Note: A request saved in draft mode cannot be closed. An administrator can close requests, which is similar to the withdraw function.
Request Completed	After the execution of all operations specified in the request are completed, the request engine moves the request to the Request Completed stage. The following request statuses are associated with this stage: Request Completed with Errors A request attains this status, when an actual requested operation executes fine, but fails to execute any of the post-processing operations. The Request Completed with Errors stage is associated with the Failed stage. Request Completed A request attains this status, when an actual requested operation executes fine without any errors. Request Awaiting Completion When a request is scheduled to be executed on a future date, the request attains Request Awaiting Completion status till the operation is completed on an effective date.

The successful attainment of a stage also results in the status of the request being updated to the corresponding status.

Operations can be executed manually or automatically by the system in response to an event. Examples of manual operations are:

Save request as draft
Edit/update draft request
Submit request
Close/cancel (withdraw) request
Approve request when the service is notified that the approval workflow is successfully approved

Examples of automatic operations are:

Start approvals when the request is submitted
Execute request when the request is approved and execution date is in the future or not specified

4.1.3.2 Single Request Lifecycle

Any single or non-bulk request goes through a single level of approval. When the approval workflow is invoked, the request moves to the Request Awaiting Approval stage, and it moves to the Request Approved stage after approval, as shown in Figure 4-2.

Figure 4-2 Single Request Lifecycle

Description of "Figure 4-2 Single Request Lifecycle"

4.1.3.3 Bulk Request Lifecycle

The lifecycle of a bulk or parent request is similar to a single or non-bulk request, until the bulk request goes to the Request Approved stage. After that, it is split into child requests, and then it moves to the Request Awaiting Child Requests Completion status of the Operation initiated stage, as shown in Figure 4-3.

Figure 4-3 Bulk Request Lifecycle

Description of "Figure 4-3 Bulk Request Lifecycle"

Each child request goes through the lifecycle described in "Single Request Lifecycle". After the child requests are completed, the bulk or parent request moves to the Request Completed stage.

4.2 Configuring Approval Workflow Rules

Configuring approval workflow rules involve understanding workflow rules, rule conditions, and system-defined operations and rules; and creating approval workflow rules, configuring custom rule conditions, modifying approval workflow rules, deleting approval workflow rules, and understanding approval workflow rule evaluation.

This sections describes about configuring approval workflow rules in the following topics:

4.2.1 About Approval Workflow Rules

Approval workflow rules can be configured to determine whether an operation requires approval or not. In addition, if approval is required, then the rule also indicates which SOA workflow is to be initiated.

A list of operations and corresponding workflow rules are predefined in Oracle Identity Manager. These system-defined rules determine whether or not approvals are required and the SOA workflow to be initiated. All the non-bulk operations have pre-defined approval workflow rules configured.

For a list of supported operations and corresponding rules, see "About System-Defined Operations and Rules".

Note:

Oracle Identity Manager does not allow you to create new operations and corresponding rules. However, you can create and modify rules for the existing operations.

Approval workflow rules can be configured for all the supported operations, which are:

Self-Register User
Create User
Modify User
Disable User
Enable User
Delete User
Create Role
Modify Role
Delete Role
Assign Roles
Remove from Roles
Modify Role Grant
Provision Application Instance
Modify Account
Disable Account
Enable Account
Revoke Account
Provision Entitlement
Modify Entitlement
Revoke Entitlement
Heterogeneous Request
Bulk Modify User Profile
Bulk Disable User
Bulk Enable User
Bulk Delete User
Bulk Delete Role
Bulk Assign Roles
Bulk Remove from Roles
Bulk Provision Application Instance
Bulk Disable Account
Bulk Enable Account
Bulk Revoke Account
Bulk Provision Entitlement
Bulk Revoke Entitlement

4.2.2 About Rule Conditions

An approval workflow rule consists of rule condition and outcome.

An approval workflow rule consists of:

Condition: Rule condition based on the allowed inputs defined at the operation level
Outcome: Workflow ID, which is the SOA workflow ID to be initiated for the operation

The following is an example of an approval workflow rule for the Modify User operation:

Rule condition:

requester.adminroles CONTAINS OrclOIMUserAdmin

Rule Outcome:

Direct

Here, the rule condition checks if the requester is a member of the User Administrator admin role in the beneficiary's organization. If the condition is satisfied, then operation is performed without initiating any approval workflow.

The rule conditions vary from operation to operation. For example, user data is required along with requester data for a Create User operation, and role information and user data is required along with requester date for an Assign Role operation. Requester data is required for all operations. Oracle Identity System Administration enables you to enter the required role conditions based on the operation that you select.

Each approval workflow can have multiple rules associated with it, which must be defined in a certain order. For example, the Create User approval workflow can have rules, such as Create Contractor, Create Supplier, and Create Partner, defined in a sequence. The order in which the rules in an approval workflow are evaluated depends on the order or sequence in which the rules are defined in the policy.

See "About Custom Rule Conditions" for examples of rule conditions for each operation.

4.2.3 About System-Defined Operations and Rules

Each operation/workflow policy has a default rule, whose outcome is DIRECT. This means that if the default rule condition evaluates to true for an operation, then it is a direct operation without approvals.

Table 4-2 lists the system-defined operations and corresponding workflow rules, for which the outcome is DIRECT.

Note:

The rules in Table 4-2 are only for backward compatibility. You must remove these and create your own rules.

Table 4-2 Operations and Rules

Operation	Rule Name	Rule condition
Assign Roles	Assign Roles Default Rule	requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Create Role	Create Role Default Rule	requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Create User	Create User Default Rule	requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Delete Role	Delete Role Default Rule	requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Delete User	Delete User Default Rule	requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Disable Account	Disable Account Default Rule	requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Disable User	Disable User Default Rule	requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Enable Account	Enable Account Default Rule	requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Enable User	Enable User Default Rule	requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Modify Account	Modify Account Default Rule	requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Modify Entitlement	Modify Entitlement Default Rule	requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Modify Role	Modify Role Default Rule	requester.adminroles CONTAINS OrclOIMRoleAdministrator OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Modify User Profile	Modify User Profile Default Rule	requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Provision Application Instance	Provision ApplicationInstance Default Rule	requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Provision Entitlement	Provision Entitlement Default Rule	requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Remove from Roles	Remove from Roles Default Rule	requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Revoke Account	Revoke Account Default Rule	requester.adminroles CONTAINS OrclOIMApplicationInstanceAuthorizerRole OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Revoke Entitlement	Revoke Entitlement Default Rule	requester.adminroles CONTAINS OrclOIMEntitlementAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator
Modify Role Grant	Modify Role Grant Default Rule	requester.adminroles CONTAINS OrclOIMRoleAuthorizer OR requester.adminroles CONTAINS OrclOIMUserAdmin OR requester.adminroles CONTAINS OrclOIMSystemAdministrator

In addition, there are a few other system-defined rules that support compliance use cases, which include role lifecycle, identity auditor, and certification, as listed in Table 4-3.

Table 4-3 Rules for Compliance Use Cases

Operation	Rule Name	Rule Condition	Rule Outcome
Assign Roles	Assign Roles IdentityAuditorEnabled Rule	identityAuditEnabled EQUAL TRUE	Workflow default/DefaultOperationalApproval!5.0
Create Role	Create Role IdentityAuditorEnabled Rule	identityAuditEnabled Equal TRUE	Workflow default/RoleLCMApproval!1.0
Delete Role	Delete Role IdentityAuditorEnabled Rule	identityAuditEnabled Equal TRUE	Workflow default/RoleLCMApproval!1.0
Disable User	Disable User Certification Rule	request.isCertification Equal true	Workflow default/DefaultRequestApproval!5.0
Modify Role	Modify Role IdentityAuditorEnabled Rule	identityAuditEnabled Equal TRUE	Workflow default/RoleLCMApproval!1.0
Remove from Roles	Remove from Roles IdentityAuditorEnabled Rule	identityAuditEnabled Equal TRUE	Workflow default/DefaultOperationalApproval!5.0
Remove from Roles	Remove from Roles Certification Rule	request.isCertification Equal TRUE	Workflow default/DefaultRequestApproval!5.0
Revoke Account	Revoke Account Certification Rule	request.isCertification Equal TRUE	Workflow default/DefaultRequestApproval!5.0
Revoke Entitlement	Revoke Entitlement Certification Rule	request.isCertification Equal TRUE	Workflow default/DefaultRequestApproval!5.0
Modify Role Grant	Modify Role Grant IdentityAuditorEnabled Rule	identityAuditEnabled EQUAL TRUE	Workflow default/DefaultOperationalApproval!5.0

4.2.4 Creating Approval Workflow Rules

Approval workflow rules are configured to determine whether an operation requires approval or not. In addition, if approval is required, then the rule also indicates which SOA workflow is to be initiated.

To create an approval workflow rule:

Login to Oracle Identity System Administration.
On the left navigation pane, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.
In the Select an Operation to configure rules section, select an operation to configure rules for the operation. The rules associated with the operation are displayed in the Rules section at the bottom of the page. This section displays the rule name, rule description, and the workflow associated with the operation.

In the Rules section, you can create a new rule, or select an existing rule and update or delete it.

Note:

When multiple rule conditions are specified in an approval workflow policy, the order in which rules are evaluated is based on the order in which they are configured in the policy. The order cannot be changed after the rules have been created. Therefore, the rules must be created in the order in which you want them to be evaluated.
In the Rules section, click Create. The Create Rule page is displayed.
In the Name box, enter a name for of the rule. This is a mandatory field.
In the Description box, enter a description for the rule.
In the Owner box, specify a owner of the rule. To do so, click the search icon adjacent to the Owner field, and then search and select a owner.
From the Status list, select a status for the rule. By default, the rule is in Enabled status.
In the Condition Builder section, specify the rule conditions in the IF and THEN clauses. To do so, perform the following steps to create a sample rule condition in which if the user is a member of the Top organization, then the Create User operation will be auto-approved:
1. Under the IF clause, in the first field of the empty row, to specify an object and attribute, click the search icon adjacent to the field. The Condition Builder dialog box is displayed.
  
  Note:
  
  If you are aware of the exact object and attribute name, then you can enter the condition in the first field, for example requester.Organization Name, instead of clicking the search icon.
2. Click requester because you want to specify the condition based on requester data. A list of attributes is displayed that you can specify for the requester object. You can navigate through the attributes by clicking the page number icons and select it. Otherwise, enter the attribute name in the search field and click the search icon.
  
  Note:
  
  From any screen of the Condition Builder dialog box, you can click Start to come back to the first screen in which you can start specifying a fresh condition by selecting the object.
3. Click the Organization Name attribute. The condition requester.Organization Name is displayed in the Condition Builder dialog box.
4. Click OK. The condition is added to the first field in the IF clause.
5. From the Operator list, select Equal.
  
  The following operators are available for selection:
  - EQUAL
  - NOT_EQUAL
  - CONTAINS
  - DOES_NOT_CONTAIN
  - BEGINS_WITH
  - DOES_NOT_BEGIN_WITH
  - ENDS_WITH
  - DOES_NOT_END_WITH
6. To specify the value in the field on the right side, click the search icon. The Condition Builder dialog box is displayed.
  
  Note:
  
  If you are aware of the exact value, then you can enter the value, for example Top, instead of clicking the search icon.
7. Select any one of the following options:
  - Value: To specify the value of an attribute.
  - Expression: To specify the condition based on an expression.
  For the purpose of this example, select the Value option. The values for the Organization Name attribute are listed. This is because the object and attribute specified in the rule is requester.Organization Name.
8. Click Top. The Top organization is selected.
9. Click OK. The Top organization is populated in the value field.
10. To add another condition, click Add Condition. Another row is added under the IF clause. From the operator list on the right, you can select the AND or OR operator, and enter another rule condition as described in steps a through i.
  
  To remove a row, you can select the check box to the left of the row, and click Remove.
11. If you have added multiple rule conditions, then you can group the conditions together. To do so, select the check boxes to the left of the conditions, and click Group. Similarly, to remove the grouping of the conditions, select the check boxes to the left of the conditions, and click Ungroup.
  Note:
  - You can group only two conditions at a time. If you select more than two conditions, then the Group button is disabled. Alternatively, the Ungroup button is enabled only when you select one of the conditions that is grouped, but it is disabled when you select more than one group.
  - A maximum of two conditions can be grouped together. Therefore, if you create a rule with four conditions that are grouped together with the AND operator, then the conditions are grouped into two sets. But if one of the conditions are grouped with the OR operator, then rule is updated correctly.
12. In the THEN clause, click the search icon adjacent to the first field to open the Condition Builder dialog box.
13. Select workflow and click OK.
14. In the value field for workflow, select AutoApproval!1.0. The request will be auto-approved if you select this workflow.
15. Click OK. The workflow value is populated in the value field.
  
  Therefore, the rule condition you specified is the following:
```
IF
requester.Organization Name EQUALS Top

THEN
workflow default/AutoApproval!1.0
```
Click Create to create the rule condition. The rule condition is displayed in the table when you select the Operation for which it is created.
Note:
- When Risk attributes are used to define the conditions in a rule, for the rule to be evaluated correctly, the Risk Aggregation Job scheduled job must be run before the request is made.
- For application instances, there is no mechanism to filter out the attributes. All the attributes for application instances are displayed in the Condition Builder with which a rule can be written. For roles, select the role name to display the list of attributes for the role entities. You can select the asterisk (*) wildcard character to display the list of attributes.

See "About Custom Rule Conditions" for examples of rule conditions for each workflow operation.

Note:

In this release, while creating a workflow rule, use User Type instead of Role. For example, in the following rule condition, user.User Type is used instead of user.Role:

IF user.User Type=Contractor
THEN capability=selfModifyUser

4.2.5 About Custom Rule Conditions

Custom rule conditions have a syntax that consist of operation and the corresponding top-level attribute for the condition.

Table 4-4 describes how to specify custom rule conditions with examples.

Table 4-4 Approval Workflow Rule Syntax and Examples

Operation	Top-Level Attribute for Condition	Creating Workflow Rule Conditions (based on top-level attribute)
All operations including bulk	operation	This refers to the operation being performed currently, for example: operation EQUALS Create User Note: Such a condition can be used where the desired outcome is always `true`.
All operations including bulk and excluding self-register user	requester	This refers to the user profile attributes, roles, and admin role memberships of all the requesters. For example: requester.Email CONTAINS @example.com requester.adminRoles CONTAINS OrclOIMUserAdmin This condition means if requester's email ID contains example.com, and requester is a member of OrclOIMUserAdmin admin role.
Create User	user	This refers to all the user entity attributes, which can be specified by the requester while creating a user. For example: user.Last Name EQUALS Doe
Modify User	user	This refers to all the user entity attributes of the user being modified, which can be specified by the requester while modifying a user. For example: user.Organization EQUALS Marketing
Disable User, Enable User, Delete User	user	This refers to all the user attributes of the user being disabled, enabled, or deleted, which are currently set in the user's profile. For example: existingUser.Organization EQUALS Marketing
Disable User, Enable User, Delete User	request	This refers to the request metadata, and the only allowed subattribute is `isCertification`. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example: request.isCertification EQUAL true Note: `request.isCertification` is used within default rules. It is not recommended to create custom conditions using `request.isCertification`.
Create Role	role	This refers to all the role entity attributes, which can be specified while creating a role. For example: role.Name EQUALS ITAdmin Because catalog metadata attributes can also be specified while creating the role, conditions are allowed based on catalog metadata attributes as well. For example: role.catalog.Category EQUAL Role
Create Role	identityAuditEnabled	This can be used to create condition based on the value of the `OIG.IsIdentityAuditorEnabled` system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example: identityAuditEnabled EQUALS TRUE Note: `identityAuditEnabled` is used within default rules. It is not recommended to create custom conditions using `identityAuditEnabled`.
Modify Role	role	This refers to all the role entity attributes, which can be specified while modifying a role. For example: role.Name EQUAL ITAdmin Because catalog metadata attributes can also be specified while modifying the role, conditions are allowed based on catalog metadata attributes as well. For example: role.catalog.Category EQUAL Role
Modify Role	existingRole	This refers to all the role entity attributes, which are currently set for the role being modified. For example: existingRole.DisplayName EQUALS IT Administrator Because catalog metadata attributes can also be specified while modifying the role, conditions are allowed based on catalog metadata attributes as well. For example: role.catalog.Category EQUAL Role
Modify Role	identityAuditEnabled	This can be used to create condition based on the value of the `OIG.IsIdentityAuditorEnabled` system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example: identityAuditEnabled EQUALS TRUE Note: `identityAuditEnabled` is used within default rules. It is not recommended to create custom conditions using `identityAuditEnabled`.
Delete Role	existingRole	This refers to all role entity attributes, which are currently set for the role being deleted. For example: existingRole.DisplayName EQUALS IT Administrator
Delete Role	identityAuditEnabled	This can be used to create condition based on the value of the `OIG.IsIdentityAuditorEnabled` system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example: identityAuditEnabled EQUALS TRUE Note: `identityAuditEnabled` is used within default rules. It is not recommended to create custom conditions using `identityAuditEnabled`.
Assign Roles, Remove from Roles	user	This refers to all user attributes, which are currently set in the profile for the user/beneficiary who is being assigned a role or whose role membership is being revoked. For example: user.Organization EQUALS Marketing
Assign Roles, Remove from Roles	role	This refers to all attributes of the role, which is being assigned ro or revoked from a user. For example: role.name EQUAL IT Administrator
Assign Roles, Remove from Roles	catalogItem	This refers to catalog metadata attributes corresponding to the role for which the access request is being submitted. For example: catalogItem.Category EQUAL Role
Assign Roles, Remove from Roles	identityAuditEnabled	This can be used to create condition based on the value of the `OIG.IsIdentityAuditorEnabled` system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example: identityAuditEnabled EQUALS TRUE Note: `identityAuditEnabled` is used within default rules. It is not recommended to create custom conditions using `identityAuditEnabled`.
Assign Roles, Remove from Roles	request	This refers to the request metadata, and the only allowed sub-attribute is `isCertification`. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example: request.isCertification EQUAL true Note: `request.isCertification` is used within default rules. It is not recommended to create custom conditions using `request.isCertification`.
Modify Role Grant	user	This refers to user attributes, which are currently set in the profile for the user/beneficiary whose role membership is being modified. For example: user.Organization EQUALS Marketing
Modify Role Grant	role	This refers to attributes of the role whose membership is being modified. For example: role.name EQUALS IT Administrator
Modify Role Grant	catalogItem	This refers to catalog metadata attributes corresponding to the role for which the access request is being submitted. For example: catalogItem.Category EQUAL Role
Modify Role Grant	identityAuditEnabled	This can be used to create condition based on the value of the `OIG.IsIdentityAuditorEnabled` system property. The only allowed values are TRUE and FALSE, which must be entered manually. For example: identityAuditEnabled EQUALS TRUE Note: `identityAuditEnabled` is used within default rules. It is not recommended to create custom conditions using `identityAuditEnabled`.
Provision ApplicationInstance	user	This refers to the user profile attributes of the user/beneficiary to whom the account is being provisioned. For example: user.Organization EQUALS Marketing
Provision ApplicationInstance	appType	This refers to the account which is being provisioned to a user/beneficiary. `appType` is a top-level attribute that can lead to a hierarchy of sub-attributes, such as `appInstance`, followed by `account`, and optionally followed by account-specific child tables or entitlements. Further, `account` can be followed by the parent form attributes, and child table or entitlement can be followed by their specific attributes. Example 1: appType[AD User].appInstance[VisionEmployeesDomain].account[].Organization Name EQUAL Marketing This condition means that if an account is being created in the `VisionEmployeesDomain` appInstance within the `Marketing` organization. Note: Workflow rule evaluation only considers the account that is being requested and does not consider any of the existing accounts that the user/beneficiary might have. Example 2: appType[AD User].appInstance[].account[*].Organization Name EQUAL Marketing This condition means that if an account is being created in any appInstance pertaining to the AD User target within the `Marketing` organization.
Provision ApplicationInstance	catalogItem	This refers to catalog metadata attributes set in the catalog item for which the access request is being submitted, for example `catalogItem`.
Modify Account	user	This refers to user profile attributes of the user/beneficiary whose account is being modified. For example: user.Organization EQUALS Marketing
Modify Account	appType	This refers to the account information that is being modified as part of this operation. For example: existingAppType[AD User].appInstance[].account[].Organization Name EQUAL Manufacturing This condition means that if the user account on any of the AD User targets is being transferred to the Manufacturing organization.
Modify Account	existingAppType	This refers to current or existing user account information, which is being modified as part of this operation. For example: appType[AD User].appInstance[].account[].Organization Name EQUAL Marketing This condition means that if the user account on any of the AD User targets is being transferred from the Marketing organization to some other organization. Note: Workflow rule evaluation only considers the account that is being modified and does not consider any of the existing accounts that the user/beneficiary might have.
Modify Account	catalogItem	This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted. For example: catalogItem.Category EQUALS Role
Enable Account, Disable Account, Revoke Account	user	This refers to the user profile attributes of the user/beneficiary whose account is being enabled/disabled/revoked. For example: user.Organization EQUALS Marketing
Enable Account, Disable Account, Revoke Account	existingAppType	This refers to current or existing user account information, which is being disabled/enabled/revoked as part of this operation. For example: existingAppType[AD User].appInstance[].account[].Organization Name EQUAL Marketing This condition means that if the user account being disabled/enabled/revoked belongs to the Marketing Organization of any of the AD User targets. Note: Workflow rule evaluation only considers the account which is being disabled/enabled/revoked and does not consider any of the existing accounts that the user/beneficiary might have.
Enable Account, Disable Account, Revoke Account	catalogItem	This refers to catalog metadata attributes set in the catalog item for which the access request is being submitted, for example `catalogItem`.
Enable Account, Disable Account, Revoke Account	request	This refers to the request metadata, and the only allowed sub-attribute is `isCertification`. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example: request.isCertification EQUAL true Note: `request.isCertification` is used within default rules. It is not recommended to create custom conditions using `request.isCertification`.
Provision Entitlement	user	This refers to user profile attributes of the user/beneficiary to whom the entitlement is being provisioned. For example: user.Organization EQUALS Marketing
Provision Entitlement	appType	This refers to the entitlement information or the data that is being specified while performing the operation. For example: appType[AD User].appInstance[VisionEmployeesDomain].account [].UD_ADUSRC[].Group Name EQUAL PasswordPolicyAdminGrp This condition means that if the `PasswordPolicyAdminGrp` entitlement is being granted to the user/beneficiary on `VisionEmployeesDomain` application instance.
Provision Entitlement	catalogItem	This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted, for example, `catalogItem`.
Modify Entitlement	user	This refers to the user profile attributes of the user/beneficiary whose entitlement grant is being modified. For example: user.Organization EQUALS Marketing
Modify Entitlement	appType	This refers to the entitlement information or the data that is being specified while performing the operation. For example: appType[AD User].appInstance[VisionEmployeesDomain].account [].UD_ADUSRC[].Group Name EQUAL PasswordPolicyAdminGrp This condition means that if `PasswordPolicyAdminGrp` entitlement grant is being modified for the user/beneficiary on `VisionEmployeesDomain` application instance.
Modify Entitlement	existingAppType	This refers to the entitlement information or the existing entitlement form data, such as start date and end date. For example: existingAppType[AD User].appInstance[VisionEmployeesDomain].account [].UD_ADUSRC[].Group Name EQUAL PasswordPolicyAdminGrp This condition means that if `PasswordPolicyAdminGrp` entitlement grant is being modified for the user/beneficiary on VisionEmployeesDomain application instance.
Modify Entitlement	catalogItem	This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted, for example `catalogItem`.
Revoke Entitlement	user	User profile attributes of the user/beneficiary whose entitlement grant is being revoked. For example: user.Organization EQUALS Marketing
Revoke Entitlement	existingAppType	This refers to the entitlement information or the existing entitlement form data, such as start date and end date. For example: existingAppType[AD User].appInstance[VisionEmployeesDomain].account [].UD_ADUSRC[].Group Name EQUAL PasswordPolicyAdminGrp This condition means that if `PasswordPolicyAdminGrp` entitlement grant is being modified for the user/beneficiary on `VisionEmployeesDomain` application instance.
Revoke Entitlement	catalogItem	This refers to the catalog metadata attributes set in the catalog item for which the access request is being submitted, for example `catalogItem`.
Revoke Entitlement	request	This refers to the request metadata, and the only allowed sub-attribute is `isCertification`. The only allowed values are true and false, which must be entered manually. This can be used to check if the current operation/request is a certification request. For example: request.isCertification EQUAL true Note: `request.isCertification` is used within default rules.It is not recommended to create custom conditions using `request.isCertification`.

4.2.6 Modifying Approval Workflow Rules

You can modify workflow rules to add, modify, or remove the rule conditions.

To modify the workflow rule that you added in "Creating Approval Workflow Rules":

On the left navigation pane of Identity System Administration, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.
In the Operation section, select an operation to configure rules for the operation.
In the Rules section, click Edit. The Edit Rule page is displayed.
In the Operation section, search and select the operation for which you want to modify the workflow rule. For the purpose of this example, select Create User. The rules for the Create User operation is displayed in a table in the Rules section.
In the Rules section, select the rule that you want to edit, and click Edit. The Edit Rule page is displayed.
If you want to modify any rule attribute, then update the attribute values in the Edit Rule section.
In the Condition Builder section, you can modify an existing rule by modifying the object, attribute, or value fields. You can also add conditions to the existing ones, or remove rule conditions. Perform the following steps to add a rule condition that specifies that if the requester has the UserHelpDesk admin role, then the target user manager's approval is required for the Create User Operation:
1. In the Condition Builder section, click Add Condition. A new row is added.
2. From the operators list on the right, select OR.
3. In the first field of the row, specify requester.adminRole by using the Condition Builder dialog box. See step 10 of "Creating Approval Workflow Rules" for information about selecting values in the Condition Builder dialog box.
4. From the operators list, select CONTAINS.
5. In the value field, select OrclOIMUserHelpDesk by using the Condition Builder dialog box.
6. In the THEN section, specify workflow and default/BeneficiaryManagerApproval!3.0 in the two fields respectively. Therefore, the complete rule condition is:
```
IF
requester.adminRoles CONTAINS OrclOIMUserHelpDesk

THEN
workflow default/BeneficiaryManagerApproval!3.0
```
  This rule condition will ensure that if the requester has the UserHelpDesk admin role, then the target user manager's approval is required for creating the user.
Click Update. The workflow rule is updated with the new rule condition.
To remove a rule condition, select the check box to the left of the rule condition row, and click Remove. Then, click Update.

4.2.7 Deleting Approval Workflow Rules

You can delete the workflow rules that you define for all the operations. However, it is recommended that the default rules are not deleted.

To delete a workflow rule:

On the left navigation pane of Identity System Administration, under Workflows, click Approval. The Approval Workflow Configuration page is displayed.
In the Operation section, select an operation whose workflow rule you want to delete.
In the Rules section, click Delete. A message box is displayed asking for confirmation.
Click Yes.

4.2.8 About Approval Workflow Rule Evaluation

Understand the approval workflow rule evaluation for bulk and non-bulk operations.

When an operation (bulk or non-bulk) is being performed, approval workflow rule evaluation takes place in the following way:

The approval workflow rules associated with the operation being performed are evaluated one by one, in the order in which they are configured.
Rule evaluation stops, and the outcome, which is workflowID or Direct, of the matched rule is returned.

Approval workflow rule evaluation stops at the first matching rule, which is the rule that evaluates to true, and that rule's outcome is returned as the result.
For a Bulk operation, if none of the rules match, then the SOA composite configured in defaultRequestApprovalComposite of SOAConfig is returned implicitly.
For a non-bulk operation, if none of the rules match, then the SOA composite configured in defaultOperationApprovalComposite of SOAConfig is returned implicitly.

If the approval workflow rule evaluation returns a WorkflowID, for example UserManagerApproval, then a request is created and the corresponding ASYNC orchestration is initiated. As part of the orchestration, there is a possibility that some of the data submitted by the user is modified or added. As a result, a different workflow ID than UserManagerApproval might be applicable. To handle such scenarios, approval workflow rules are re-evaluated before the workflow is initiated. If the re-evaluation results in a different workflowID, for example HRManagerApproval, then HRManagerApproval is initiated.

4.3 Managing Request Approval in an Upgraded Deployment of Oracle Identity Governance

Managing request approvals in an upgraded deployment involves understanding request approval process in an upgraded deployment, request process flow with disabled workflow rules, migrating approval policies, and enabling workflow rules.

This section describes about managing request approvals in an upgraded deployment of Oracle Identity Governance in the following topics:

4.3.1 About Request Approval in an Upgraded Deployment of Oracle Identity Governance

In an upgraded deployment of Oracle Identity Manager, the approval workflow rules feature is disabled by default.

As a result, the following occurs when an operation is initiated:

Authorization policies and admin role assignments determines whether or not an operation requires approval, as described in Request vs. Direct Operation in the User’s Guide for Oracle Identity Manager.
Approval policies are functional and determines which SOA workflow is to be invoked if approval is required.
There are two levels of approval, and the functionality is as described in Managing Requests of User's Guide for Oracle Identity Manager for 11g Release 2 (11.1.2.2).
If you enable workflow policies, then request generation and approval takes place in the same manner as in a fresh deployment of Oracle Identity Manager. However, you must migrate approval policies to workflow policies, as described in "Migrating Approval Policies to Approval Workflow Rules".

Note:

After enabling workflow policies, you must not disable it again. Toggling between enabling and disabling workflows is not supported.

Most of the approval policy features can be achieved by using approval workflows. Table 4-5 lists the approval policy features that can be achieved by using approval workflows.

Table 4-5 Approval Policies to Approval Workflows

Approval policies	Approval workflow rules
Approval policies for a request type	Approval workflow rule specific to an operation
Approval policy level, which consists of request level and operation level	Single level of approval
Scope type, scope	Approval workflow rule condition
Approval process configuration: auto approval	Approval workflow rule configuration: Select Direct
Approval process configuration: approval process	Workflow rule configuration: Search and select workflow
Approval policy rule	Approval workflow rule condition
Heterogeneous request type	Heterogeneous request policy
Bulk request type	Bulk policy for operation, for example Create User Bulk
Request level approval policies	Approval workflow rules
Operation level approval policy	NA
Priority	Policy order, in which the policies are configured
Hierarchical organization scoping	Policy condition based on organization hierarchy, for example: user.Organization="VisionMarketing" OR user.parentOrganization="Vision" OR ...

4.3.2 About Request Process Flow With Approval Workflow Rules Disabled

In an upgraded deployment of Oracle Identity Manager, approval workflows is disabled by default.

Figure 4-4 shows the request process flow when approval workflows is disabled.

Figure 4-4 Request Process Flow with DIsabled Workflow

Description of "Figure 4-4 Request Process Flow with DIsabled Workflow"

When approval workflow rules feature is disabled, the ApprovalRequired obligation(s) returned as a result of authorization policy evaluation determine whether the operation requires approval(s) or not.

If ApprovalRequired is false, then no request is created, and it is a direct operation.

If ApprovalRequired is true, then a request is created, approval policies are evaluated, and the SOA workflow returned by approval policy evaluation is initiated.

4.3.3 Migrating Approval Policies to Approval Workflow Rules

By default, a single workflow policy is available for an operation, whereas, an operation or request type can have multiple approval policies configured at request level and operation level.

To migrate approval policies to approval workflow rules:

Identify all the approval policies that are applicable to a request type. Because there can be policies at request level and operation level, some manual analysis is required to identify their priority or order.

An operation or request type can have multiple approval policies configured at request level and operation level. Whereas, by default, there is only a single approval workflow policy available for an operation. This default approval workflow policy cannot be deleted; new rules can be added to the same.
Pick the approval policy that comes first or next in the order of priority.
Open the default approval policy configuration specific to the request type. If there is a requirement to modify the current approval policy as a bulk workflow policy rule, then open the default bulk policy, for example Bulk Modify User.
Model the current approval policy as an approval workflow rule as follows:
1. Create a new approval workflow rule with the same name as the approval policy name picked in step 2. Provide a description for the approval workflow rule.
  
  See Also:
  
  "Creating Approval Workflow Rules" and "Modifying Approval Workflow Rules" for information about the user interface to work with approval workflow rules
2. In the Approval Workflow Configuration page of Oracle Identity System Administration, search and select the workflow that is configured in the approval policy as approval process.
3. Model the approval policy rule as approval workflow rule condition in the Approval Workflow Configuration page.
Repeat steps 2 through 4 for all the approval policies applicable to a request type.
Repeat steps 1 through 5 for all the request types.

4.3.4 Enabling Approval Workflow Rules

Enabling approval workflow rules in an upgraded deployment involves enabling the workflow rules feature and understanding the in-flight rquest lifecycle.

This section contains the following topics:

4.3.4.1 Enabling the Approval Workflow Rules Feature

In an upgraded deployment of Oracle Identity Manager, the approval workflow rules feature is disabled by default. To enable the feature:

Ensure that SOA is enabled. To do so, verify that the value of the Workflows Enabled system property is true.
Ensure that migration of approval policies to approval workflows, as described in "Migrating Approval Policies to Approval Workflow Rules", has been completed.
Set the value of the Workflow Policies Enabled system property to true.
Restart Oracle Identity Manager Managed Server.

4.3.4.2 About In-Flight Request Lifecycle

When you upgrade Oracle Identity Manager to 12c Release 2 (12.2.1.2.0), there can be some in-flight requests that must be processed after the upgrade. After the approval workflow policies feature is enabled, the life cycle of all the in-flight requests are the same as in the earlier release of Oracle Identity Manager, except for workflow determination. SOA workflow to be initiated is determined based on the workflow policies and not approval policies. In-flight request go through the existing request stages, which are Obtaining Request Approval, Obtaining Operation Approval, Request Approval Approved, Operation Approval Approved, Request Approval Rejected, and Operation Approval Rejected.

After enabling approval workflows, the in-flight requests are processed in the following manner:

For In-Flight Requests Awaiting Request Approval

Figure 4-5 shows the lifecycle of in-flight requests that are awaiting request approval.

Figure 4-5 In-Flight Requests Awaiting Request Approval

Description of "Figure 4-5 In-Flight Requests Awaiting Request Approval"

If the request is approved, then approval workflow rule is evaluated to determine the SOA workflow to be initiated at operation level. The request moves to the Obtaining Operation Approval stage.

If the request is rejected, then the request moves to Request Approval Rejected stage.

For In-Flight Requests Awaiting Operation Approval

Figure 4-6 shows the lifecycle of in-flight requests that are awaiting operation approval.

Figure 4-6 In-Flight Requests Awaiting Operation Approval

Description of "Figure 4-6 In-Flight Requests Awaiting Operation Approval"

If the request is approved, then the operation is initiated.

If the request is rejected, then the request moves to the Operation Approval Rejected stage.

4.4 Migrating Workflow Rules From Test to Production

You can migrate workflow rules from a test environment to a production environment.

This section contains the following topics:

4.4.1 About Migration of Workflow Rules From Test to Production

Workflow rules can be exported from the source environment, such as test environment, and imported to the target environment, such as production environment, by using the Deployment Manager.

Migration of workflow rules and rule to operation/policy relationships come under the category of Policy in the Deployment Manager Wizard. See "Migrating Incrementally Using the Deployment Manager" for information about the Deployment Manager.

As workflow rules are associated with a specific operation, you must select the operation first, and then select the rules that you want to export.

While exporting/importing workflow rules, the workflow rule configuration in the source environment overrides the workflow rule configuration in the target environment. As a result, when workflow rules for an operation are imported, all rules configured for that operation are deleted, and the exported rules are associated with that operation in the target environment. In addition, the order of the rules in the source environment are carried over to the target environment.

For example, consider that the Create User operation has rules Rule1 and Rule2 configured in the target environment. But the Create User operation on the source environment has rules Rule1 and Rule3, and both are exported. When these rules are imported to the target environment, Rule1 and Rule2 are deleted, and Rule1 and Rule3 are associated with the Create User operation.

Therefore, it is recommended to maintain the source/test environment as the source of truth for workflow rule configuration.

4.4.2 Moving Workflow Rules From Test to Production Using the Deployment Manager

Use the Deployment Manager to export the operations and policies and import them to the target environment.

To export/import the workflow rules by using the Deployment Manager:

Login to Oracle Identity System Administration of the source/test environment as the system administrator.
On the left pane, under System Configuration, click Export. The Export Configuration page opens and the Search Objects option is displayed.
From the Search Objects page, select Type as Policy and click Search icon. Search result is displayed in the Available Entities table.
From the Available Entities table, select the check box against the policy you want to export the workflow rules. The Policy is moved to the Selected Entities table.
Click Next or click Export Options in the train link. The Export Options page is displayed.
Set Dependency to Yes, select the workflow rules for the selected operations that you want to export.
Continue with the remaining steps of the wizard and complete the export.
Login to Oracle Identity System Administration of the target/production environment as the system administrator.
On the left pane, under System Configuration, click Import.
Select the file that contains the exported workflow rules (from step 7), and complete the import process. For detailed steps see, Importing Deployments

Note:

A workflow rule condition can refer to entities, such as role or application instance. Such dependent entities cannot be migrated as part of workflow rule migration. You must manually configure or migrate such dependent entities in the target/production environment. Otherwise, rule evaluation result might be unpredictable.

4.5 Running Oracle Identity Governance Without Workflows

Oracle Identity Manager is dependent on SOA server, which is installed and enabled by default. However, you can manually disable workflows by disabling SOA as a post install configuration step.

This chapter describes the procedure to disable SOA and the functional impact of doing so in the following sections:

4.5.1 Disabling SOA Server

You can disable the SOA server by setting the value of the Workflows Enabled system property.

To disable SOA Server:

Shutdown the SOA Managed Server.
Set the value of the Workflows Enabled system property to false. See Table 19-1 for information about this system property.
Restart Oracle Identity Manager Managed Server.

SOA Server can be re-enabled by setting the value of the Workflows Enabled system property to true.

Note:

Oracle recommends that you do not enable SOA again after disabling it. Toggling between enabling and disabling workflows is not supported.

4.5.2 About the Impact of Disabling Workflows

The primary functional impact of disabling workflow is that all operations are auto-approved, which means that the operations are completed without any approvals. Because no approval workflows are initiated, neither approval policies nor approval workflow rules are evaluated.

Figure 4-7shows the impact of disabling workflows.

Figure 4-7 Disabled Workflows

Description of "Figure 4-7 Disabled Workflows"

In addition, Table 4-6 lists the features that are not available when workflow is disabled.

Table 4-6 Unavailable Features When Workflow is Disabled

Feature	Details
Request approvals	All the operations performed are direct operations and a request is not created, with the following exceptions: Request is always created for bulk operations. Child requests are created immediately, which are auto-approved. Request is always created for all operations with future effective date. All the newly created requests are auto-approved without involving any human approval. For example, all add access, self profile modification, and account/entitlement modification requests, are direct operations. Approval policies or workflow rules are not evaluated. See "About Rule Conditions" for information about workflow rules.
Provisioning operations	Disconnected application instance: Manual fulfillment tasks for disconnected application instances do not work when workflow is turned off. Provisioning operations for disconnected application instances will fail. Account-entitlement dependency: Entitlement request with one beneficiary when workflow is turned off works in the following way: Selected user has one account: The account is preselected, and there is no impact. Selected user has multiple accounts: It is mandatory to select an account, and there is no impact. Selected user has no account: Application instance automatically gets added to the cart and a bulk request is created. As SOA is turned off, bulk and child requests will be auto-approved. Selected user has a pending account request: Newly created entitlement request is set as dependent on the account request. If the account is pending for approval, then as SOA is turned off, the requests are not processed further. If account request is waiting for an effective date, then the entitlement request is processed after the account request is completed. Entitlement request with multiple beneficiaries when SOA is turned off results in bulk request. The bulk request is auto-approved and child requests are created. The following are some specific use cases: User has one account: entitlement request: This is auto-approved and completed. User has multiple accounts: Corresponding entitlement child requests will fail. User has no account: Corresponding entitlement child requests will fail. User has pending account request: Entitlement child request is set as dependent on the account request. If the account is pending for approval, then as SOA is turned off, the requests are not processed further. If account request is waiting for an effective date, then entitlement request is processed after the account request is completed. The following account -entitlement use cases that rely on SOA composites will fail: A multiple beneficiary request for entitlement where one or more beneficiaries have no account, and there is no in-flight account request (for that beneficiary and application instance combination). A multiple beneficiary request for entitlement where one or more beneficiaries have multiple accounts, and account is not identified.
Identity Auditor features	When workflow is turned off, Certification and Identity Auditor features do not work, and the UI links related to Certification and Audit Compliance are not displayed in both Identity Self service and Identity System Administration. This is true when the value of the `Identity Auditor Feature Set Availability` system property is set to `TRUE`. When workflow is turned off, any certification-related scheduled job will not be run, and appropriate messages will be logged.
UMS notification	UMS notification provider works depending on whether workflows are enabled or not. UMS provider does not send notifications when SOA is not available. If UMS provider is kept enabled when SOA is not available, then UMS does not attempt to send notifications and logs an error message. An alternate provider, for example, the EmailServiceProvider must be configured and enabled to continue sending notifications.
Web services connector	Web services connector does not work when SOA is disabled.
SIL-based SoD	SIL-based SoD check do not happen when workflows are disabled even when the operation results in a request. However, SIL-based SoD Checks continue to work at the provisioning level when SOA is unavailable.
User management	User self-registration: User self-registration continue to work when SOA is turned off. Organization is calculated through the home organization determination policy, and the self registration request is auto approved. Proxy user management: The proxy feature is disabled when SOA is turned off. The panel for managing proxies in the Identity Self Service is not displayed, and all the APIs around proxy throws an exception with the following message: Proxy functionality is only supported when SOA and workflows are enabled.
User interface	The following features are disabled (and not displayed) in the default user interface when the `Workflows Enabled` system property is set to false: In Oracle Identity System Administration: The Approval Policies link In Oracle Identity Self Service: The Certifications, My open tasks, and Pending Approvals links/icons in the Self Service Home page, and the Approvals tab in the Request Details/Summary pages

4.6 Use Cases for Disabled or Deleted Proxy Users

When users are disabled, Oracle Identity Governance handles tasks without losing the assignments although the target assignee of the task being initiated is already disabled, or the current assignee of the pending tasks is being disabled. The type of tasks can be one of request/approval task, identity audit (IDA) scan violation, or certification.

Applying Oracle Identity Governance Bundle Patch 12.2.1.3.210329 provides the following enhancements:

Removing Proxy Relationships When a User is Disabled or Deleted

When a user is disabled or deleted, all proxy relationships defined with the user is not effective anymore. If there is an active proxy at the time of disabling the user, the proxy will be terminated. This means that Oracle Identity Governance removes all proxy data of this user from the database and SOA.

For example, User1 and User2 set their proxy to User3, and User3 sets his proxy to User4. When User3 is disabled, those proxy relationships will be removed.

Proxy cleanup actions are done both with Oracle Identity Governance database and SOA. As a result, the proxy data is completely removed from the system.

Task Assignment with Proxy

When a user has proxy a setup, all tasks are delegated to both the user and its proxy. This means that both the users have the same level of control at the beginning. When a user starts to take actions on the task, modification actions on the same task are limited for the other assignee.

Reassigning Tasks When Current Assignee is Disabled or Deleted

When a user is disabled or deleted, the existing proxies from/to this user are removed, and all pending tasks are reassigned to the other user or role depending on the configuration of the OIG.DefaultTaskReassignee system property. It is important to set this property with an active user or role.

By default, the value of the OIG.DefaultTaskReassignee system property is the SYSTEM ADMINISTRATORS role so that pending tasks can be reassigned to the SYSTEM ADMINISTRATORS role when a user is disabled or deleted.

When the value of the OIG.DefaultTaskReassignee system property is a manager, Oracle Identity Governance finds the closest active manager from the hierarchy if the current target assignee is disabled.

When the value of the OIG.DefaultTaskReassignee system property is a user, Oracle Identity Governance reassigns the task to the user.

When the value of the OIG.DefaultTaskReassignee system property is a role, Oracle Identity Governance reassigns the task to the role. Here, the role name as the value of the OIG.DefaultTaskReassignee system property is case-sensitive.

If Oracle Identity Governance cannot find any valid assignee, then the tasks are reassigned to the System Administrator.

Note:

This feature works for the disable and delete operations initiated from Oracle Identity Governance user interface or APIs only. Disabling and deleting the users from reconciliation and bulk load does not trigger this new feature.

Defining the New Initial Task Assignee

If the target assignee of a request being created is already disabled, Oracle Identity Governance looks for the closest manager of the initial target assignee based on the configured approval workflows, as described below:

OIG.BeneficiaryManagerApprovalWorkflows (for request only): When the initial target assignee is already disabled, Oracle Identity Governance looks for the closest manager of the beneficiary of the request with the defined approval workflow, as shown:
```
OIG.BeneficiaryManagerApprovalWorkflows=default/BeneficiaryManagerApproval!4.0,default/MyCustomComposite!1.0
```
Multiple composites can be defined with the comma separator.
OIG.RequesterManagerApprovalWorkflows (for Request only): When the initial target assignee is already disabled, Oracle Identity Governance looks for the closest manager of the requester of the request with the defined approval workflow, as shown:
```
OIG.RequesterManagerApprovalWorkflows=default/RequesterManagerApproval!4.0,default/MyCustomComposite2!1.0
```
Multiple composites can be defined with the comma separator.
Note:

The OIG.BeneficiaryManagerApprovalWorkflows and OIG.RequesterManagerApprovalWorkflows properties are applicable only for requests. By default, OIG.BeneficiaryManagerApprovalWorkflows is set to default/BeneficiaryManagerApproval!4.0, and OIG.RequesterManagerApprovalWorkflows is set to default/RequesterManagerApproval!4.0. You can append more approval workflows, such as the following:
```
OIG.BeneficiaryManagerApprovalWorkflows= default/BeneficiaryManagerApproval!4.0,default/DefaultOperationalApproval!5.0
```
Identity Audit (IDA) scan violations and certifications are assigned to the closest active manager of the initial target assignee if the manager is already disabled.

If a valid assignee is not found, Oracle Identity Governance assigns the IDA scan violations and certifications to the user defined for OIG.DefaultTaskReassignee, and then for SYSTEM ADMINISTRATOR or the default certification assignee, if defined.

When certifications are created, if there is no valid assignee even after looking up for the active higher manager and the user defined for OIG.DefaultTaskReassignee and XL.AlternativeReviewerIDForManager, Oracle Identity Governance skips the creation of such certifications. Therefore, make sure that the two system properties are defined with active users with enough privilege for the operations.

Deploying the New Version of the CertificationProcess Composite

To enable this feature after applying this bundle patch, deploy the new version of the CertificationProcess composite. To do so:

Create a backup of the current version of the CertificationProcess composite from SOA, as shown:
1. Login to Oracle Enterprise Manager Fusion Middleware Control.
2. Navigate to SOA, soa-infra, default, CertificationProcess[2.0].
3. From the SOA Composite menu, select Export the composite.
Extract the contents of the OIM_HOME/server/workflows/composites/CertificationProcess.zip file to a temporary directory.
Perform the following steps to deploy the deploy/sca_CertificationProcess_rev2.1.jar file:
1. In Oracle Enterprise Manager Fusion Middleware Control, navigate to SOA, soa-infra, default.
2. From the SOA Composite menu, select SOA Deployment, Deploy.
3. Provide the complete path of the /deploy/sca_CertificationProcess_rev2.1.jar file.
4. Restart the SOA servers.