1 Oracle Identity Analytics Identity Warehouse

This chapter contains the following sections:

Section 1.1, "Overview"
Section 1.2, "Working With Resources"
Section 1.3, "Working With Applications"
Section 1.4, "Understanding How Risk Summaries are Calculated"
Section 1.5, "Working With Extended User Custom Properties"
Section 1.6, "Working With Orphan Accounts"
Section 1.7, "Creating Business Structure Rules"

1.1 Overview

This chapter documents Identity Warehouse functionality that is available to business administrators, but not to general business users. Identity Warehouse information for general business users is documented in the User's Guide for Oracle Identity Analytics "Identity Warehouse" chapter.

See the User's Guide for Oracle Identity Analytics to learn more about the following Identity Warehouse topics:

What is the Identity Warehouse?
Understanding the Identity Warehouse user interface
Working with users
Searching for a user
Viewing user details
Working with Business Structures
Associating users with roles and business structures
Setting user status
Working with resources
Working with policies
Working with roles
Setting the segregation of duties at the role and policy levels

1.2 Working With Resources

Resources are the applications and enterprise information assets that users need to do their jobs. In Oracle Identity Analytics, a resource is an instance of a resource type, which is a grouping of like resources. A resource type defines meta-data common to all resources of that type. For example, a resource type of "Oracle DBMS" might define entitlements (that is, attribute-values of Oracle database accounts) that are common to all database instances. Each resource of that type represents a specific database instance to which a user might have access

Common resource types include platforms (Windows 2000, UNIX®, Mainframe) or business applications (such as, billing and accounts payable applications). Each resource has an owner who handles the various operations on the resource, such as reviewing user entitlements. The user entitlements are collected from different resources and stored in a central repository.

Note:

For information about configuring resource types, including creating or modifying resource types, see Section 11.1.3, "Resource Types Configuration."

1.2.1 To Create or Modify Resources

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Resources.
To add a new resource, click the New Resource button.

The New Resource dialog box opens.
Complete the form:
- Resource Type - Select the resource type that the new resource/directory should belong to.
- Resource Name - Type a name for the resource.
- Host Name - Type the host name.
- Host IP - Type the host's IP address.
- Description - Type a short description for the resource.
- Comments - Additional comments can be entered here.
Click Save.

1.2.2 To Delete Resources

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Resources.

All the resources and resource types are listed.
Go to the resource you want to delete, then click Delete in the Actions column.

A window opens asking you to confirm the delete action.

1.3 Working With Applications

An application is a collection of multiple resource types and resources. You can select the resource type and resources to be included in the application and enter metadata around applications.

1.3.1 To Create Applications

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Applications.
Click the New Application button.

The Create Application page opens.
Complete the form.
- Name - Enter the name of the application.
- Version - Enter version details.
- Description - Enter a description for the application.
- Environment - Enter environment details.
- Comments - Enter comments, if applicable.
- Status - Set the status as active or inactive. You can schedule a user assignment for the application only if the application is in the active state.
Click Next.

The Add Owners page opens.
Click the Add Owner button.

The Search dialog box opens.
Search for the user to add as the application owner.

For help using Search, see the "Searching for a User" topic in the "Identity Warehouse" chapter of the User's Guide for Oracle Identity Analytics.
Click Next.

The Add Conditions page opens.
Click the Add Conditions button.

The Add Conditions window opens.
From the table select the resource types, resources, attribute names, and attribute values. You do not have to select from all four columns

Click OK.
Click Next.

The summary page opens.
Click Create.

1.3.2 To Schedule a Job for Assigning Users to Applications

In Oracle Identity Analytics, you cannot use the user interface to manually add users to (or remove users from) applications. Instead, after you create an application, you need to schedule a job using configuration files. The job scans all users and assigns the users who have an account in the selected resource type to the application.

To enable a scheduling job, edit the scheduling-context.xml file located in the $RBACX_HOME/WEB-INF folder.
To schedule a job, edit the jobs.xml file located in the $RBACX_HOME/WEB-INF folder.

For detailed instructions, see Section 10.2, "Scheduling a Job by Editing the Configuration Files."

Remember to restart the application server after editing the configuration files.

Note - If you select two or more attribute values from the same resource, users who are associated with any one of the selected attribute values are assigned to the application. However, if you select one or more attribute values from multiple resources, users who have an account in all the multiple resources will be assigned to the application.

1.4 Understanding How Risk Summaries are Calculated

You can directly assign high, medium, and low risk levels to roles, resources, and resource-attribute values (entitlements), as well as to certain predefined risk factors. A risk-aggregation job calculates Risk Summaries for the remaining higher-order data objects that are needed to support the OIA Identity Certification feature. These objects include every User, User-Role assignment, Account, and Account-Attribute value in the Identity Warehouse. During identity certification, OIA certifiers use Risk Summaries to separate high-risk certification items from medium-risk and low-risk items.

This section describes how the system processes risk levels to arrive at Risk Summaries. It also describes the risk-aggregation job, which you can run manually or on a scheduled basis.

Note:

In OIA, Roles, Resources, and Entitlements (Resource-Attribute Values) are metadata objects, whereas Users, Accounts, and Account-Attribute Values are instance-data objects.

Think of metadata objects as "structural" objects that represent and describe your information systems within OIA, whereas instance-data objects are the individual instances of application data that populate the systems described. For example, consider a customer service application (a Resource) that has a predefined role that enables users to create trouble tickets (an entitlement). In this example, a single Resource object represents the application and a single entitlement object represents a specific privilege within that application.

Now consider there might be thousands of user accounts on this resource, some subset of which has the entitlement-assignment that allows the user to create a trouble ticket. In the Identity Warehouse, each user account is represented by an Account object, and each instance of the entitlement assignment is represented by an Account-Attribute-Value object. This illustrates the one-to-many relationship that exists between metadata objects and instance data objects. A single resource (metadata object) can have multiple accounts (instance-data objects), and a single entitlement (metadata object) can have multiple assignment instances (instance-data objects). OIA calculates the risk levels for instance-data objects because it would not be feasible for a human to process risk levels for every User, Account, and Account-Attribute Value in the Identity Warehouse on a recurring basis.

1.4.1 Understanding Item Risk and Risk-Factor Mappings

Item Risk and the Risk-Factor Mappings are settings that are under your direct control. Item Risk is discussed first.

1.4.1.1 Understanding Item Risk

Item Risk refers to the risk levels that you and other administrators can assign to specific roles, resources, and entitlements in the Identity Warehouse. (There are other ways that Item Risk can be assigned to metadata objects, but direct assignment is the most common method.)

Note:

In OIA, three bars signifies high risk, two bars signifies medium risk, one bar signifies low risk.

Assigning an Item-Risk level to a metadata object in the UI is straightforward. To do so, you open the object in the Identity Warehouse and select a High, Medium, or Low risk setting from the menu.

If you do not directly assign an Item-Risk level to a metadata object in the Identity Warehouse, the system assigns a default Item-Risk level for you. Roles, Resources, and Entitlements can each have a default value. You can configure a default Item-Risk level using the Risk Mapping page (from the menu, choose Administration > Configuration > Risk Level).

Generally speaking, you should reserve high Item-Risk levels for metadata objects that confer highly-restricted privileges to users. Note that setting a high Item-Risk level on an object will cause its parent object to also have a high Risk-Summary value. Similarly, setting a medium Item-Risk level on an object will cause its parent object to have at least a medium Risk-Summary value. In order for a higher-order object to have a low Risk-Summary value, all of the objects under it in the system hierarchy would have to have low risk settings.

Following are the other ways that Item Risk can be assigned to objects in OIA:

An external system such as Oracle Identity Manager can set an object's risk level. When OIA imports a role or glossary entry from the external system, if that object has an assigned value for Item Risk, the value is also imported. (OIA does not import Item Risk values for any other type of imported object. Instead, the system assigns the object a default Item-Risk level as described earlier.)
OIA can set Item-Risk values when customers upgrade from a previous version of the software. Prior to version 11gR1 PS1, OIA had an attribute named "High-Privileged." Upon upgrade, instances of the "High-Privileged" attribute are converted to a value of high Item Risk if the High-Privileged attribute is set. If it is not set, the Item Risk will default to a value of medium risk.

For steps that describe how to assign an Item-Risk level to a specific role, resource, or entitlement, see the following sections.

To assign an Item-Risk level to a specific role, see "To Rename, Modify, or Decommission (Delete) a Role" in the "Identity Warehouse" chapter of the User's Guide for Oracle Identity Analytics.
To assign an Item-Risk level to a specific resource or a specific entitlement, see "To Create a Policy" in the "Identity Warehouse" chapter of the User's Guide for Oracle Identity Analytics.

Note:

The policy Risk-Level attribute is a deprecated attribute that has no current use.

1.4.1.2 Understanding Risk-Level Mappings (Risk Factors)

Risk-Factor Mappings are settings that map risk levels to certain predefined conditions within OIA. For example, you might configure "items with open audit violations" as high risk, whereas "items that are closed as risk-accepted" you might configure as medium risk.

Generally speaking, you should reserve high Risk-Factor levels for conditions in which privileges are being extended to users that may be irregular or dangerous.

There are three Risk-Factor categories in OIA, and each category contains multiple settings. Risk-Factor categories are described in the following table.

Table 1-1 Risk Factors

Risk Factor	Description
Provisioning Scenarios / Assignment Scenarios	Provisioning Scenarios define the risk levels that should be associated with the method or mechanism that a system external to OIA used to assign a role, account, or account-attribute value to a user. (Oracle Identity Manager is one example of an external system.) For example, you might configure a risk level of High for objects that are provisioned directly by an administrator, and a risk level of Low for objects that are provisioned based on Policies that are tied to Roles. For a description of each of the Provisioning Scenarios risk-level mapping settings, see Section 11.1.2.1, "External Provisioning (Provisioning Scenarios)." Assignment Scenarios define the risk levels that should be associated with assignment actions applied from within OIA. For example, you might configure a risk level of High for role memberships that are assigned directly by an administrator, and a risk level of Low for objects that are assigned by role-membership rules. For a description of each of the Assignment Scenarios risk-level mapping settings, see Section 11.1.2.2, "System Defaults," "Assignment Scenarios."
Audit Violations (Open SoD Violation)	Defines the risk level associated with having a Segregation-Of-Duties (SoD) violation. For example, you might configure a risk level of High for an unresolved SoD violation, and a risk level of Medium for an SoD violation that was closed as risk-accepted. For a description of each of the Audit Violations risk-level mapping settings, see Section 11.1.2.2, "System Defaults," "Audit Violations."
Last Certification Action	Defines risk level based on the status of the last certification for the account, account-attribute value, or user-role assignment under consideration. For example, configure a risk level of Low for any item for which the previous certification decision was to approve, and configure a risk level of Medium for any item for which the previous certification decision was to Certify Conditionally. Finally, you might configure a value of High for any item for which the previous certification decision was Abstain or Revoke. For a description of each of the Last Certification Action risk-level mapping settings, see Section 11.1.2.2, "System Defaults," "Last Certification Action."

Risk Factor

Description

Provisioning Scenarios / Assignment Scenarios

Provisioning Scenarios define the risk levels that should be associated with the method or mechanism that a system external to OIA used to assign a role, account, or account-attribute value to a user. (Oracle Identity Manager is one example of an external system.)

For example, you might configure a risk level of High for objects that are provisioned directly by an administrator, and a risk level of Low for objects that are provisioned based on Policies that are tied to Roles.

For a description of each of the Provisioning Scenarios risk-level mapping settings, see Section 11.1.2.1, "External Provisioning (Provisioning Scenarios)."

Assignment Scenarios define the risk levels that should be associated with assignment actions applied from within OIA.

For example, you might configure a risk level of High for role memberships that are assigned directly by an administrator, and a risk level of Low for objects that are assigned by role-membership rules.

For a description of each of the Assignment Scenarios risk-level mapping settings, see Section 11.1.2.2, "System Defaults," "Assignment Scenarios."

Audit Violations (Open SoD Violation)

Defines the risk level associated with having a Segregation-Of-Duties (SoD) violation.

For example, you might configure a risk level of High for an unresolved SoD violation, and a risk level of Medium for an SoD violation that was closed as risk-accepted.

For a description of each of the Audit Violations risk-level mapping settings, see Section 11.1.2.2, "System Defaults," "Audit Violations."

Last Certification Action

Defines risk level based on the status of the last certification for the account, account-attribute value, or user-role assignment under consideration.

For example, configure a risk level of Low for any item for which the previous certification decision was to approve, and configure a risk level of Medium for any item for which the previous certification decision was to Certify Conditionally. Finally, you might configure a value of High for any item for which the previous certification decision was Abstain or Revoke.

For a description of each of the Last Certification Action risk-level mapping settings, see Section 11.1.2.2, "System Defaults," "Last Certification Action."

In the UI, you configure Risk-Factor mappings using the Risk Mapping page (from the menu, choose Administration > Configuration > Risk Level).

Note:

Changing Risk-Level mappings on the Configuration page in the UI can cause major ripple effects that impact Risk Summaries throughout the Identity Warehouse. During your initial setup you should configure mappings on the Risk Level configuration page, and then avoid making additional unnecessary changes.For more information, see Section 1.4.3, "Understanding How Changing Risk Configuration Values Impacts the System."

1.4.2 Understanding Risk Aggregation and Risk Summaries

The Risk-Aggregation job processes Item-Risk levels and Risk-Factor levels, and calculates Risk Summaries for each higher-order object that supports Identity Certification.

In the first phase of risk aggregation, the Risk-Aggregation job evaluates each individual object's Item-Risk level and its three Risk-Factor levels and assigns the highest of the four levels to the object's Risk Summary property. A Risk Summary value is calculated for each individual User object, User-Role Assignment object, Account object, and Account-Attribute-Value (AAV) object. The following diagram illustrates this process.

Surrounding text describes oiaad_dt_001.gif.

Once Risk Summaries are calculated for every object in the Identity Warehouse, the next phase of aggregation begins, in which the Risk Summary of each individual object rolls up to the Risk Summary of the parent object that contains it.

Above the AAV level, each data object's Risk Summary value contributes to the Risk Summary of the parent-object that contains it. For example, Account objects are one hierarchy level up from AAV objects, and User objects are one hierarchy level up from there. So, the Risk Summary of every AAV object within an Account object contributes to the Risk Summary for that Account, and, similarly, the Risk Summary for every Account object within the User object contributes to the Risk Summary for that User.

User objects are also one level above User-Role Assignment objects, so the Risk Summary for every User-Role Assignment object contributes to the Risk Summary for that User.

The following diagram illustrates this process.

Surrounding text describes oiaad_dt_002.gif.

In the diagram, the Risk-Summary value of the Account-Attribute Value rolls up to the Account object. The Risk-Summary values of Accounts and the Risk-Summary values of User-Role Assignments roll up to the Risk Summary of any associated User.

1.4.3 Understanding How Changing Risk Configuration Values Impacts the System

There are three main actions or system events that can impact Risk Summary values in the Identity Warehouse. Depending on the action/system event, the impact can be minor, moderate, or major. Each action or event and its consequences is described in the following table.

Table 1-2 Actions or System Events That can Impact Risk Summary Values in the Identity Warehouse

Action or Event	Impact	Description
OIA Users and/or the system make changes to individual data objects	Minor	Applies to changes to individual data objects (such as Accounts, Account Attributes, and User-Role assignments). These values may change frequently. For example, the following types of changes are included in this category: An Attribute Value is added to or removed from an Account. An Account is added to or removed from a User. A Role Assignment is added to or removed from a User. A Risk Factor on an individual data object changes. The impact within the Identity Warehouse is relatively minor because the changes happen at the level of each individual data object.
An administrator or external system makes Item-Risk changes to Roles, Resources, and Resource-Attribute Values	Moderate	Applies to situations where you or another administrator change the risk-level of a Role, a Resource, or a Resource-Attribute Value. The ripple-effect of these changes can be large. Changing the risk level on a metadata object can change the Item-Risk level on every data-object associated with the metadata object. Changing the risk level on a data-object may affect its Risk Summary and, in turn, the Risk Summary of every other data-object that contains it. For example, changing the risk level on a Resource-Attribute Value will change the Item Risk on every Account-Attribute Value (AAV) that corresponds to it. Changing the Item Risk on an AAV may change its Risk Summary. Changing the Risk Summary of an AAV may affect the Risk Summary of the parent Account. Changing the Risk Summary of an Account may affect the Risk Summary of the User who owns the Account.
An administrator makes configuration changes to the Risk-Level Mappings	Major	Applies to situations where you or another administrator change the Risk-Level Mappings on the Configuration page in the UI. Changing the risk level associated with a specific value of a specific risk factor could affect the Risk Summary of any User-Role Assignment, Account, or Account-Attribute Value that has that risk-factor value. Changing the Risk Summary of any User-Role Assignment, Account, or Account-Attribute Value could in turn affect every User associated with an affected User-Role Assignment, Account, or Account-Attribute Value. For this reason, you should change Risk-Level Mappings only rarely.

Action or Event

Impact

Description

OIA Users and/or the system make changes to individual data objects

Minor

Applies to changes to individual data objects (such as Accounts, Account Attributes, and User-Role assignments). These values may change frequently. For example, the following types of changes are included in this category:

An Attribute Value is added to or removed from an Account.
An Account is added to or removed from a User.
A Role Assignment is added to or removed from a User.
A Risk Factor on an individual data object changes.

The impact within the Identity Warehouse is relatively minor because the changes happen at the level of each individual data object.

An administrator or external system makes Item-Risk changes to Roles, Resources, and Resource-Attribute Values

Moderate

Applies to situations where you or another administrator change the risk-level of a Role, a Resource, or a Resource-Attribute Value.

The ripple-effect of these changes can be large. Changing the risk level on a metadata object can change the Item-Risk level on every data-object associated with the metadata object. Changing the risk level on a data-object may affect its Risk Summary and, in turn, the Risk Summary of every other data-object that contains it.

For example, changing the risk level on a Resource-Attribute Value will change the Item Risk on every Account-Attribute Value (AAV) that corresponds to it. Changing the Item Risk on an AAV may change its Risk Summary. Changing the Risk Summary of an AAV may affect the Risk Summary of the parent Account. Changing the Risk Summary of an Account may affect the Risk Summary of the User who owns the Account.

An administrator makes configuration changes to the Risk-Level Mappings

Major

Applies to situations where you or another administrator change the Risk-Level Mappings on the Configuration page in the UI.

Changing the risk level associated with a specific value of a specific risk factor could affect the Risk Summary of any User-Role Assignment, Account, or Account-Attribute Value that has that risk-factor value. Changing the Risk Summary of any User-Role Assignment, Account, or Account-Attribute Value could in turn affect every User associated with an affected User-Role Assignment, Account, or Account-Attribute Value.

For this reason, you should change Risk-Level Mappings only rarely.

1.4.4 Understanding the Risk-Aggregation Job

The riskSummaryMaintenanceJob calculates Risk Summaries in Oracle Identity Analytics. Each data object's Risk Summary score is accurate as of the last time the riskSummaryMaintenanceJob ran successfully.

1.4.4.1 To Enable the Risk-Aggregation Job

Open the scheduling-context.xml file for editing.
Locate the entry for riskSummaryMaintenanceJob within the jobDetails property of the quartzSchedulerFactoryBean bean definition.
Uncomment the reference to riskSummaryMaintenanceJob.
Uncomment the reference to the riskSummaryMaintenanceJobTrigger in the triggers property for the quartzSchedulerFactoryBean.
Restart the application server

Note:

If the riskSummaryMaintenanceJob takes a long time to complete, update statistics on your database indexes to improve performance. New OIA installations in particular may benefit from updating statistics on database indexes.

For information about how to update statistics on database indexes, consult your database server documentation.

1.4.4.2 To Control How Often the Risk Aggregation Job Runs

Open the jobs.xml file for editing.
Locate the riskSummaryMaintenanceJobTrigger definition and modify the cron expression based on your needs.
For more information about the jobs.xml file and editing cron expressions, see Section 10.2, "Scheduling a Job by Editing the Configuration Files."

1.5 Working With Extended User Custom Properties

Custom properties and extended custom properties save custom user information in the Identity Warehouse. Out-of-the-box, Oracle Identity Analytics features twenty custom properties. If you need more than twenty custom properties, you can enable extended user custom properties and use them in a similar way.

Note:

The known limitations while using extended user custom properties are as follows:

There is no ability to search using extended properties.
Extended properties cannot be used in audit rules.
Extended properties cannot be used in role management rules.

In the user interface, custom properties are displayed by choosing Identity Warehouse > Users > User Name, and clicking the Custom Properties tab, whereas extended custom properties are displayed by clicking the User Defined Properties tab.

Custom properties and extended custom properties can be populated with user data either by importing the data or by using the user interface.

1.5.1 To Enable Extended User Custom Properties

Open the idw-context.xml file located in $RBACX_WAR/WEB-INF.
Scroll down to the section of the file that contains the comment Add Extended Global User Attributes and locate the following lines:
```


      
```
Remove the comment tags from around the extended property lines. (Remove the  tags for each extended attribute that you want to enable.) To create additional extended user properties, copy and paste additional extended property values in the idw-context.xml file and increment the number as needed (for example, extendedAttribute3, extendedAttribute4, and so on).
Change extended attribute label names as needed by editing the rbacxmessages.properties file and adding a line for each extended user property. For example:
```
user.extendedAttribute1=Sample Label Name 1 
user.extendedAttribute2=Sample Label Name 2
```
For more information, see the "To Modify User Labels" topic in the "Customizing the Oracle Identity Analytics User Interface" chapter of the System Integrator's Guide for Oracle Identity Analytics.

1.6 Working With Orphan Accounts

An orphan account is an account that does not correlate to a global user. You can assign orphan accounts to users from the user interface.

1.6.1 To Assign an Orphan Account to a User

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Users.
Click Orphan Accounts.

Resource Types are listed in the panel on the left.
Expand each resource type to view orphan accounts.
Click the Account Name on the right to view the Account and Entitlement details.
Select the account and click the Assign to User button.
Search for and select the user that you want to assign the account to.

For help using Search, see the "Searching for a User" topic in the "Identity Warehouse" chapter of the User's Guide for Oracle Identity Analytics.
Click OK.

1.7 Creating Business Structure Rules

Business structure rules correlate users to appropriate business units based on correlation rules that you define. You can define business structure rules to reduce the need for manual correlation.

If the user meets the conditions you have specified, then the system automatically assigns the user to the business structure, along with any associated roles and policies.

1.7.1 To Create Business Structure Rules

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Business Structures.
Click Rules.
Click New Rule.
Complete the Rule Name, Description, and Status fields, and click Next.
Create one or more conditions for the rule.

Specify an object, an attribute, and the condition, and enter a value.
- To add more conditions, select AND or OR, and click Add Condition.
- Use the Group and Ungroup buttons to create complex conditions.
Click Next.
Specify the business structure and click Next.
Search for the user to add as the rule owner and click Next.

For help using Search, see the "Searching for a User" topic in the "Identity Warehouse" chapter of the User's Guide for Oracle Identity Analytics.
Select an unAssign action. An unAssign action is the action taken by Oracle Identity Analytics in the event of a rule change.
- No Action - Means no change takes place to the existing business structure.
- Remove Business Structure - Means the business structure is removed in the event of a rule change. Only users who satisfy the new rule are now part of the business structure.
- Notify Administrator - Means the administrator is notified in the event of a rule change. Click Choose Template to select an email template.
Click Finish.

The business structure rule is created.
The following actions are optional:
- Preview - Means Oracle Identity Analytics runs the rule and allows you to preview the results. However, Oracle Identity Analytics does not save the results of the rule. You can either save the results or discard them. To preview the results of the rule, see Section 1.7.2, "To Preview Results Of A Business Structure Rules Job."
- Run - Means Oracle Identity Analytics runs the rule and saves the results. To run and save the results of the rule, see Section 1.7.3, "To Run Business Structure Rules Job.".
- View results - Oracle Identity Analytics displays the results of the rule, after you have clicked preview or run.

1.7.2 To Preview Results Of A Business Structure Rules Job

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Business Structures.
Click Rules.

The business structure to user rules are displayed.
In the Actions column, click Preview for the rule that you want to preview.

The Rule Preview wizard opens.
Select a strategy from the following options:
- All Business Structures - All business structures in Oracle Identity Analytics are selected.
- Selected Business Structures - Only the business structures you select are included.
- All Users - All users in Oracle Identity Analytics are selected.
- Users Criteria - All users based on the condition you create are included.
- Selected Users - Only the users that you individually select are included.
Based on the user selection strategy in Step 5, select the desired business structures or users and click Next.

The summary page opens.
Click Preview.

The Status column displays the progress of the preview request.
After the preview request is 100 percent complete, click the job name.

The results of the preview are displayed.
Do one of the following:
- To save the results, click Apply.
- To return to the rules page, click Don't Apply.

1.7.3 To Run Business Structure Rules Job

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Business Structures.
Click Rules.

The business structure to user rules are displayed.
In the Actions column, click Run for the rule that you want to run.

The Run Rule wizard opens.
Select a strategy from the following options:
- All Business Structures - All business structures in Oracle Identity Analytics are selected.
- Selected Business Structures - Only the business structures you select are included.
- All Users - All users in Oracle Identity Analytics are selected.
- Users Criteria - All users based on the condition you create are included.
- Selected Users - Only the users that you individually select are included.
Based on the user selection strategy in step 5, select the desired business structure or users and click Next.
Do one of the following:
- To run the rule immediately, click Run Now.
  
  The Status column displays the progress of the run request.
  - After it is 100 percent complete, click the job name.
    
    The results of the rule are displayed.
- To schedule a job for the rule, click Run Later.
  - Complete the form and click Next.
  - Review the summary and click Schedule.

1.7.4 To Edit Business Structure Rules

Log in to Oracle Identity Analytics.
Choose Identity Warehouse > Business Structures.
Click Rules.

The business structure to user rules are displayed.
Click the desired rule.

The Edit Rule page opens. Details of the rule are displayed on the following tabs: General, Conditions, Ownership, and Unassign Actions.
Choose the tabs and make changes as needed.
Click Save.