# SailPoint IdentityIQ 9.0 Documentation > SailPoint IdentityIQ 9.0 Documentation # SailPoint IdentityIQ 9.0 # SailPoint IdentityIQ # IdentityIQ 9.0 Overview SailPoint IdentityIQ is an identity and access management software platform custom-built for complex enterprises. It delivers full lifecycle and compliance management for provisioning, access requests, access certifications, and separation of duties. The platform integrates with SailPoint's extensive library of connectors to intelligently govern access to today's essential business applications. Harnessing the power of AI and machine learning, SailPoint's AI-Driven Identity Security seamlessly automate access, delivering only the required access to the right identities and technology at the right time. SailPoint's comprehensive extension modules address the sophisticated needs of the large enterprise while delivering the flexibility and ease-of-deployment that customers demand. Important The implementation of SailPoint solutions can be complex and requires knowledge of identity governance and target systems. If you need assistance, contact your implementation partner or ask your Customer Success Manager about options for help from SailPoint. We offer [billable Professional Services/Expert Services](https://community.sailpoint.com/t5/Working-With-Services/ct-p/Working_with_PS). These services are particularly valuable during new implementations. ## IdentityIQ Components and Features ### IdentityIQ Compliance Manager Automate access certifications, policy management, and audit reporting to streamline compliance processes and improve the effectiveness of identity governance – all while lowering costs. - **Access Certification**: Maintain a continuous state of compliance by frequently reviewing and rechecking user access throughout your organization. - **Automated Policy Management**: Create a more secure and compliant organization by enforcing policies that prevent inappropriate access or actions that may be in conflict with each other. - **Audit Reporting and Analytics**: Ensure audit readiness and quickly demonstrate compliance with pre-defined audit reports. ### IdentityIQ Lifecycle Manager Lifecycle Manager helps your organization manage changes to access through user-friendly self-service requests and lifecycle events for fast, automated delivery of access to users. - **Access Request**: Single, self-service interface for requesting and approving access empowers business users to request and manage access to resources without burdening IT while adhering to policies. - **Automated Provisioning**: Automatically detect and trigger changes to a user's access based on a user joining, moving within, or leaving an organization. Reduce risk by automatically changing or removing accounts and access in an appropriate manner with automated role and attribute based access. ### Artificial Intelligence and Machine Learning Apply advanced governance capabilities, using the power of SailPoint Predictive Identity to discover suspicious or anomalous access, maintain continuous compliance and enjoy greater productivity across the entire organization. Utilize generated insights and access recommendations to help guide decisions around your security and compliance related efforts. - **Access Insights**: Leverage the power of AI and machine learning to gather and analyze access information and provide rich intelligence to transform your identity program into an even greater strategic resource. - **Access Modeling**: Use an AI-driven approach to instantly generate and implement access role models that align with your evolving business. - **Access Recommendations**: Incorporate AI-based access recommendations to help reviewers safely decide if access should be approved or revoked. ### Privileged Account Management Module IdentityIQ Privileged Account Management module provides a standardized approach for extending critical identity governance processes and controls to highly privileged accounts, enabling IdentityIQ to be used as a central platform to govern standard and privileged accounts. ### Connectors and Integration Modules SailPoint's extensive connector library and advanced integrations let organizations connect and govern access to all types of digital identities across evolving on-premises, hybrid, and cloud environments. This includes more than 100 out-of-the-box connectors across a variety of critical areas: - IT Service Management - Enterprise Applications and Infrastructure - Privileged Access management - Cloud Collaboration - Security and Risk (GRC, SIEM, UBEA, CASB) The identity-driven connectors and integrations allow organizations to: - Get up and running in minutes with out-of-the-box connectors - Accelerate day one productivity by rapidly on-boarding new apps - Continuously adapt to change through customizable controls and policies - Ensure access adheres to data privacy and compliance regulations ### Password Manager IdentityIQ Password Manager delivers a simple-to-use solution for managing user passwords across cloud and on-premises applications policies from any desktop browser or mobile device. By providing intuitive self-service and delegated administration options to manage passwords while enforcing enterprise-grade password, IdentityIQ enables businesses to reduce operational costs and boost productivity. ### Access Risk Management Access Risk Management automates real-time access risk analysis, simplifies GRC processes, and even identifies a potential user's risks before access is granted. Centralize all access risk governance within SailPoint's identity platform for: - **Unified Risk Management**: Experience comprehensive, seamless governance, risk, and compliance (GRC) and identity protection. - **Enterprise-wide Visibility**: Get a full view of your separation of duties (SOD) violations including risk simulations across applications before access is provisioned. - **Compliance**: Streamline GRC processes, access reviews, emergency access management and reduce audit deficiencies and compliance violations. ### Identity Security Platform SailPoint's Identity Security Platform lays the foundation for effective and scalable IAM within the enterprise. It establishes a common framework that centralizes identity data, captures business policy, models roles, and takes a risk-based, proactive approach to managing users and resources. The platform is fully extensible, providing robust analytics which transforms disparate and technical identity data into relevant business information, resource connectivity that allows organizations to directly connect IdentityIQ to applications running in the datacenter or in the cloud, and APIs and a plugin framework to allow customers and partners to extend IdentityIQ to meet a wide array of needs. An open platform allows organizations to build a single preventive and detective control model that supports all identity business processes, across all applications – in the datacenter and the cloud. ### Access History Access History helps organizations track the history of access and attribute changes for identities. You can confirm that attributes, entitlements, and access were provisioned, changed, or removed as expected, discover which identities have entitlements to a given application and how they were acquired, and export Access History results to csv files to document how access stands on a specific date. ## Where to Get More Information ### SailPoint Community In [SailPoint Community](https://community.sailpoint.com/), you can engage with peers and experts to ask questions and share answers, submit ideas, read wiki articles and technical white papers, watch webinars, and more. ### SailPoint Developer Community The [Developer Community](https://developer.sailpoint.com/) contains everything you need to build, extend, and automate scalable identity solutions, including API documentation, developer tools, discussion forums, and a technical blog. ### Identity University At [SailPoint's Identity University](https://university.sailpoint.com/) you can enroll in self-paced e-learning or instructor-led training, watch short, targeted QuickLearns, and prepare for SailPoint certification exams. ### SailPoint Support [Get help](https://support.sailpoint.com/csm) with your SailPoint products by searching the knowledge base or contacting our Support team. # About Access History Access History helps organizations track the history of access for identity objects. This feature benefits: - Auditors who need to confirm that entitlements and access were provisioned or removed as expected - Managers who want to compare access of newly-hired employees against incumbents - Administrators who need to generate a report to document or prove how access stands on a specific date - Application owners who want to know how many identities have entitlements and how they were acquired Access History extracts data for identity and associated objects. If your needs are beyond that scope and you would like to learn about using Data Extract to code custom extracts for other objects or change data formats, see [About Data Extract](https://documentation.sailpoint.com/identityiq/9.0/help/system_administration/about_data_extract.html#about-data-extract). # How Access History Works History events related to Access History objects are constructed and published to the history writer API through a scheduled event or ad hoc service. You can configure how frequently Access History runs, but the default is once per day. The Dispatch Access History task determines the set of IdentityIQ objects to extract from IdentityIQ, which are those that haven't been captured previously or have changed significantly since the last time Access History was executed. Note The initial run of Dispatch Access History extracts all identity and related objects, and it can take a long time to execute. The following runs of Dispatch Access History are faster because only changed or new objects will be extracted and processed. Each extracted object describes all of the information about a single IdentityIQ access history object (e.g., identity, role, account, etc.). An extracted object can also reference other objects. The extracted objects are formatted into JSON and enqueued to the Access History writer service. The Dispatch Access History task processes the extracted JSON objects, persisting the information into the tables in the access history database used specifically by the Access History user interface (UI). Key point to remember: Each partition of the Dispatch Access History task periodically saves its progress within its work cycle. This allows another host to resume processing from the last saved state if the original host goes down. The mechanism **"restart at last state"** ensures that requests don’t need to start over after a crash or failure. The Access History UI lets you search the access history database. There are also APIs that the UI can use to query against the database, processing Identity, Role, Identity Entitlements, Certifications, Identity Requests, Managed Attributes, Capabilities, Accounts, Workgroups, and Policy Violations. The system identifies duplicates so they are not processed twice and can distinguish between initial events and change events. Unchanged objects are not processed. Access History is disabled by default to allow you to configure it. To use this functionality, you need to complete the following: - [Setting Up Access History Database and Tables](#setting-up-access-history-database-and-tables) - [Setting Up Access History Task](#setting-up-access-history-task) - [Scheduling the Access History Task](#scheduling-the-access-history-task) - [Configuring Access History](#configuring-access-history) - [Restrictions For Configuring the Access History Task](#restrictions-for-configuring-the-access-history-task) - [Troubleshooting Access History Task Failures](#troubleshooting-access-history-task-failures) - [Out of Sequence Events](#out-of-sequence-events) ## Setting Up Access History Database and Tables The database for storing Access History data is separate from the IdentityIQ database. The IdentityIQ install and upgrade scripts create separate databases for IdentityIQ and Access History data. The databases can be within the same instance for convenience, but separate database instances are recommended for production environments to avoid an impact on IdentityIQ performance. Depending on your environment setup and on the number of daily changes to your identities, the Access History database can be large, and will continue to grow. The separate IdentityIQ Access History database is required, even when the Access History feature is disabled or is not being used. See the *IdentityIQ Install Guide*. During the initial run, the Dispatch Access History task collects all necessary objects and populates the Access History database tables. This ensures that on a fresh install or upgrade, you start with a complete access history store. IdentityIQ Access History database includes the following tables: - spt_hist_account_capture - spt_hist_accounts - spt_hist_assigned_roles - spt_hist_capability - spt_hist_capability_capture - spt_hist_certification - spt_hist_cert_remediation_capture - spt_hist_detected_roles - spt_hist_entitlement_capture - spt_hist_entitlements - spt_hist_identity - spt_hist_identity_capture - spt_hist_identity_event - spt_hist_identity_req_capture - spt_hist_identity_req_item_capture - spt_hist_mattr - spt_hist_mattr_capture - spt_hist_mattr_event - spt_hist_object_config_capture - spt_hist_policy_violation_capture - spt_hist_policy_violation_remediation_bundle_ids - spt_hist_policy_violation_remediation_capture - spt_hist_policy_violation_remediation_entitlements - spt_hist_policy_violations - spt_hist_role - spt_hist_role_capture - spt_hist_role_event - spt_hist_workgroup - spt_hist_workgroup_capture - spt_hist_workgroup_event ## Setting Up Access History Task There is a preconfigured task named Dispatch Access History. This is a scheduled task that runs every day at midnight by default. Alternatively, you can create your own Access History task to run on your IdentityIQ instance: 1. Navigate to **Setup > Tasks**. 1. Select the **New Task dropdown** in the upper right corner. 1. From the dropdown list, select **Access History**. 1. On the New Task screen, enter a name for your task, and add any other optional field information you would like. 1. Under Access History Options, select **AccessHistoryExportConfig** from the dropdown. Note If you are setting up multiple Access History tasks with slightly different timings, you need to provide a unique YAML for each and input a unique name here for each task that you create. 1. Select **Save**, **Save & Execute**, **Cancel**, or **Refresh**. 1. Once the save button is selected, you can set the optional task arguments using the debug page like lossLimit, partition and other arguments. The default task arguments added are **The default task arguments added are** | Argument Name | Default | Description | | ----------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | lossLimit | 2500 | The state of Data Extract Partitions will be snapshotted to its RequestState object each time it processes an additional set of **lossLimit** objects. | | maxObjectAttempts | 5 | If an object fails to be extracted or published during a run of Access History or Data Extract, that is considered a failed attempt. The failed object will be processed again in subsequent runs of the task if it has failed less than **maxObjectAttempts** times. | | maxFailuresAbsolute | 500 | If more than **maxFailuresAbsolute** objects failed to be extracted or published during a run of the task, the task will be marked with an error, the NamedTimestamp date will not be altered, and the failed objects will not be saved. Thus, the next run will be a redo. | | maxFailuresPercent | 5 | If more than **maxFailuresPercent** percent objects failed to be extracted or published during a run of the task, the task will be marked with an error, the NamedTimestamp date will not be altered, and the failed objects will not be saved. Thus, the next run will be a redo. | | minExtractPartitions | 5 | A hint for the minimum number of data extract partitions to launch. This will be ignored (exceeded) if there are more than **maxObjectsPerPartition** * **minExtractPartitions** objects to process. | | maxExtractPartitions | 50 | A hint for the maximum number of data extract partitions to launch. This will be ignored (exceeded) if there are more than **maxObjectsPerPartition** * **maxExtractPartitions** objects to process. | | maxObjectsPerExtractPartition | 50000 | The maximum number of objects which will be delegated to a single data extract partition. | b. Executing the task looks at what objects are configured to be exported, applies the filter criteria and any limits that you have set and translates all of those objects into JSON documents and publishes them into the Access History database. c. If executed, review the Task Results, which display all the differences as well as the attribute statistics. See [Viewing Data Extract Task Results](https://documentation.sailpoint.com/identityiq/9.0/help/system_administration/about_data_extract.html#viewing-data-extract-task-results) **The results declared for the task are** | Result Label | Result Variable | Description | | ----------------------------------------- | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Number of Objects qualified for extract | totalObjectMessages | Count of the objects which were qualified for processing. This is the sum of totalModifiedObjectMessages and totalReattemptObjectMessages. Always shown. | | Number of Objects Qualified by Change | totalModifiedObjectMessages | Count of the modified objects which were qualified for processing. Only shown if totalReattemptObjectMessages > 0. | | Number of Objects Qualified by Re-attempt | totalReattemptObjectMessages | Count of the previously failed objects which were qualified for another re-attempt at processing in this run. Only shown if > 0 | | Number of Deletion Objects | totalDeletionExtractedObjects | Count of the rows in spt_intecepted_delete which were attempted to be published for this task. Shown if > 0. | | Deletion Objects Published | totalDeletionExtractedObjectsDispatched | Count of the rows in spt_intecepted_delete which were successfully published by this task. Shown if > 0. | | Number of Objects Processed | totalSeenObjects | Count of the objects which were processed (across all partitions). This does not imply whether or not they were successfully extracted and published -- only that a partition attempted to process it. Only shown if > 0 | | Number of Objects Unprocessed | totalUnseenObjects | If there any objects left unprocessed because one or more partitions were prematurely exited (e.g. due to too many failures), then totalObjectsUnseen is populated with the count of unprocessed objects. Only shown if > 0 | | Number of Objects Successfully Extracted | totalExtractedObjects | Count of the objects which were successfully extracted (across all partitions). Only shown if > 0. | | Number of Objects Not Found | totalExtractedObjectsNotFound | Count of the objects which were not found in the database during extraction (across all partitions). Only shown if > 0. | | Number of Objects that Failed to Extract | totalExtractedObjectsFailed | Count of the objects which encountered exceptions during extraction (across all partitions). Only shown if > 0. | | Number of Objects Successfully Published | totalExtractedObjectsPublished | Count of the objects which were successfully published (across all partitions). Only shown if > 0. | | Number of Objects that Failed to Publish | totalPublishingFails | Count of the objects which encountered exceptions during publishing (across all partitions). Only shown if > 0. | | Number of Abandoned Re-attempts | totalDroppedObjects | Count of the failed objects that have exceeded their re-attempt limit, and will not be attempted again. | ## Scheduling the Access History Task Schedule the Dispatch Access History task to run at a time or cadence you choose. See [Tasks Overview](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/index.html#tasks-overview) and [How to Schedule a Task](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/working_with_tasks.html#how-to-schedule-a-task). ## Configuring Access History The Access History Configuration page is available under **Global Settings** for users with the appropriate rights, Access History Admin. The page allows you to edit and save the decided options. 1. Navigate to the **gear > Global Settings > Access History Configuration** page, which includes Access History Controls. 1. Make sure the **Enable Access History** checkbox is selected. 1. Select **Save Changes** or **Cancel**. Additional configuration may be completed in the Debug page, where the following objects are available: - Configuration object "SystemConfiguration" - accessHistoryEnabled\ Set to True to enable Access History. - Configuration object "AccessHistoryConfiguration" - jsonFormat\ If set to PRETTY, JSON strings are stored in an easy-to-read format.\ If set to MINIFIED, JSON strings are stored in unformatted JSON with white space removed.\ If set to ZIPPED (default), JSON strings are compressed. - accessHistoryEnabled Set to True to enable Access History. - Configuration object "AccessHistoryConfiguration" - jsonFormat If set to PRETTY, JSON strings are stored in an easy-to-read format. If set to MINIFIED, JSON strings are stored in unformatted JSON with white space removed. If set to ZIPPED (default), JSON strings are compressed. Note Due to space considerations, it is advisable to leave jsonFormat set to ZIPPED, unless suggested by support for troubleshooting. - maxAllowedPatches A patch capture only captures the differences from the previous capture of the object. It is useful for saving space. If maxAllowedPatches > 0, patch document support is enabled. This property identifies the number of patch documents that can be saved between full captures, e.g., if the value is 2, every third capture will be a full capture. This pattern can change based on the config property captureMaxAgeInDays. - captureMaxAgeInDays If a patch document is older (in days) than the number specified in captureMaxAge, a full capture will be taken regardless of the number of patch documents. - maxAllowedPatches\ A patch capture only captures the differences from the previous capture of the object. It is useful for saving space.\ If maxAllowedPatches > 0, patch document support is enabled. This property identifies the number of patch documents that can be saved between full captures, e.g., if the value is 2, every third capture will be a full capture. This pattern can change based on the config property captureMaxAgeInDays. - captureMaxAgeInDays\ If a patch document is older (in days) than the number specified in captureMaxAge, a full capture will be taken regardless of the number of patch documents. A default Extract YAMLConfig is available for Access History. If you prefer to create a custom configuration, see [Configuring Data Extraction](https://documentation.sailpoint.com/identityiq/9.0/help/system_administration/about_data_extract.html#configuring-data-extraction). Note A severe performance problem can occur when optimizeFailoverEnabled is true, and your hostname resolves to an unreachable IP address. ### Restrictions For Configuring the Access History Task The Access History extract configuration must be maintained as a single, unified task. It **must not be divided** or implemented as multiple, separate tasks. Modifications to the extract are permitted **only within the YAML configuration file** `(YAMLConfig)`. Specifically: - You may **edit the YAMLConfig** to adjust the level of detail or scope of the extracted content (for example, to include or exclude specific data attributes). - However, the **defined object types** within the configuration **must not be removed, renamed, or restructured**. The existing object type definitions are mandatory and must remain intact to ensure compatibility and consistency across environments. ## Troubleshooting Access History Task Failures If the Access History feature is not enabled, the task completes but the Task Result has a status of Warning and a banner states, "The Access History feature must be enabled in order to support history events." - If the Access History feature is not enabled, the task completes but the Task Result has a status of Warning and a banner states, "The Access History feature must be enabled in order to support history events." - If the Extract YAML Config is missing the transform configuration name, the status indicates Fail and a banner states, "No transformation configuration name was found in the Export YAMLConfig." - If the Extract YAMLConfig has a bad value for the transform configuration name, or references one that does not exist, the status indicates Fail and a banner states, "Unable to find YAMLConfig AccessHistoryImageConfig2." - If the Extract YAMLConfig is missing a value for extracted objects, the status indicates Warning and a banner states, "The selected Export YAMLConfig is missing entry for exportedObjects." - If the Transform YAMLConfig has a bad value in the extracted objects list, the status indicates Warning and a banner states, "The Transform YAMLConfig is missing imageConfigDescriptor for exportedObject [object]." Note that other extracted objects with valid values will still be processed. - If the Transform YAMLConfig is missing an entry for one of the extracted objects, the status indicates Warning and a banner states, "The Transform YAMLConfig is missing ImageConfigDescriptor for importedObject Certification." - If the reading or processing of InterceptedDelete objects fails for any reason, the status indicates Warning and a banner states, “The row in the spt_intercepted_delete table remains in the database and will be retried during the next run. There is no limit to the number of attempts made for processing an InterceptedDelete row.” - If the Data Extract Processor for the xxxx partition encounters any failures while extracting or publishing objects, the status indicates Warning and a banner states, “The list of failed objects is written to the task's NamedTimestamp object.” - If the number of newly failed objects exceeds the defined thresholds (maxFailuresAbsolute or maxFailuresPercent), the status indicates Warning and a banner states, “The task will fail with an error, and the NamedTimestamp will not be updated (neither the date nor the list of failures).” - If the number of newly failed objects is below the threshold, the task will complete successfully. The status indicates Warning and a banner states, “The NamedTimestamp will be updated with both the date and the list of failed objects.” Note During the Extract Partition Creation execution, the list of failed objects (if any) are read from the NamedTimestamp object and are scheduled to be processed by the Data Extract Processors requests, along with any newly changed objects found in IIQ database. However, the number of re-attempts of a failed object is limited by the task argument maxObjectAttempts. When an object is attempted to be processed more than maxObjectAttempts time, it is discarded from the failure list in NamedTimestamp. ## Out of Sequence Events Sometimes messages arrive in Access History out of chronological order. This can happen if there is an error in processing that makes it need to be requeued or if there are multiple consumers and one somehow completes processing a newer message faster than another consumer completes processing an older message. When this happens, the system is set up to properly handle these messages by requeuing the messages in the correct chronological order. In cases where an image processor entity fails to be processed, the processor handler gives an exception error and the message is requeued for another attempt to be processed. You can configure the redelivery delay and maximum number of redelivery attempts. After the message exceeds the number of redelivery attempts, it is discarded and sent to the dead letter queue. See [Configuring Access History](#configuring-access-history). Occasionally, due to bad data, there is no way to process a message. In that case, it is discarded, logged in the discarded messages log file as INFO, and sent to a dead letter queue. To allow the timeline to show discarded messages, an optional event called DiscardedMessage can be enabled via the Debug page. The default value is false, but it can be enabled by setting the following Access History property to true: `` Access History defaults to allow you to audit removed event records. You may disable this functionality from the Audit Configuration page. These records may be created during out-of-sequence processing where a new capture is inserted between two existing captures. The events generated between the two existing captures must be removed and new events generated. See [Audit Configuration](https://documentation.sailpoint.com/identityiq/9.0/help/system_configuration/identityiq_global_settings/audit_configuration.html#audit-configuration). # Using the Access History UI To see the Access History UI, you need to have the SPRight `AccessHistoryViewIdentityHistory`. The `AccessHistoryExportIdentityHistory` right further allows export of the selected Access History data. 1. Navigate to **Identities > Identity Access History**. 1. Search for and / or select an identity from the Identity List. 1. The Identity List shows all identities by default. Use filters or search to narrow down the options. 1. Display name and email are both shown for each identity so that in cases where there are duplicate display names, you can more easily select the one you want. 1. Select a capture date. By default, the most recent capture is shown for the selected identity. 1. View details in the Access Items cards, by Accounts, Entitlements, or Roles, and on the event timeline, which lists individual events affecting the identity from the capture date backwards to the beginning of Access History data capture. 1. Select **View Profile** to view the identity attributes at the time of the capture. See [View Profile](#view-profile). 1. Select **Export** to export access items and / or events. See [Export Access History](#export-access-history). ## Using the Identity List Search and Filters Search allows you to find identities in the Access History database. When the search field and filter are blank, all identities are included in the identity list in alphabetical order. 1. Select the **filter icon** next to the search field to open the Identity Filters panel. 1. Filter By Identity, By Role, and / or By Entitlement. (Entitlement filter will include only Managed Attributes.) Combine filters to more easily find what you need. For example, you might choose to search by both Identity and Role. Note that filtering on permissions is not supported. 1. Select the dropdown arrows to select filter criteria options. 1. For **Identity**, select from attributes that have been configured for your implementation such as Manager, Is Manager (set the value to true or false), Is Active, and Identity Type. Note An identity is included in the filter results if the filter value has been true for that identity either now or at any time in the past since the beginning of Access History. 1. For Role and Entitlement, select from the three-way toggle to view **All** (all roles or entitlements the identity has ever had), **Current** (roles or entitlements that the identity currently has), or **Previous** (roles or entitlements that the identity previously had but does not have now). 1. For **Entitlements**, first select the application, then the attribute, then the value. 1. Select the **Apply** button to apply your selection(s) or the **Clear** button to clear values from the filter fields. You may also select **Cancel** to close the dialog without applying changes to the filters. Note If you have already applied filters, then reopen the filter dialog and make changes to those filters, Cancel will discard those changes but the existing filters will still apply. —OR— 1. In the **search** field, begin entering a name or email. 1. The search and filter capabilities are a "starts with" incremental search in which suggested values are filtered in real time as letters are entered. 1. Search by display name, first name, last name, or email. Select **X** to clear values from the search field. 1. If nothing matches the value you enter, the identity list is empty. Note Because a person's name may change over time, you may search using any of their names and it will bring up all results associated with that historical identity. For example, a person's name of origin and their married or changed name may both appear in a list, but selecting either one displays information for the same identity. 1. The Identity List displays all potential matches. At the bottom of the identity list, **Of Total** shows the total number of identities matching your entered criteria. Select **Show Next 20** to display more matches. 1. Select an identity to view its detailed information on the right side of the screen. Only one identity can be selected at a time. ## Selecting a Capture Date Choose a date on the calendar or timeline for the selected identity to view data about a specific identity capture. Use the timeline carousel to select an access change event. 1. Use the toggle above the timeline to scroll by month or day. 1. Use the capture selector or arrows to the right and left of the timeline to scroll chronologically backwards and forwards. 1. The capture selector above the Month / Day toggle navigates backwards and forwards one capture at a time. 1. The arrows to the right and left of the timeline scroll backwards or forwards one week when in Day mode or one year when in Month mode. 1. Select a date on the carousel to see information about a specific identity capture. 1. The filled blue dot indicates the day or month of the currently selected capture. 1. Empty circles indicate one or more captures on that day. Select the circle to see a list and select a specific capture. 1. Gray dots indicate that there was no identity capture on that day and the date may not be selected. Alternatively, you can use the date field or date picker to see an identity's state on a given date. 1. Enter a date in the date field or select the **calendar icon** on the upper right side of the timeline to open the date picker. 1. Select a date from the calendar. A dot under a calendar date indicates that there are captures for that date. 1. The selected date displays next to the calendar icon. 1. If there was an access change on the selected date, the latest capture data is shown. 1. If there was no access change on the selected date, a pop-up message states that no capture events occurred on this date and asks if you want to view the closest prior capture. 1. Select **Yes** to view information for the closest prior capture. 1. Select **No** to dismiss the pop-up message. When a date is selected either on the date carousel or using the date picker, the Access Items tiles and Event Timeline below update to show data for the selected identity on the selected date. A timestamp above the date carousel displays the capture date for the information displayed below. ## Access Items Tiles The Access Items panel displays tiles with the identity's counts of Total Access Items, Accounts, Entitlements, and Roles. Selecting the Accounts, Entitlements, or Roles tile displays a table with more information about items of that type. To close the detail table, select **Go back to event timeline**. Use the Search field above the Entitlements and Roles tables to search items in each table. Search results include matches in any column. To clear the search, select **Clear Search** next to the search field. For Entitlements, you can select the **Show only additional entitlements** checkbox to filter out entitlements that were gained because of role assignments. Table columns may be configured from the options below. Those marked with an asterisk are sortable. Accounts: - Application \* - Account ID \* - Status (Active/Locked/Disabled) Roles: - Name \* - Description - Classifications (multivalued – select the icon to see the classifications list) - Elevated access (Boolean) - Assigned by (identity) - Allowed by (role) - Acquired (assigned / detected) - Role type (business, IT, etc.) - Application (multivalued) - Account name (multivalued) Note Blue icons indicate elevated access. If a role has start and end dates with time, they appear here. Entitlements: - Attribute \* - Entitlement (value) - Classifications (multivalued) - Elevated access (Boolean) - Application \* - Account name Note Red triangle icons indicate that an entitlement has been disconnected. If an entitlement has start and end dates with time, they appear here. ## Event Timeline The event timeline lets you scroll through a reverse chronological list of all changes to access that occurred up to and including the selected capture date and time. There are also governance event cards for added or removed entitlements, roles, or identity attributes with additional information about what caused the access or identity attribute change. The cards also displays the start and end dates with time set during creating the access request for the role or entitlement. The most recent 20 events are displayed. Select the **Show Next 20** button to see more. List elements include: - **Event icon** - green + indicates add, red - indicates remove, blue gavel indicates governance events, and left / right arrows indicate an identity status change, identity attribute change, or account attribute change - **Event type** - types of events include: - Changed account - Added account - Removed account - Removed entitlement - Added entitlement - Removed detected role - Added detected role - Removed assigned role - Added assigned role - Changed identity - Changed identity status - Deleted identity - Discovered identity - Governance event - Access Request, Certification, or Policy Violation - Mitigated policy violation - **Event timestamp** - date and time the event was recorded in the Access History database - **Type-specific fields or details** - configure columns to select which type-specific fields you want to display ### Event Timeline Timestamp The timestamp on an event in the Events Timeline is the date that the Access History task was launched, which fetched the objects that led to event detection. It is not the date and time that the event occurred. Therefore, events in the Access History database may have a later event date and time than the time at which the access change occurred in IdentityIQ. See [Setting Up Access History Task](https://documentation.sailpoint.com/identityiq/9.0/help/access_history/how_access_history_works.html#setting-up-access-history-task). Note Not every object captured in the Access History database results in a new identity capture being created. Changes to objects in the IdentityIQ database other than identity objects - such as, for example, changes to existing Accounts, Roles, or Entitlements that affect the identity - do NOT trigger a new capture. However, when a new capture is triggered by a change to the Identity, such as an added or removed Entitlement or Role, or a change to an identity attribute, the events for changes to the non-identity objects will be included in that capture. Therefore, it is possible to retrieve the latest capture for an identity in Access History, and for there to be some related events (the ones that in and of themselves don't trigger a capture) that are not yet included because those events were recorded after the latest identity capture was created. This is a transitory situation, and no events will be lost. They will show up when the next identity capture is generated. It's also possible that even recent identity-related changes may not be included in the latest capture, if the Dispatch Access History task has not been run since they occurred. #### Filtering Events Select the **filter icon** at the upper right side of the event timeline to filter events by: - Access Items – Accounts, Entitlements, Roles - Use the three-way toggle to indicate whether you want to view All, Added, or Removed access items - Governance Events – Access Requests, Certifications, Policy Violations - Other Events – Identity Attribute Changes, Identity Status Changes, Account Attribute Changes Select the **Apply** button to apply your selection(s) or the **Clear** button to clear values from the search fields. You may also select **Cancel** to close the dialog without applying changes to the filters. Note If you have already applied filters, then reopen the filter dialog and make changes to those filters, Cancel will discard those changes but the existing filters will still apply. ## View Profile Select the **View Profile** button at the upper right side of the screen to see identity attributes for a selected identity as of the selected capture date, such as email, type, cost center, employee ID, department, job title, location, region, region owner, and location owner. If you want View Profile to include extended attributes that your organization has configured, be sure to specify these in the Object configuration. See [Configuring Data Extraction](https://documentation.sailpoint.com/identityiq/9.0/help/system_administration/about_data_extract.html#configuring-data-extraction). ## Export Access History Export Access History results to a CSV file for each type of item exported. The files are zipped together in a file whose name includes the identity name and date of the capture. 1. In Access History, select the identity for which you want to export information. 1. Select the **Export** button. 1. In the Create Export File window, select the Access Item types you would like to export – for example, Accounts, Entitlements, or Roles. Note The Search features in the Entitlement and Roles tables do not operate as filters for the Export feature. The entire table will be exported if the user requests an export, regardless of whether search has been used and the Entitlements or Roles table filtered. 1. Decide whether you want to also export the contents of the Event Timeline and select **Yes** or **No**. Note If you have filtered the Event Timeline, only the filtered events will be exported. A warning is provided, telling you how many events will be exported. 1. Select **Generate**. 1. A zip file with all of the exported CSV files can be found in your downloads. ## Running Access History from the IdentityIQ Console If you want to run the IdentityIQ console in standalone mode (without starting the application server) then use execute access history commands. ## Console Commands that Do Not Support Access History The following console commands do not support Access History objects: - checkin - delete - rollback - rename - import - lock - unlock # Advanced Analytics Overview Advanced Analytics lets you to create specific queries based on a variety of search criteria within IdentityIQ. These searches can be used to identify specific areas of risk, and to create populations of identities that can be saved and used as filtering criteria in other features. Search results can be saved for reuse, or saved as reports or populations. When you save a search as a report, you can schedule the search to run on an continuous basis, for monitoring and tracking purposes. When you save the search criteria as a population, you can use activity monitoring and statistical reporting of identities that fit that criteria in the same way that you use them for groups. To access Advanced Analytics from the navigation menu bar, select **Intelligence > Advanced Analytics**. Then choose a **Search Type** from the dropdown menu and enter the search criteria. IdentityIQ Advanced Analytics includes these search types: - [Identity Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/identity_search.html) – generate searches on specific attributes of the users in your enterprise. - [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html) – generate ad-hoc searches using Boolean operations. - [Access Review Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/access_review_search.html) – generate searches based on certification criteria. - [Role Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/role_search.html) – generate searches on the roles in your enterprise. - [Entitlement Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/entitlement_search.html) – generate searches on entitlements in your enterprise. - [Activity Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/activity_search.html) – generate searches on activity over specific time periods and on specific applications, identities, groups, populations or targets. - [Audit Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/audit_search.html) – generate searches for audit records for specific time periods and for specific actions, sources, and targets. - [Process Metrics Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/process_metrics_search.html) – generate searches based on business process metrics criteria. - [Access Requests Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/access_requests_search.html) – generate searches for current and archived access requests. - [Syslog Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/syslog_search.html) – generate searches for specific technical support related information that relates to your IdentityIQ installation. - [Account Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/account_search.html) – generate searches based on the accounts in your enterprise. These searches can find accounts by application, display name, owner, native identity, instance or any combination of these criteria. Many search types offer an [Advanced Search](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html) option that lets you create detailed, multilayered search filters. To view your search results, see [Search Results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html). # Access Requests Search Use the Access Requests Search page to generate searches on specific attributes of the access requests made in your enterprise. See [Access Requests Search Criteria](#access-requests-search-criteria). Search results can be saved as reports to reuse at a later time. When you save a search as a report, you can schedule the search on a continuous basis for monitoring and tracking purposes. See Report Use Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Field | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Access Requests Search Criteria Search results can be saved as reports to reuse at a later time. When you save a search as a report, you can schedule the search on a continuous basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports). The search fields are inclusive or "AND" type searches. Only actions matching values specified in all fields are included in the search results. To limit the search results, use search criteria. If you do not type information or make a selection in a search criteria field, all possible choices are included. For example, if you do not provide a type in the **Type** field, events with any action type are included. Specify the search criteria and columns to display and click **Run Search** to display the [search results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html). From the search results page, you can review the results of your search and save the search. The Access Request Search page has the following information: | | | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Criteria | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Search:** | | | Run Search | Run the search with the criteria displayed on the current page. If you modify the criteria of the Loaded Saved Search, the modified criteria is used for the search. | | Clear Search | Unload the Loaded Saved Search and clear all query options. | | Delete Search | Delete the specified Loaded Saved Query. | | **Access Request Attributes**: | | | Access Request ID | Identification number designated for individual requests. | | Requestor | Name of the identity that made the request. | | Requestee | Name of the identity for who made the request | | Is Verified | Attribute was verified through the provisioning process. | | Application | The application that is part of the access request. | | Instance | The instance of the application that is part of the access request. | | Operation | Type of operator used to fulfill request. For example, Add is an operation used in Request Roles and Lock is an action of a Certification. | | Completion Status | The current state of a completed access request. | | Priority | The priority assigned to the access request. | | Request Type | The type of business process associated with the access request. | | Approval State | The current state of the access request in the Approval phase. | | Provisioning State | The current state of the access request in the Provisioning phase. | | Reason | Indicates if an item was added (expanded) or filtered from the original request. For example, a role requires an entitlement or an entitlement requires and account. The compilation process adds or removes any required items in the provisioning process. | | State | The current state of the access request. | | **Filter by:** Date | | | Request Date | Use the dropdown list to select from Request Date, Completion Date, or Verified Date and select a Start Date and End Date. | | Fields to Display | Select the columns to display in your search results. | # Access Review Search Use the [Access Review Search](#access-review-search-criteria) page to generate searches for access review records. These searches can find access reviews by certifier, identity to be certified, access review type, access review phase, completion percentage, significant dates, tags, or any combination of criteria. Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Field | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Access Review Search Criteria The search criteria text fields support partial text strings using a starts-with protocol. For example, if you input "ro" in the Last Name field, the search results include Thomas Rowen and Betty Roberts. Your search criteria is used to narrow the search results. If you do not type information in a search criteria field, all possible choices are included. For example, if you do not select an application from the **Applications** list, all applications are included. Note If the Load Saved Search panel displays, the search criteria for that search is loaded on the page. To create a new search click **Clear Search**. The search fields are inclusive or "AND" type searches. Only actions matching values specified in all fields are included in the search results. For example, if you search by **First Name** John and **Last Name** Doe, the search results include only users with the character string John in their first name and Doe in their last name. Use the **Fields to Display** panel on the right to select the identity and risk fields to display on the search results page. Specify the search criteria and columns to display and click **Run Search** to display the search results. From the search results page, you can review the results of your search and save the search. See [Search Results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html#search-results). The Access Review Search page has the following information: | | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Criteria | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. These Saved Searches are only available for your use. To make searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of the current saved query. | | | Run Search | Run the search with the criteria displayed on the current page. If you have modified the criteria of the Loaded Saved Search, the modified criteria is used for the search. | | Unload the Loaded Saved Search and clear all query options. | Clear Search. | | Delete Search | Delete the specified Loaded Saved Query. | | **Access Review Attributes:** | | | Name | The name that you assigned to the access review when the access review was created. The search results include all access reviews that meet a specific criteria. The search is case-insensitive. You can type the entire name or a portion of the name. For example, you can type "mycert" to include that specific name or you can type "m" to include all access reviews that begin with the letter "m." | | Certifier | The identity or workgroup that is assigned the access review request. The search results include all access reviews assigned to the value specified. Select the arrow to the right of the suggestion field to display a list of all certifiers or type a few letters in the field to display a list of identities or workgroups that begin with that letter string. | | Identity | An identity in access review requests. The search results include all access reviews that have the specified identity. Select the arrow to the right of the suggestion field to display a list of all identities or type a few letters in the field to display a list of identities that begin with that letter string. | | Type | Select an access review type from the dropdown list. The access review type can display additional options to filter the search. | | Phase | Select an access review phase to limit the search. Review phases include Active, Challenge, Remediation, End. | | Percentage Complete | Limit the search results by a percentage complete. Type a percentage in the field to the right and set the operator, greater than or less than. | | Tags | Tags are assigned when access reviews are scheduled. You can use tags to classify access reviews for search and report purposes. The dropdown list has all the tags assigned to access reviews that you can access. | | **Filter By:** **The following fields are displayed based on the Type of access review selected in the Type field. If no type is specified, these fields are not displayed.** | | | Manager Attributes | Specify a manager to include in your search for access review requests. Select the arrow to the right of the suggestion field to display a list of all managers or type a few letters in the field to display a list of manager names that begin with that letter string. | | Group | Select a group or population to include in the search for access review requests. The search results include access reviews assigned to the group or population. To display the valid options, click the arrow to the right of the Group and Value fields. | | Application Attributes | Specify an application to search for access review requests. Select the arrow to the right of the suggestion field to display a list of all applications or type a few letters in the field to display a list of application names that begin with that letter string. | | Role Attributes | Specify a role to search for access review requests. Select the arrow to the right of the suggestion field to display a list of all roles or type a few letters in the field to display a list of role names that begin with that letter string. | | Account Group Attributes | Specify an account group and application to search for access review requests. Select the arrow to the right of the suggestion field to display a list of all account groups or applications or type a few letters in the field to display a list of account groups or applications that begin with that letter string. | | **Filter By: Date** | | | Date Type | Select an access review state for the dates specified. Review states include Created, Expiration, Signed or Finished. | | Start Date | Specify a date to begin this search. For example, if you selected a type of Create, the search results include any access reviews created on or after the specified date. | | End Date | Specify a date to end this search. For example, if you selected a type of Create, the search results include any access reviews created on or before the specified date. | | **Filter By: Signed Status** | | | Status | Specify access reviews by Signed or Unsigned status. Use the dropdown list to select **True or False**. | | E-Signed | Specify access reviews by Electronic Signature status. Use the dropdown list to select **True or False**. | | Signed By | Specify access reviews by the identity who signed off. | | **Fields to Display:** | | | Fields to Display | Specify the information displayed on the Access Review Search Results page associated with this search.The fields displayed change based on the type specified. Each field defines a column on the results table. You must select at least one field to display on the results page. | # Account Search Use the Account Search page to generate searches based on the accounts in your enterprise. These searches can find accounts by application, display name, owner, native identity, instance, or any combination of these criteria. See [Account Search Criteria](#account-search-criteria). When you save a search as a report, you can schedule the search on a continuous basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports). Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Field | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Account Search Criteria The search fields are inclusive or "AND" type searches. Only actions matching values specified in all fields are included in the search results. To limit the search results, use search criteria. If you do not type information or make a selection in a search criteria field, all possible choices are included. For example, if you do not provide an application in the Application field, all application’s accounts are included. Specify the search criteria and columns to display and click **Run Search** to display the [search results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html). From the search results page you can review the results of your search and save the search. The Account Search page has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Criteria | Description | | **Saved Searches:** | | | Search Name | The name of the past searches that you saved to reuse at a later time. These saved searches are only available for your use. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | | Run Search | Run the search with the criteria that is displayed on the current page. If you have modified the criteria of the Loaded Saved Search, the modified criteria are used for the search. | | Clear Search | Unload the Loaded Saved Search and clear all query options. | | Delete Search | Delete the specified Loaded Saved Query. | | **Account Attributes:** | | | Application | Select the application to include in the search for accounts. | | Display Name | Enter the Display name of account to include in the search. | | Owner | If you want to filter by owner, select the owner to search from the drop-down list. | | Instance | Select the instance to include in the search for accounts. | | Native Identity | Select the native identity to include in the search for accounts. | | Locked | Select **True** to search on only locked accounts or **False** to search on only unlocked accounts. If neither is specified, all accounts are included. | | Disabled | Select **True** to search on only disabled accounts or **False** to search on only enabled accounts. If neither is specified, all accounts are included. | | **Searchable Attributes:** | Select True or False to include or exclude Inactive Account, Service Account, and / or Privileged Account in your search. | | **Fields to Display:** | Specify the information displayed on the Account Search Results page associated with this search. Each field defines a column on the results table. You must select at least one field to display on the results page. | # Activity Search Use the Activity Search panel to generate searches for activity information on applications and targets, by specific identities and population, over specific time periods. These searches can determine risk areas and track activity on sensitive applications in your enterprise. See [Activity Search Criteria.](#activity-search-criteria) Search results can be saved as reports for reuse. When you save a search as a report, you can schedule the search on an on-going basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports). ## Activity Search Criteria The search fields are inclusive or "AND" type searches. Only actions matching values specified in all fields are included in the search results. To limit the search results, use search criteria. If you do not enter information or make a selection in a search criteria field, all possible choices are included. For example, if you do not select an application from the **Applications** list, all application configured to work with IdentityIQ are included. Specify the search criteria and columns to display and click **Run Search** to display the [search results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html). From the search results page, you can review the results of your search and save the search. The Activity Search tab has the following information: | | | | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Criteria | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved for reuse. These Saved Searches are only available for your use. To make searches available to IdentityIQ users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | | Run Search | Run the search with the criteria displayed on the current page. If you have modified the criteria of the Loaded Saved Search, the modified criteria is used for the search. | | Clear Search | Unload the Loaded Saved Search and clear all query options. | | Delete Search | Delete the specified Loaded Saved Query. | | **Activity Attributes:** | | | **Type of Time Span:** | | | Time Period | If you want to filter by **Time Period**, select one or more time periods from the list. The definition for each time period is specified when IdentityIQ is configured. | | Date of Activity | If you want to filter by **Date of Activity**, type the start and end dates for the search. **Start Date** -- include information on activity that occurred on or after this date in the search results. **End Date** -- include information on activity that occurred on or before this date in the search results. You can type the date manually or click the [...] icon to select a date from the calendar. | | **Actions:** | | | Action | The action that was performed. For example, login or create. Use the Shift and Ctrl keys to select multiple list items. Identities need to match only one of the selected items to be included in the search results. | | **Applications:** | | | Source Application | Select the applications to include in the search. If no applications are specified, all applications are included. Select the arrow to the right of the suggestion field to display a list of all applications or type a few letters in the field to display a list of applications that begin with that letter string. Identities need to match only one of the selected items to be included in the search results. | | **Type of Target:** | | | Category | If you want to filter by **Category**, select the category to search from the dropdown list. The **Category** dropdown has all of the activity target categories defined on the Activity Target Categories page. Activity Target Categories are groups of targets from one or more applications. | | Targets | If you want to filter by **Targets**, specify the target that was acted upon. For example, a machine name for a login or a file name for a create action. | | **Identities or Populations:** | | | Identities | The name of the user or workgroup that requested the action. Entering the first letter or letters, of a name displays a selection list of users or workgroups with names that have that letter string or click the arrow to the right of the field to display all names. | | Interesting Population | The population of identities to include in the search. The **Interesting Populations** dropdown list has the populations created based on the results of Identity Searches. The list has only the populations that you created or that their creator designated as public. | | **Activity Results:** | | | Result | The result of the action, **Failure** or **Success**. | | **Fields to Display:** | | | Activity Fields | Specify the information displayed on the Advanced Activity Search Results page.\\ | # Audit Search Use the Audit Search tab to generate searches for audit records for specific time periods and for specific actions, sources, and targets. These searches can find and track events. The information included in the audit logs is different than application activity because the events in the audit log are not associated with an application or data source and may not be associated with a specific identity. See [Audit Search Criteria](#audit-search-criteria). Before the audit logs collect any data to use in an audit search, IdentityIQ must be configured for auditing. Because collecting and storing event information in the audit logs can impact performance, a system administrator must specify the general actions and class actions to audit. Search results can be saved as reports to reuse at a later time. When you save a search as a report, you can schedule the search on an ongoing basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports). Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Field | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Audit Search Criteria The search fields are inclusive or "AND" type searches. Only actions matching values specified in all fields are included in the search results. To limit the search results, use search criteria. If you do not type information or make a selection in a search criteria field, all possible choices are included. For example, if you do not provide a type in the **Type** field, events with any action type are included. Specify the search criteria and columns to display and click **Run Search** to display the search results. From the search results page, you can review the results of your search and save the search. When you select an audit log event like `AccessRequestStart`, `ApproveLineItem`, or `RejectLineItem`, the **Audit Event Details** pop-up shows the event start and end dates with time along with other details. See [Search Results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html#search-results). The Audit Search tab has the following information: | | | | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Criteria | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. These Saved Searches are only available for your use. To make searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | | Run Search | Run the search with the criteria displayed on the current page. If you have modified the criteria of the Loaded Saved Search, the modified criteria is used for the search. | | Clear Search | Unload the Loaded Saved Search and clear all query options. | | Delete Search | Delete the specified Loaded Saved Query. | | **Audit Attributes:** | | | Action | The action that was performed, for example, login, delete or signoff. | | Source | The string that identifies the source of the event. The source is generally the name of an Identity object. The source can also be a less specific name such as, "scheduler" or "system." When the event occurs during an interactive session with the IdentityIQ Web application, identity names are used. When background tasks or anonymous requests are not run for a specific identity, abstract names are used. | | Application | Type manually or use the dropdown list to select an audited application. | | Instance | Type manually or use the dropdown list to select an instance of a specified audited application. | | Attribute Name | Type manually or use the dropdown list to select an audited attribute name. | | Attribute Value | Type manually or use the dropdown list to select a value of a specific audited attribute. | | Target | The object that was acted upon. For example, a machine name for a login or a file name for a create action. | | Account Name | Type manually or use the dropdown list to select an audited account name. | | **Filter by Date:** | | | Start Date | Include information on events that occurred on or after this date in the search results. You can type the date manually or click the **[...]** icon to select a date from the calendar. | | End Date | Include information on events that occurred on or before this date in the search results. You can type the date manually or click the **[...]** icon to select a date from the calendar. | | Fields to Display | Specify the information displayed on the Audit Search Results page associated with this search. Each field defines a column on the results table. You must select at least one field to display on the results page. | # Entitlement Search Use the Entitlement Search page to generate searches based on the entitlements or application object types in your enterprise. These searches can find application objects by attribute, owner, value, application, type, target, rights, annotation, or any combination of that criteria. See [Entitlement Search Criteria](#entitlement-search-criteria). Search results can be saved as reports for reuse. When you save a search as a report, you can schedule the search on a continuous basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports). Entitlement searches that are saved as identity searches are only available from the Identity Search page. If you save an entitlement search as an identity search, the filters are converted to work on identity pages. The new search results include the identities that are in associated with the application objects for the original search. Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Field | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Entitlement Search Criteria The search fields are inclusive or "AND" type searches. Only actions matching values specified in all fields are included in the search results. To limit the search results, use search criteria. If you do not type information or make a selection in a search criteria field, all possible choices are included. For example, if you do not provide a type in the **Type** field, all application object types are included. Specify the search criteria and columns to display and click **Run Search** to display the search results. From the search results page, you can review the results of your search and save the search. See [Search Results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html#search-results). The Entitlement Search page has the following information: | | | | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Criteria | Description | | **Saved Searches:** | | | Search Name | These Saved Searches are only available for your use. The names of past searches that you saved to reuse at a later time. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | | Run Search | If you have modified the criteria of the Loaded Saved Search, the modified criteria is used for the search. Run the search with the criteria that is displayed on the current page. | | Clear Search | Unload the Loaded Saved Search and clear all query options. | | Delete Search | Delete the specified Loaded Saved Query. | | **Account Group Attributes:** | | | Attribute | Type the name of an attribute to include in the search. | | Owner | Type the entitlement owner to include in the search. Select the arrow to the right of the suggestion field to display a list of all possible owners or type a few letters in the field to display a list of possible owners that begin with that letter string. | | Value | The value assigned to the attribute on an application. | | Application | Select the applications to include in the search for entitlements. If nothing is selected, all application are included. | | Type | Select the application object type to include in the search. If no application is specified all application object types from all applications are included in this list. If no application object types are specified, all are included in the search. | | Classification | Classifications can identify entitlements as potentially allowing access to sensitive, protected, or otherwise significant data. Choose any classifications to include in the search. | | Effective Access | Limit the search to the specific effective access list. Effective Access is any indirect access that was granted through another object. For example a nested group, an unstructured target, or another role. | | Elevated Access | Allows the results to be filtered for the Elevated Access attribute. | | Target | The specific target on an application to include in the search. Use the target filter to narrow the search results based on a specific application. | | Rights | The rights associated with an entitlement on the target attribute. For example, create, read, update, delete, execute. | | Annotation | The annotation field is an open field that you can use to add information to help describe permissions. | | **Searchable Attributes:** | The extensible entitlement attributes marked as searchable in the entitlements catalog. | | **Fields to Display:** | | | Fields to Display | Specify the information displayed on the Entitlement Search Results page associated with this search. Each field defines a column on the results table. You must select at least one field to display on the results page. | # Identity Search Generate searches on specific attributes of the identities in your enterprise. You can use these searches to identify specific risk areas, or to define populations of people from multiple organizations, departments, and locations. See [Identity Search Criteria](#identity-search-criteria). Search results can be saved for reuse or saved as reports. In some cases, you can save your results as populations of identities. - When you save a search as a report, you can schedule the search on an continuous basis for monitoring and tracking purposes. - When you save the search criteria as a population, you can use activity monitoring and statistical reporting of identities that fit that criteria in the same way that you use them for groups. Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html#using-advanced-search-options). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | Field | Description | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Identity Search Criteria The search criteria text fields support partial text strings using a starts-with protocol. For example, if you input "ro" in the Last Name field, the search results include Thomas Rowen and Betty Roberts. If you want to use a "contains" type of search, so that using "ro" in the Last Name field would include "Brown" as well as "Rowen" and "Roberts," use the Advanced Search option and choose "Is Like" for the search operator. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html#using-advanced-search-options). Your search criteria is used to narrow the search results. If you do not type information in a search criteria field, all possible choices are included. For example, if you do not select an application from the **Applications** list, all applications are included. Note If the Load Saved Search panel displays, the search criteria for that search is loaded on the page. To create a new search click **Clear Search**. The search fields are inclusive or "AND" type searches. Only actions matching values specified in all fields are included in the search results. For example, if you search by First Name **John** and Last Name **Doe**, the search results include only users with the character string John in their first name and Doe in their last name. Use the **Fields to Display** panel on the right to select the identity and risk fields to display on the search results page. Specify the search criteria and columns to display and click **Run Search** to display the search results. From the search results page, you can review the results of your search and save the search. See [Search Results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html#search-results). The Identity Search page has the following information: ### Identity Attributes | Criteria | Description | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Identity Attributes** | Identity attributes are pulled from the identity mapping information that is set during deployment and configuration. You can use full or partial strings in the text fields. Simple text searches use *starts with* logic; for example, "ro" in the Last Name field returns Roberts and Rowen. To search for results that *contain* the text string in the field, use the Advanced Search option and choose *is like* as the Search Type. | | **Searchable Attributes** | Searchable Attributes are attributes you created and that are designated as Searchable when an identity is generated during deployment and configuration. For example, Department, Organization, or Location. | | Last Name | Last name criteria to use in the query. | | First Name | First name criteria to use in the query. | | User Name | User name criteria to use in the query. | | Display Name | The identity name in IdentityIQ. | | Email | Email address criteria to use in the query. | | Manager | Manager criteria to use in the query.\\The Identity search results include all users that report to managers that match the criteria in this field. | | Is Inactive | Select **True** to include identities currently marked inactive or **False** to include identities that are currently active in the search results. | | Is Manager | Select **True** to include identities that are marked as manager or **False** to include identities that are not marked as manager in the search results. | | Type | Employee types include: Employee, Contractor, External Partner, RPA/Bots, Service Accounts | | Software Version | **Only applicable to RPA / Bots** Software version associated with the Robotic Process Automation (RPA) / bots. | | Administrator | **Only applicable to RPA / Bots** The administrator of the Robotic Process Automation (RPA) / bots. | | Applications | Select the applications to include in the search. If no applications are specified, all applications are included. Select the arrow to the right of the suggestion field to display a list of all applications or type a few letters in the field to display a list of applications that begin with that letter string. Identities need to match only one of the selected items to be included in the search results | | Detected Roles | Select the detected roles to include in the search. If no roles are specified, all roles are included. Select the arrow to the right of the suggestion field to display a list of all roles or type a few letters in the field to display a list of roles that begin with that letter string. For hierarchical roles, the identity is included in the search results with each role in the hierarchy not only the highest level role. | | Instance | The attribute that uniquely identifies a specific subdivision of an application. | | Assigned Roles | Select the assigned roles to include in the search. If no roles are specified, all roles are included. Select the arrow to the right of the suggestion field to display a list of all roles or type a few letters in the field to display a list of roles that begin with that letter string. For hierarchical roles, the identity is included in the search results with each role in the hierarchy not only the highest level role. | | Workgroup | Select the workgroups to include in the search. If no workgroups are specified, all workgroups are included. | | Include Assigned Role Hierarchy | Select to include roles that are inherited from the assigned roles you selected for your search. | ### Entitlements | Criteria | Description | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Entitlement Filters** | Select an application, attribute name and entitlement then click **Add** to filter by your selection. | | **Entitlement Metadata** | Filter your search to include identities with entitlements meet specific IdentityIQ-related criteria. | | Certification | **Has uncertified entitlements** -- use the dropdown list and select True or False to specify search results that include identities that have uncertified entitlements. **Has entitlements pending certification** -- use the dropdown list and select True or False to specify search results that include identities that have entitlements with pending certifications. | | Request | **Has entitlements that were not requested** -- use the dropdown list and select True or False to specify search results include identities with entitlements that were not requested. **Has pending requests for entitlements** -- use the dropdown list and select True or False to specify search results that include identities that have entitlements with pending access requests. | | Other | **Aggregation Status** -- specify if the search must include identities whose entitlements are associated with applications that are Connected or Disconnected for aggregation. **Is Assigned** -- use the dropdown list and select True or False to specify search results that include identities with entitlements were assigned and not detected. | ### Multi Valued Attributes | Criteria | Description | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Multi-Valued Attributes:** | By default, IdentityIQ does not come preconfigured with any multi-valued attributes. Multi-valued attributes are created during deployment and configuration. To limit the search, add values associated with a multi-valued attribute. The search results include the member list for the selected values. Use the and / or operator to define the search criteria. For example, for multi-valued identity attributes you can search by cost center or projects that have multiple values on multiple applications. For multi-value account attributes you can use group membership for specific accounts such as payroll or strategy and planning. | | Certification Score | The sum of compensated risk scores associated with certifications. | ### Risk Attributes Risk scores and compensating factors are defined when IdentityIQ is configured. | Criteria | Description | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Composite Score | The total composite risk score for the identity. | | Role Score | The sum of the compensated risk scores of each role assigned to this identity. To determine the compensated role risk score, compensating factors are applied to the role base risk score. | | Role Score (Base) | The sum of role base risk scores. This score does not account for the compensating factors defined for role risk scoring. | | Entitlement Score | The sum of the compensated risk scores of each entitlement assigned to this identity. To determine the compensated role risk score, compensating factors are applied to the entitlement base risk score. | | Entitlement Score (Base) | The sum of entitlement base risk scores. This score does not account for the compensating factors defined for entitlement risk scoring. | | Policy Score | The sum of compensated risk scores associated with policy violations as defined when IdentityIQ was configured. Policies do not affect identity risk scores until a violation occurs. | | Certification Score | The sum of compensated risk scores associated with certifications. | # Process Metrics Search Use the Process Metrics Search page to generate searches on the business process metrics in your enterprise. These searches provide visibility to the detailed metrics that monitored processes and process steps generate. These searches help administrators create, manage, and monitor the identity business processes in IdentityIQ. See [Process Metrics Search Criteria](#process-metrics-search-criteria). For example, you can determine the amount of time to run a defined business process and identity failures in the monitored steps of that process. Search results can be saved as reports to reuse at a later time. When you save a search as a report, you can schedule the search on a continuous basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports). ## Process Metrics Search Criteria Specify the search criteria and columns to display and click **Run Search** to display the [search results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html). From the search results page you can review the results of your search and save the search. See Search Results. The Process Metrics Search page has the following information: | Criteria | Description | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | Type the name or select a business process from the dropdown list. | | Participants | Select one or more participants to include in your search. | | Result Status | Select All, Success, or Fail from the dropdown list. | | Filter by Active Dates | Include a start or end date to limit your search results. Select the Start Date checkbox and select a date. Select the End Date checkbox and select a date. | | Filter by Execution Time | Use one of the following filtering methods to limit your search results based on the process run times: Average or Maximum -- select Average or Maximum to display the average or maximum of all execution times. Execution time greater than -- enter a minimum time unit as a baseline to start your search. Time Unit -- select from minutes, hours, or days. | # Role Search Use the Role Search page to generate searches based on the roles in your enterprise. These searches can find roles by name, owner, type, or status. You can also search for roles by the number of users to whom they are assigned, manually or through role assignment rules, the number of entitlements they contain, their risk score weight, their association to other roles, the last time they were assigned or certified, or any combination of that criteria. See [Role Search Criteria](#role-search-criteria). For example, you can identify roles that were created but are not being used by searching for setting **Detected Total** and **Assigned Total** to less than one (1). Note The Refresh Role Indexes task must have run at least once before a roles search will yield results. Search results can be saved as reports to reuse at a later time. When you save a search as a report, you can schedule the search on an ongoing basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports) Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See Using [Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Field | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Role Search Criteria The search fields are "AND" type searches. Only actions matching values specified in all fields are included in the search results. To limit the search results, use search criteria. If you do not enter any values in a search criteria field, all possible choices are included. For example, if you do not provide a type in the **Type** field, roles of any type are included. Specify the search criteria and columns to display and click **Run Search** to display the search results. From the [search results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html) page, you can review the results of your search and save the search. ### Role Attributes ***Name*** Enter a role name to include in the search. You can use full or partial strings in the text fields. Simple text searches use "starts with" logic. Entering a string of characters returns all roles with that string at the beginning of their name that your controlled scopes enable you to view. For example, if you enter "sys," the search results include information for the roles System Administrator, SysAdmin. To search for results that contain the text string anywhere in the field, use the Advanced Search option and choose **is like** as the Search Type. ***Display Name*** Enter a display name to include in the search. Entering a string of characters returns all roles with that string in their display name that your controlled scopes enable you to view. For example, if you enter "System Administrator," the search results include information for the display name System Administrator. ***Owner*** Enter the role owner to include in the search. Select the arrow to the right of the suggestion field to display a list of all role owners, or enter a few letters in the field to display a list of role owners that start with that letter string. ***Type*** Select the role type to include in your search. For example, IT, Organizational, or Business. Role types are defined for your enterprise during the role modeling process. ***Status*** Select the Enabled / Disabled status of the roles to include in the search. ***Classification*** Classifications can identify roles as potentially allowing access to sensitive, protected, or otherwise significant data. Choose any classifications to include in the search. ***Elevated Access*** When searching for a role or entitlement using Advanced Analytics, you can set the Elevated Access filter to True or False. ***Detected Total*** Specify an upper or lower limit for the number of identities that have this role detected that should be included in the search results. Detected roles are roles that are automatically assigned to identities based on the entitlements to which they have access. For example, to search for roles that were not detected by any identity during correlation, select **Less Than** from the dropdown list and type **1** in the empty field. The search results include all roles that were not automatically assigned to at least one identity. ***Assigned Total*** Specify an upper or lower limit for the number of identities that have this role assigned that should be included in the search results. Assigned roles are roles that were manually assigned to an identity by a user with role assignment authority or through a role assignment rule. For example, to search for roles that were not assigned to any identity, select **Less Than** from the dropdown list and type **1** in the empty field. The search results include all roles that were not manually assigned to at least one identity. ***Entitlement Total*** Specify an upper or lower limit for the number of entitlement a role can have. For example, if you select Less Than and type **3**, the search results include roles that contain two (2), one (1), or zero (0) entitlements. ***Risk Score Weight*** Specify an upper or lower limit for risk score weight assigned to a role for it to be included in the search results. For example, you can specify a Greater Than value to search for high-risk roles, or you can specify a Less Than value to search for roles that were created with a risk score weight that is too low for their type. In the second example, if your enterprise has a policy that requires that all IT-type roles have a risk score weight of 100, you can select IT from the **Type** dropdown list, select **Less Than** from the Risk Score Weight dropdown list, and type 100 in the empty field to return all IT-type roles with a risk score weight less than 100. ***Associated To Another Role*** Include roles that are associated with at least one other role or roles that are NOT associated with any other role. **True** – include roles that are associated with at least one other role. **False** – include roles that are NOT associated with any other roles. ***Effective Access*** Limit the search to the specific effective access list. Effective Access is any indirect access that was granted through another object, for example, a nested group, an unstructured target, or another role. ### Filter by: Profile A profile is a set of entitlements on a specific application. Options in this section let you search for roles based on profiles and on their relationship to other roles. ***Profile State*** Search for roles based on how entitlements and permissions are defined relative to the role(s). For example, you can use this criteria to search for all roles on an invalid application, or for roles with entitlements that are not defined (in other words, are missing) in IdentityIQ. Options are: - No Invalid/Missing Relationships - Invalid Applications or Missing Entitlements/Permissions - Missing Entitlements/Permissions Only - Invalid Applications Only ***Relationship to Role*** Search for roles based on how entitlements or permissions are defined, relative to the role(s). This filter can be used in conjunction with an application, or independently. For example, to search for roles that provide direct access to permissions on the Oasis_DB application, you would select the **Oasis_DB** application, select **Permissions** in the **Filter Type** field, and choose **Any direct relationships** here. To search for every role that allows indirect access to entitlements, regardless of the application, you would select **Any indirect relationships** here and choose **Entitlements** in the **Filter Type** field. Options are: - Any direct or indirect relationships: Show roles with any entitlement or permission relationships - Any direct relationships: Only show roles that have the entitlements or permissions directly on them - Any direct and selected indirection relationships: Show roles that have the entitlements / permissions directly on them, or a specific indirect relationship (such as inherited, permitted, or required). When you choose this option, you can enter additional criteria to filter on **Inheritance** and **Required/Permitted** relationships. - Any indirect relationships: Only show roles that have entitlements or permissions through a specific relationship, not on the role directly - Selected indirect relationships: Only show roles that have the entitlement or permission through a specific relationship, not on the role itself. When you choose this option, you can enter additional criteria to filter on **Inheritance** and **Required / Permitted** relationships. Note that some roles can grant both direct and indirect access to entitlements and permissions, so a role can potentially be returned by both the direct relationship and indirect relationship options. ***Application*** To filter roles by application, choose the application(s) here. Select the arrow to the right of the suggestion field to display a list of all applications, or enter a few letters in the field to display a list of applications that start with that letter string. ***Filter Type*** Choose whether to search for permissions or entitlements. Leave this field blank to search for both. OpenFilter by: Extended Attributes The extended attributes for roles are specific to your instance of IdentityIQ; they are defined under the gear icon > Global Settings > Role Configuration option. Any extended attributes defined for roles that are marked searchable appear here as search criteria. ### Filter by: Extended Attributes The extended attributes for roles are specific to your instance of IdentityIQ; they are defined under the **gear icon > Global Settings > Role Configuration** option. Any extended attributes defined for roles that are marked searchable appear here as search criteria. ### Filter By: Date ***Date Type*** Select a state to associate with the specified dates: - **Last Membership Certification** – the date when the last role membership certification was performed. - **Last Composition Certification** – the date when the last role composition certification was performed. - **Last Assigned** – the date when the role was last assigned to an identity. ***Start Date*** Specify a beginning date for this search. The search results include information pertaining to any action performed on or after the specified date. ***End Date*** Specify an end date for this search. The search results include information pertaining to any action performed on or before the specified date. ### Fields to Display Choose the information to display on the Role Search Results page associated with this search. Each field defines a column on the results table. You must select at least one field to display on the results page. ### Saving Searches Once you have run your search, you can save the results as a saved search or as a report. 1. In the **Search Results** page, click the **Result Options** dropdown and choose **Save Search** or **Save Search as Report**. 1. Enter a **Name** and **Description** for the saved search or report. 1. Select **Save**. Searches saved as reports are saved in the **Intelligence > Reports > My Reports** area of IdentityIQ. Searches saved as searches are listed in the **Saved Searches** section of the Role Search page. When you have saved searches, you can: - Click on the saved search in the **Search Name** area to see the saved search's description and to load the criteria for the search. - Clear any saved search criteria you have loaded by clicking the **Clear Search** button at the bottom of the page. - Delete the currently-selected saved search by clicking **Delete Search**. # Search Results The columns in the table are based on the **Fields to Display** list. From the results you can export your search results to file and save the search criteria for future use. Click **Refine Search** to return to the search criteria page. From Identity Search results you can use **Schedule Certification** to schedule certifications for any or all listed identities. Identity certifications are sent to the managers of identities that warrant special attention. These additional certifications do not replace regularly scheduled certification requests. ## Result Options Note Result Options are dependent on the search type. Use the **Result Options** dropdown list to: - **Save Search** – save the search for your own use. A list of saved searches displays at the top of the search page every time you log in. - **Save Search As Report** – searches saved as reports are added to your list of reports and can be scheduled to run on a continuous basis. - **Save Search As Identity Search** – searches that are saved as identity searches are only available from the Identity Search page. If you save an account group search as an identity search, the filters are converted to work on identity pages. The new search results include the identities that are associated with the entitlements from the original search. - **Save Identities as Population** – save the search as an interesting population of identities to use in activity monitoring and statistical reporting in similar way groups are used. - **Show Entitlements** – display the entitlement information for all of the identities included in the list. The entitlements are separated into tables based on applications. To display a list of all users who are assigned the entitlement, click a value in any of the tables. The Percent of Population column displays the number of identities assigned to the specified attribute value on the application. The search results are displayed as a percentage and are based on the identities that have an account on the application. ## Export Searches Use the buttons on the top of the table to export the search results to file for archiving and auditing purposes. You can export search results to a .pdf, Microsoft Excel, or ArcSight CEF Flat File format. # Syslog Search Use the Syslog Search page to generate searches on specific technical support information that relates to your IdentityIQ installation. See [Syslog Search Criteria](#syslog-search-criteria). Note This tab is used primarily to determine specific support information that SailPoint IdentityIQ support engineers can use for troubleshooting issues. Search results can be saved as reports to reuse at a later time. When you save a search as a report, you can schedule the search on a continuing basis for monitoring and tracking purposes. See [Report Use](https://documentation.sailpoint.com/identityiq/9.0/help/reports/index.html#introduction-to-reports). Use **Advanced Search** to create detailed, multi-layered filters to identify specific populations of users in your enterprise. To create complex queries into your Identity Cubes, you can create multiple filters and then group and layer them using And / Or operations. See [Using Advanced Search Options](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/using_advanced_search_options.html). When a previous search is saved to use later, the Saved Searches section displays at the top of the page. A saved search has the following information: | | | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Field | Description | | **Saved Searches:** | | | Search Name | The names of past searches that you saved to reuse at a later time. To view the search results page, click the name of the saved search to view the search results page. These Saved Searches are only available for your use. To make identity searches available to users with Report access, save the search as a report. | | **Loaded Saved Search:** | | | The name and description of your current saved query. | | ## Syslog Search Criteria Specify the search criteria and columns to display and click **Run Search** to display the search results. From the search results page you can review the results of your search and save the search. See [Search Results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html). The Syslog Search page has the following information: | | | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Criteria | Description | | **Current Search:** | | | Run Search | Run the search with the criteria displayed on the current page. | | Clear Search | Clear all query options. | | **Syslog Attributes**: | | | Incident Code | The ID associated with the logged exception. If the exception can be viewed in the UI, the ID is at the end of the message. The Incident Code assists help desk personnel to locate the exact exception. | | Server | Name of the server running the code where exception was encountered. This information is helpful in clustered environments. | | Level | Indicates the level of the logged exception. SailPoint supports logging WARN, ERROR, and FATAL to the IdentityIQ database. Lower levels are logged using log4j4 if configured, but are not saved to the Syslog table in the database. | | Username | User who was performing the action when the exception was encountered and logged. The username can be an individual user or a system. | | Classname | Class in which the exception was encountered. | | Message | The message included in the exception. | | Line | The line of code executed when exception occurred. | | Thread Name | The thread of code executed when the exception was encountered. | | **Filter** by Date: | | | Start Date | Include information on events that occurred on or after this date in the search results. You can type the date manually or click the **[...]** icon to select a date from the calendar. | | End Date | Include information on events that occurred on or before this date in the search results. You can type the date manually or click the **[...]** icon to select a date from the calendar. | | Fields to Display | Specify the information displayed on the Syslog Search Results page associated with this search. Each field defines a column on the results table. You must select at least one field to display on the results page. | # Using Advanced Search Options Most of the search types in Advanced Analytics include the option to create complex queries using multiple filters, with the Advanced Search feature. To create an Advanced Search, select the **Advanced Search** button. This opens the Advanced Search panel. Note Running a filter on more than one multi-value attribute with an OR condition generates a query that is unable to use the indexes and might impact performance. ## Creating an Advanced Search Creating an Advanced Search is a multi-step process: 1. In the **Add A Filter** section, select a **Field** and **Search Type**, then add a **Value**. For example, Manager equals john.smith. 1. Select **Add Filter** to add the criteria you just defined to the Advanced Search. 1. Repeat these steps as needed to add additional filtering criteria. 1. Optional: You can select and group individual filters, and choose AND or OR operators to determine how items are filtered. For more details, see [Grouping Filter Criteria](#grouping-filter-criteria). 1. After you enter the search criteria, select **Run Search**. The search results are displayed. ### Advanced Search criteria and fields: | | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Criteria | Description | | **Add A Filter:** | | | Field | A filter characteristic associated with the search type. The drop-down list has all of the categories available. | | Search Type | The qualifier associated with the attribute value. For example, "equals" or "is like." The choices in this dropdown list are based on the Field specified. | | Value | The value of the attribute. | | **Filter(s):** | | | Operations | The dropdown list that have the And / Or values that control the interaction of the filters included in the query. The dropdown list is not visible unless two or more filters are created. | | Group Selected | Group multiple filters in the Filters list to create layers or sub-filters in the query. | | Ungroup Selected | Ungroup grouped filters to edit the query. | | Remove Selected | Remove the selected filter or sub-filter. If you select grouped filters and click this button, all filters in the group are removed from the query. To remove one filter from a grouped bundle, you must first ungroup the filters. | | view/edit filter source | Open a text box that enables you to view and edit a string view of the query. If you type invalid query code the green check mark is replaced with a red exclamation point. | | **Fields to Display:** | Specify the information to display on the Search Results page. Each field defines a column on the results table. See [Search Results](https://documentation.sailpoint.com/identityiq/9.0/help/advanced_analytics/search_results.html#search-results). You must select at least one field to display on the results page. | ## Grouping Filter Criteria As you add filter criteria, you can select sets of criteria and use the **Group** and **Ungroup** options to link them, using AND or OR operators to determine how the filtering criteria is applied. This example shows how filters can be grouped. This filter will find identities that are either in the Accounting department and have a status of inactive, or are managed by aaron.nichols and have a status of inactive. ## Viewing and Editing the Filter Source Directly Click the **view/edit filter source** link to see the filter string created by the filter criteria you have set. You can edit this filter string directly. For more detailed information on working with filters and filter strings, see [Filters and Filter Strings](https://community.sailpoint.com/t5/Technical-White-Papers/Filters-and-Filter-Strings/ta-p/76012). # About SailPoint AI-Driven Identity Security SailPoint's AI-Driven Identity Security is a SaaS-delivered data analysis product designed to work with IdentityIQ and SailPoint Human Fabric. The goal of AI-Driven Identity Security is to improve your identity governance process through data analysis and machine learning. Integrating AI-Driven Identity Security with IdentityIQ helps your organization determine who should have access to what. AI-Driven Identity Security uses peer group analysis and identity attributes to recommend access to your users, and to help certifiers decide when user access should be approved or denied. AI-Driven Identity Security can also identify user access patterns to determine potential roles that accurately align with what users actually do in an organization. ## Decision Access Recommendations AI-Driven Identity Security can be configured to give decision access recommendations to the people performing access reviews and approving access requests. This can help them make more informed decisions about the access they are granting. For example, an access reviewer may not be entirely familiar with what item in the access review is. The AI-Driven Identity Security integration can provide access recommendations to display in IdentityIQ about whether the access should be granted or not. AI-Driven Identity Security can provide two types of access recommendations – a thumbs up indicating Recommended, or a thumbs down indicating Not Recommended – or not provide any recommendation at all. Users can also filter access recommendations by type, making it easy to review all items with the same recommendation status, together. Decision access recommendations can be enabled both globally, and at the individual certification level. See [Enabling Access Recommendations and Automatic Approvals Globally for Certifications](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/enabling_recs.html#enabling-access-recommendations-and-automatic-approvals-globally-for-certifications) for details on how to enable automatic approvals globally. ## Access Request Recommendations AI-Driven Identity Security can be configured to give access recommendations to people requesting access. With this option, users managing their own access are shown a set of access recommendations, based on information such as the user's manager, department, location, and colleagues. This can help reduce confusion on the user's part about what access to request, and save valuable time and effort in the request process. See [Enabling Recommendations for Access Requests](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/enabling_recs.html) for details on how to enable access request recommendations. ## Automatic Approvals You can use AI-Driven Identity Security to automatically approve access based on access recommendations. With this feature enabled, any access review item that has a recommendation of "thumbs up" is automatically moved from the reviewer's **Open** tab to the **Review** tab, with an "Approved" decision. Reviewers retain the option of changing the automated decision, as needed, before signing off on the review. Automated approvals help your reviewers process access reviews quickly and more efficiently by taking easy decisions out of the way so that they can focus on exceptional items. Automated approvals can be enabled both globally, and at the individual certification level. See [Enabling Access Recommendations and Automatic Approvals Globally for Certifications](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/enabling_recs.html#enabling-access-recommendations-and-automatic-approvals-globally-for-certifications) for details on how to enable automatic approvals globally. ## Access Modeling SailPoint's AI-Driven Identity Security includes an Access Modeling service which uses patented machine learning algorithms to identify user access patterns and determine potential roles that accurately align with what users actually do in an organization. In IdentityIQ, AI-Driven Identity Security Access Modeling gives you the option to use this service for role discovery, to display potential roles based on the optimal role granularity derived from AI-Driven Identity Security algorithms. The [Access Modeling](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/enabling_access_modeling.html) feature is part of your AI-Driven Identity Security integration. # AI-Driven Identity Security Reports and Console Commands ## AI-Driven Identity Security Reports AI-Driven Identity Security recommendation information is included in the following IdentityIQ reports. - [Access Review Decision Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/index.html#access-review-decision-report) – note that the Roles table for this report intentionally does not contain the recommendation columns - [Access Request Status Report](https://documentation.sailpoint.com/identityiq/9.0/help/lifecycle_manager/lifecycle_manager_reports.html#access-request-status-report) - [Advanced Access Review Live Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/index.html#advanced-access-review-live-report) - [Application Owner Access Review Live Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/index.html#application-owner-access-review-live-report) - [Certification Activity by Application Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/index.html#certification-activity-by-application-report) - [Manager Access Review Live Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/index.html#manager-access-review-live-report) - [Role Membership Access Review Live Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/index.html#role-membership-access-review-live-report) - [Targeted Access Review Live Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/index.html#targeted-access-review-live-report) - [Work Item Archive Report](https://documentation.sailpoint.com/identityiq/9.0/help/reports/iiq_std_reports/administration_reports.html#work-item-archive-report) The following columns are included in these access review and certification reports. In live reports, the columns function the same as the other IdentityIQ columns on the Report Layout tab. Note These columns are always blank on Policy Violation tables. Access recommendations are not evaluated for policy violations. - Recommended Decision - Recommendation Timestamp - Recommendation Reasons - Auto Decision Generated - Auto Decision Accepted For request types that are not supported by access recommendations, the reports return the following: - **Recommendation** – Not Consulted - **Recommendation Timestamp** – Blank - **Recommendation Reasons** – The recommender in use does not support recommendations for this work item type - **Auto Decision Generated** – False - **Auto Decision Accepted** – False If a recommendation is not found for a line item, the report returns the following: **Recommendation** – Not Found **Recommendation Reasons** – We do not have a recommendation for this access because the identity was not found within AI-Driven Identity Security **Recommendation Timestamp** – Blank **Auto Decision Generated** – False **Auto Decision Accepted** – False ## AI-Driven Identity Security IdentityIQ Console Commands You can use the IdentityIQ console to view the status of your recommender or to disable access recommendations for this IdentityIQ instance. These commands are available in the IdentityIQ console after `init-ai.xml` is imported: - **reco list** – a list of all recommender definitions and their status: In Use, Available, or Unavailable - **reco use \** – the name of the recommender to use. If the recommender name contains white spaces, put quotation marks around the name (“Recommender Name”) - **reco use --** – disable and clear the recommender selection For more information see [IdentityIQ Console](https://documentation.sailpoint.com/identityiq/9.0/help/iiq_console/index.html#identityiq-console). # Discovering Common Access The AI Access Modeling – Discover Common Access feature uses AI analytics and scoring methodologies to evaluate access for a given population, then presents a recommended role that includes the entitlements that are common across those identities. You can create and assign the common access role to large populations of employees to provide broad-based access from the first day an employee joins your organization. Once entitlements are labeled as part of a common access role, they are excluded from future access modeling role mining, role insights, and access request recommendations, which helps simplify your AI model. This feature is available to organizations using AI Access Modeling. You need the ManageIAICommonAccessDiscovery SPRight, which is part of the AIAccessModelingAdministrator and AIServicesAdministrator capabilities. Your system configuration needs to have AI enabled. See [About SailPoint AI-Driven Identity Security](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/index.html). Note Access Modeling, available prior to version 8.4 as an IdentityIQ plugin, may be part of your AI subscription as of version 8.4. You will no longer need to download a separate plugin, and you will no longer see it listed with your Installed Plugins. Note AI-Driven Identity Security modules may be licensed separately. Please direct questions to your account manager to clarify your agreement. ## Common Access Roles Discovery IdentityIQ Administrators can use this functionality to determine which access should be common to nearly all identities in an organization. Common access roles are not tied to specific job functions. Note Only roles created using Discover Common Access will be designated as common access in AI, and only these roles will have their entitlements excluded from future Access Modeling mining sessions. To discover a common access role: 1. Navigate to **Intelligence > Advanced Analytics**. 1. In the Search Type field, make sure **Identity** is selected. 1. Enter and apply search criteria. 1. Select the identity or identities to discover roles for. Note AI Access Modeling limits the number of identities to 25,000 per population to be mined. 1. Select the **Discover Common Access Roles** button. 1. You will be redirected to the Access Modeling page in Identity Security Cloud, using the URL that you configured in [Enabling Access Modeling](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/enabling_access_modeling.html). If you are not already logged in to Identity Security Cloud, you will have to enter admin credentials and authenticate. *AI displays the potential role.* Note Once you are in a role mining session, you can select the Settings button at the right side of the screen to adjust settings and use the granularity slider to adjust the minimum number of identities in a group. 1. The Potential Role page includes the following tabs: - On the Composition tab, use the slider to exclude entitlements beyond your chosen popularity threshold, then select **Apply**. - On the Exclusions tab, indicate exclusions. - On the Identity Overview tab, use the Show Chart dropdown to view the Identity Attributes. A list of identities shows those that would be included in this role, listed by display name, department, job title, and location. 1. Select the **Create a Role** button. Alternately, you may select **Save Draft** if it needs additional work. 1. On the Create a Role page, enter a name, owner, and description to create it. This role will be excluded from future Access Modeling role mining, role insights, and Access Request recommendations. Select the **Include Identities** checkbox to indicate that you want the identities listed in the Identity Overview tab to be included in the new role when it is created. 1. Select the **Create a Role** button. ## Specialized Roles Discovery Specialized Roles Discovery, part of Access Modeling, identifies user access patterns and determines potential roles, or bundles of access, that accurately align with what users actually do in an organization. IdentityIQ Administrators can use this functionality to generate roles for specific job functions, such as Accounting or Sales. To discover specialized roles: 1. Navigate to **Intelligence > Advanced Analytics**. 1. In the Search Type field, make sure **Identity** is selected. 1. Enter and apply search criteria. 1. Select the identity or identities to discover roles for. Note AI Access Modeling limits the number of identities to 25,000 per population to be mined. 1. Select the **Discover Specialized Roles** button. 1. You will be redirected to the Access Modeling page in Identity Security Cloud, using the URL that you configured in [Enabling Access Modeling](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/enabling_access_modeling.html). If you are not already logged in to Identity Security Cloud, you will have to enter admin credentials and authenticate. *AI displays a list of potential roles.* Note Once you are in a role mining session, you can select the **Settings** button at the right side of the screen to adjust settings and use the granularity slider to adjust the minimum number of identities in a group. 1. Select a role from the list. 1. The Potential Role page includes the following tabs: - On the Composition tab, use the slider to exclude entitlements beyond your chosen popularity threshold, then select **Apply**. - On the Exclusions tab, indicate exclusions. - On the Identity Overview tab, use the **Show Chart** dropdown to view the Identity Attributes. A list of identities shows those that would be included in this role, listed by display name, department, job title, and location. 1. Select the **Create a Role** button. Alternately, you may select **Save Draft** if it needs additional work. 1. On the Create a Role page, enter a name, owner, and description to create it. This role will be excluded from future Access Modeling role mining, role insights, and Access Request recommendations. 1. Select the **Include Identities** checkbox to indicate that you want the identities listed in the Identity Overview tab to be included in the new role when it is created. 1. Select the **Create a Role** button. # GenAI Descriptions for Entitlements IdentityIQ uses Generative AI (GenAI) to generate descriptions for your organization’s entitlements. On the Entitlement Catalog page, users can select one or more entitlements to request a generated description. The progress of these requests can be tracked on the GenAI Entitlement Descriptions page, which also allows users to submit new descriptions for approval. For each approval request: - Users can select either single or multiple entitlements to request descriptions. - Once generated, a description can be submitted. If approvals are enabled for GenAI Description for Entitlements, then they must be approved before the new description is applied to the entitlement. - A workflow determines who can approve the initial description that GenAI generates. Typically, this is the Entitlement Owner, but the feature can be configured to let users approve their own generated descriptions themselves. See: - [GenAI Entitlements on the Entitlement Catalog Page](#genai-entitlements-on-the-entitlement-catalog-page) - [GenAI Entitlement Descriptions Page](#genai-entitlement-descriptions-page) ## GenAI Entitlements on the Entitlement Catalog Page To access the Entitlement Catalog page, select **Applications > Entitlement Catalog**. See [Entitlement Catalog](https://documentation.sailpoint.com/identityiq/9.0/help/application_management/entitlement_catalog.html#entitlement-catalog) for details and functionalities on Entitlement Catalog page. In addition to the details and functionalities described in [Entitlement Catalog](https://documentation.sailpoint.com/identityiq/9.0/help/application_management/entitlement_catalog.html#entitlement-catalog), users with the AI Entitlement Description Administrator capability will see these options in the Entitlement Catalog table: - **Checkbox** in the Application column - **Magic Wand** icon in the Description column - **Review GenAI Descriptions** button Users with this capability can also generate GenAI Descriptions for Entitlements associated with applications on the page. See [Assigning GenAI Administrator Capability](#assigning-genai-administrator-capability) for more information on how to assign the AI Entitlement Description Administrator capability to a user. Use the checkbox to select a single Entitlement or multiple Entitlements, then right click and select **Generate Descriptions** to generate a request for generating GenAI Descriptions for Entitlements. A maximum of 100 entitlements can be selected in a single request. See [Generating GenAI Descriptions for Entitlements](#generating-genai-descriptions-for-entitlements) for more information. The Entitlement Catalog table displays a magic wand icon for entitlement descriptions generated through GenAI. The color of the magic wand represents its status in the workflow as follows: | Magic Wand Icon Color | Status | Description | | --------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Grey | Requested | GenAI Description for Entitlement has been requested but has not yet been created. | | Purple | Suggested | GenAI Description for Entitlement has successfully created. | | Red | Failed | GenAI Description for Entitlement was not created, due to an error. | | Yellow | Pending Approval | GenAI Description for Entitlement has been sent to an approver but has not yet been approved. | | Green | Approved | GenAI Description for Entitlement has been approved or provisioned without need for approval. | | Amber | Rejected | GenAI Description for Entitlement has not been approved, due to it not meeting the quality and accuracy standards of the approver. | Select the **Review GenAI Descriptions** button to navigate to the GenAI Entitlement Descriptions page. See [GenAI Entitlement Descriptions Page](#genai-entitlement-descriptions-page) for more information. ## GenAI Entitlement Descriptions Page Users with the AI Entitlement Description Administrator capability can access the GenAI Entitlement Descriptions page to monitor the request progress by selecting the **Review GenAI Descriptions** button on the Entitlement Catalog page. Users can also access this page directly via a URL: `https:///identityiq/define/groups/entitlementDescription.jsf#/genai.` The GenAI Entitlement Descriptions page provides a comprehensive overview of the suggested descriptions, status, and actions buttons. Users should refresh the page to see the progress of requests. The GenAI Entitlement Descriptions page displays a table with all relevant data associated with entitlements and descriptions generated using GenAI. | Column | Description | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Application | The application to which the managed attribute belongs. | | Display Name | Display the name of the managed attribute. If no display name was defined, this field displays the value of the attribute. | | Suggested Description | GenAI suggested entitlement descriptions. | | Creation Date | The creation date and actual time of the request to generate GenAI Descriptions for Entitlement. | | Status | Status of the request for generating GenAI Descriptions for Entitlement. The status can be Requested, Suggested, Failed, Pending Approval, Approved, or Rejected. | | Action | The action that users can take on the suggested descriptions under various statuses. Users can submit or discard a description. | The table data is displayed by the entitlement Creation Date in descending order, with the most recent entitlements created displayed first, independent of their status. Users can reposition (drag and drop) and sort the table columns as required. The page has both “full text” and “contains” type search functionality. The search includes all entitlements on all pages in the table, and the result count is displayed on the page. To configure which columns appear in the table, select the **column configure** icon. Users can perform the following actions on the page: - **Submit** – Submits the GenAI Descriptions for Entitlement to the workflow approver for approval. - **Discard** – Discards the GenAI Descriptions for Entitlement. This action will remove the entitlement descriptions from the table, but the user can resubmit the request. ## Generating GenAI Descriptions for Entitlements Users with the AI Entitlement Description Administrator capability can generate entitlement descriptions on the Entitlement Catalog page. They can generate descriptions for a single entitlement or multiple entitlements through a single request. They can generate descriptions for entitlements with and without existing descriptions. Currently, IdentityIQ supports GenAI Descriptions for Entitlement only in English, irrespective of the browser locale settings. ### Generating a Single Entitlement Description To generate a description for a single entitlement: 1. Select the checkbox and right-click on the table **OR** on the entitlement. A contextual menu is opened. 1. On the contextual menu, select **Generate Descriptions**. The GenAI Entitlement Descriptions page loads, including the additional selected entitlements. Note You cannot generate descriptions for entitlements that already have a GenAI description, or that have a status of Requested, Suggested or Pending Approval. ### Generating Multiple Entitlement Descriptions To generate descriptions for multiple entitlements through a single request: 1. On the Entitlement Catalog table, select the checkboxes for the entitlements. You can also select all entitlements on the page by selecting the header checkbox and selecting **Select Current Page** from the contextual menu. Note Once you have initiated a request for a description, the checkbox is disabled, except when the entitlement generation has failed or was approved or rejected by the approver. Note You can select a maximum of 100 entitlements in a single request to generate descriptions. If you try to select more than 100 entitlements, an error message will appear. 1. On the table, right-click in the selected area. A contextual menu display. 1. Select **Generate Descriptions**. The GenAI Entitlement Descriptions page loads, including the additional selected entitlements. Note When you select multiple entitlements, the Edit and Delete options on the contextual menu are disabled, because multiple edits and multiple deletes of entitlements are not allowed. ## Reviewing Generated Descriptions for Entitlements The GenAI Entitlement Descriptions page provides a comprehensive overview of the suggested descriptions, status, and actions buttons. The page shows the progress of the requests. ### Submitting an Entitlement Description Select **Submit** to submit the entitlement description, with Suggested status, for approval. An approval workflow (or whichever workflow is registered as the `workflowManagedAttribute` workflow) is launched, and the request is routed to the Entitlement approver for approval. If approvals are turned off via the **Enable approvals for GenAI Descriptions for Entitlements** checkbox, the descriptions will be auto approved once submitted. See [Configuring GenAI Descriptions for Entitlements](#configuring-genai-descriptions-for-entitlements) for details. Note The requester for the description can also be the approver. In this scenario, the entitlement description is instantly approved. See [Configuring GenAI Descriptions for Entitlements](#configuring-genai-descriptions-for-entitlements) for information on how to configure a requester as an approver. ### Discard an Entitlement Description If an entitlement description is incorrect, users can discard the entitlement descriptions with Failed, Suggested, and Rejected status. To discard an entitlement description, select **Discard** icon. It will remove the description from the GenAI Entitlement Descriptions page. Users can then select the entitlement again from the Entitlement Catalog page to generate a description, if they want. ### Entitlement Description Status Change When a user takes an action on the GenAI Entitlement Descriptions page, the entitlement description status changes as follows: No action = Suggested status Submit = Pending Approval status When the user sends the descriptions to the Entitlement approver, the status changes according to the approver’s action, or changes to Approved if approvals were auto-approved. See [Approving GenAI Entitlement Description](#approving-genai-descriptions-for-entitlements) for more information. ## Approving GenAI Descriptions for Entitlements As an Entitlement approver, you may be asked to review and approve a GenAI Descriptions for Entitlement. Entitlements are the access that an application can provide to an identity. Entitlement descriptions should provide useful information about the entitlement and its access. To ensure that a GenAI Descriptions for Entitlement is accurate, approval by the Entitlement approver is optionally required before the suggested description can be applied to the entitlement. If the Entitlement owner does not exist, the description is approved by the Application owner. When you need to approve an entitlement description, you will receive an email notifying you that it is ready for your review. 1. Select the **Approvals** Quicklink card to open the Approvals page, where you can view the GenAI-generated Descriptions for Entitlement received for approval.\ Alternatively, navigate to **My Tasks > Approvals** to open the Approvals page. 1. Review the proposed description. 1. Select **Approve** or **Deny**. When you approve a description, it is instantly updated on the entitlement. ### Entitlement Description Status Change When the Entitlement approver takes an action on the approval request for an entitlement description, the entitlement description status on the GenAI Entitlement Descriptions page changes as follows: No action = Pending Approval status Approve = Approved status Deny = Rejected status ## Assigning GenAI Administrator Capability The IdentityIQ administrator can assign the AI Entitlement Description Administrator capability to other users. The capability enables the users to generate GenAI Descriptions for Entitlements on the Entitlement Catalog page and review the descriptions on the GenAI Entitlement Descriptions page. To assign the capability to a user, perform the following: 1. Log in as an IdentityIQ administrator. 1. Navigate to **Identities > Identity Warehouse**. 1. On the Identity Warehouse page, search for the user you want to assign the **AI Entitlement Description Administrator** capability to. 1. Select the identity to open the View Identity page. 1. Select the **User Rights** tab. 1. Select **AI Entitlement Description Administrator** under User Capabilities. 1. Select **Save**. ## Configuring GenAI Descriptions for Entitlements IdentityIQ Administrator can activate the GenAI Descriptions for Entitlements feature in IdentityIQ. From the IdentityIQ gear icon, select **Global Settings > AI-Driven Identity Security Configuration**. Select the **Enable GenAI Descriptions for Entitlements** checkbox under the **GenAI Settings** section to see all the settings available in the section. 1. **Delete GenAI Descriptions for Entitlements requests older than (days)** – Deletes all stored requests for GenAI Descriptions for Entitlements older than the defined number of days with the statues; Requested, Suggested, Failed, Pending Approval, Approved, and Rejected. However, GenAI Descriptions for Entitlements that have been approved will still be applied to the entitlements. 1. **Enable approvals for GenAI Descriptions for Entitlements** – Enable workflow approvals for GenAI Descriptions for Entitlements. When this is enabled, GenAI Descriptions for Entitlements will follow established workflow approvals when they are submitted. Note If an Entitlement approval workflow has not been configured and the **Enable approvals for GenAI Descriptions for Entitlements** is selected, entitlement descriptions will be automatically approved when submitted through the GenAI Entitlement Descriptions page due to no approver existing. 1. Provide the following details under Connection Information for GenAI: a. **GenAI Hostname** – The API Gateway URL for your tenant. For example: `https://.api.identitynow.com` **OR** `https://.api.saas.sailpointfedramp.com`. b. **Client ID** – OAuth client ID for the GenAI API. c. **Client Secret** – OAuth client secret for the GenAI API. Note See [Generating Client Credentials in Your Tenant](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html#generating-client-credentials-in-your-tenant) to generate Client ID and Client Secret. 1. Provide the following details under Advance Connection Settings for GenAI: a. **Read Timeout** – The number of seconds IdentityIQ will wait to read GenAI Descriptions for Entitlements before reporting failure. b. **Connection Timeout** – The number of seconds IdentityIQ will wait to connect to GenAI LLM proxy before reporting a failure. 1. Select **Test Connection** to ensure that LLM APIs are being called to establish connection with the GenAI host. 1. Select **Save**. # Using Automatic Approvals You can use AI-Driven Identity Security to automatically approve access based on access recommendations. With this feature enabled, any access review item that has a recommendation of "thumbs up" is automatically moved from the reviewer's **Open** tab to the **Review** tab, with an "Approved" decision. Reviewers retain the option of changing the automated decision, as needed, before signing off on the review. Automated approvals help your reviewers process access reviews quickly and more efficiently by taking easy decisions out of the way so that they can focus on exceptional items. Automated approvals can be enabled both globally, and at the individual certification level. See [Enabling Access Recommendations and Automatic Approvals Globally for Certifications](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/enabling_recs.html#enabling-access-recommendations-and-automatic-approvals-globally-for-certifications) for details on how to enable automatic approvals globally. ## How Automatic Approvals Work The icon for Auto Approved Access Recommendations is the standard "thumbs up" icon, with a star. Any access review item that has a recommendation of "thumbs up" is automatically moved from the reviewer's **Open** tab to the **Review** tab, with an "Approved" decision. Reviewers retain the option of changing the automated decision, as needed, before signing off on the review. Users still have to sign off on automatically approved items in the **Review** tab. If the user reverses an automatic approval, the item is moved back to the user's **Open** tab for further review as needed. ### Finding Automatically Approved Items For quick viewing of all automatically approved items, you can filter the items in your Access Review: 1. In the Access Review, click **Filter**. 1. Click **Add Filter** and select **Auto Approved**. 1. Choose a value of **True** to find automatically approved items; you can choose **False** if you want to filter items to show those that are not automatically approved. 1. Click **Apply**. ## Reporting on Automatic Approvals You can include automated approval information in reports to help track and monitor items that have been automatically approved. To report on automatically-approved items: 1. Click **Intelligence > Reports**. 1. From the **Access Reviews and Certifications** reports section, choose a "live report" option for one of the certification types (Manager, Targeted, Application Owner, Advanced, or Role Membership) that supports automatic approvals. 1. In the **Report Layout** section, choose the columns related to automatic approvals that you want to display, such as: - Decision Maker - Decision Maker Comments - Recommendation - Recommendation Reasons - Recommendation Timestamp - Auto Decision Generated - Auto Decision Accepted # Integrating SailPoint AI-Driven Identity Security Note Plugins must be enabled in IdentityIQ for AI-Driven Identity Security to be installed. Ensure that `plugins.enabled=true` in the `identityiq_home/WEB-INF/classes/iiq.properties` file of your installation. ## Prerequisites for Integrating AI-Driven Identity Security Because SailPoint's AI-Driven Identity Security are a part of SailPoint Human Fabric, you will need a connection to a SailPoint Human Fabric tenant to integrate AI-Driven Identity Security with IdentityIQ. You can read about AI-Driven Identity Security prerequisites, the onboarding process, and deployment steps at [Getting Started with AI-Driven Identity Security for IdentityIQ](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html). ## Importing the AI-Driven Identity Security Integration File Begin your implementation of SailPoint AI-Driven Identity Security in IdentityIQ by importing the AI-Driven Identity Security `init-ai.xml` file into IdentityIQ: 1. Log in to IdentityIQ as an administrator. 1. Select the **gear** icon > **Global Settings > Import from File**. 1. Click **Browse** and browse to the following directory: `identityiq_home\WEB-INF\config` where *identityiq_home* is the directory in which you extracted the `identityiq.war` file during the IdentityIQ installation procedure. 1. Select the `init-ai.xml` file and click **Import**. 1. When the import is complete, click **Done**. This process enables AI-Driven Identity Security and installs the AI-Driven Identity Security Recommender Plugin into your IdentityIQ instance. ## AI-Driven Identity Security Limitations for Customizing Hibernate Files IdentityIQ allows you to customize extended and searchable attributes by editing various `.hbm.xml` files (such as `IdentityExtended.hbm.xml` or `LinkExtended.hbm.xml`) when IdentityIQ is installed and configured. The AI-Driven Identity Security feature requires that all the *default* values in IdentityIQ's `.hbm.xml` files are present. The AI-Driven Identity Security feature will not function properly if any default fields have been removed from any of the `.hbm.xml` files. Do not remove any default fields from the `.hbm.xml` files if you plan to implement the AI-Driven Identity Security integration. See the *IdentityIQ Installation Guide* for more details. # Monitoring and Disabling AI-Driven Identity Security ## Monitoring AI-Driven Identity Security Status You can use the SailPoint Modules and Extensions page of the Administrator Console to view the status of AI-Driven Identity Security. 1. Log in as an IdentityIQ administrator. 1. Under the **gear** icon select **Administrator Console**. 1. Click the **Environment** item in the menu bar on the left. 1. Click the **SailPoint Modules and Extensions** tab. 1. On this tab you can view the current status of the AI-Driven Identity Security connection, and can click on the module name to see the status of AI-Driven Identity Security connections for each host. ## Disabling AI-Driven Identity Security If you no longer want to use the AI-Driven Identity Security features, AI-Driven Identity Security can be disabled. 1. Log in as an IdentityIQ administrator. 1. Disable the AI-Driven Identity Security feature in the Debug pages: 1. Navigate to the Debug pages through the Debug URL: `https:///identityiq/debug` (for example, `http://localhost:8080/identityiq/debug`). 1. From the **Configuration Objects** dropdown list, choose **System Configuration**. 1. Locate the **identityAIEnabled key** and change the value from true to false: `` 1. **Save** your change to the System Configuration object. 1. Disable the AI-Driven Identity Security plugins: 1. Click the **gear icon > Plugins**. 1. Disable the **AI-Driven Identity Security Recommender Plugin** by clicking the power button icon to enable or disable plugins, and confirming your decision. # Configuring AI-Driven Identity Security Use the AI-Driven Identity Security Configuration page to connect IdentityIQ to AI-Driven Identity Security. From the **gear** icon, select **Global Settings > AI Configuration**. Note that the AI Configuration option does not appear in the Global Settings page until you have completed the steps in [Integrating SailPoint AI-Driven Identity Security](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/index.html). Note **Websphere and IBM JDK**: Connections to AI-Driven Identity Security using the IBM JDK require a JVM argument to support TLS version 1.2. If you deploy IdentityIQ on WebSphere, or other application servers using the IBM JDK, you must specify the JVM argument `-Dcom.ibm.jsse2.overrideDefaultTLS=true` for your Java process. To do this in WebSphere, add the JVM argument to the Generic JVM arguments at: **Servers > Java** and **Process Management > Process Definition > Java Virtual Machine > Generic JVM** arguments. For general information on getting started with AI-Driven Identity Security, see [Getting Started with AI-Driven Identity Security for IdentityIQ](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html). ## Connection Information for AI-Driven Identity Security ***AI-Driven Identity Security Hostname*** The host name of the AI-Driven Identity Security access recommendation API. For example, `https://.api.identitynow.com` ***Client ID*** OAuth client ID for the AI-Driven Identity Security access recommendation API. See [Generating Client Credentials in Your SailPoint Human Fabric Tenant](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html#generating-client-credentials-in-your-tenant) for details on how to generate this credential. ***Client Secret*** OAuth client secret for the AI-Driven Identity Security access recommendation API. See [Generating Client Credentials in Your SailPoint Human Fabric Tenant](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html#generating-client-credentials-in-your-tenant) for details on how to generate this credential. ## Advanced ***Read Timeout*** The number of seconds IdentityIQ will wait to read access recommendations from AI-Driven Identity Security before reporting a failure. ***Connect Timeout*** The number of seconds IdentityIQ will wait to connect to AI-Driven Identity Security before reporting a failure. ## Testing Your Connection Once your configuration details have been entered, you can click **Test Connection** to verify that the connection information is accurate and operating. If you are using an HTTP or HTTPS proxy for IdentityIQ's communications, and you want to make an exception for connecting to AI-Driven Identity Security, you can configure your AI-Driven Identity Security connection to bypass the proxy connection by adding this key to the **IdentityAIConfiguration** object: `` **Save** your settings before leaving the page. # Enabling Access Modeling SailPoint's AI-Driven Identity Security includes an Access Modeling service, which uses patented machine learning algorithms to identify user access patterns and determine potential roles that accurately align with what users actually do in an organization. In IdentityIQ, AI-Driven Identity Security Access Modeling gives you the option to use this service for role discovery, to display potential roles based on the optimal role granularity derived from AI-Driven Identity Security algorithms. The Access Modeling feature is part of the AI-Driven Identity Security integration. For more information, see [Configuring IdentityIQ for Access Modeling](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html#configuring-identityiq-for-access-modeling). Note AI-Driven Identity Security modules may be licensed separately. Please direct questions to your account manager to clarify your agreement. ## Prerequisites for Access Modeling To use Access Modeling for role discovery, AI-Driven Identity Security must be integrated into your IdentityIQ instance. See [Integrating SailPoint AI-Driven Identity Security](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/index.html) for details. You can read about AI-Driven Identity Security prerequisites, the onboarding process, and deployment steps at [Getting Started with AI-Driven Identity Security for IdentityIQ](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html). ## Configuring Access Modeling Discover Common Access Functionality Discover Common Access functionality is only available to organizations using IdentityIQ's AI functionality. Note Configuration settings automatically copy over for those running the AI-Driven Identity Security Access Modeling plugin prior to IdentityIQ version 8.4. Begin by enabling AI – see [Configuring AI-Driven Identity Security](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/integrating/configure_ai_identity_security.html) – then configure Discover Common Access and Role Discovery: 1. Log in to IdentityIQ as an administrator. 1. Navigate to **gear > Global Settings > AI-Driven Identity Security Configuration** and enter: - Connection information, including AI-Driven Identity Security Hostname, Client ID, and Client Secret. - Identity Security Cloud URL. This is specific to each customer. - Minimum number of identities on which to model roles. The default is 20. Note Selecting fewer identities on which to model roles yields more potential role options. Using a higher minimum number of identities avoids yielding many highly-specific roles. 1. Select **Save**. ## Using Access Modeling for Role Discovery in Advanced Analytics After the Access Modeling is enabled and configured, you can use it to explore potential roles based on users' current roles and create new roles that align with the access users need. See [Common Access Roles Discovery](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/discovering_common_access.html) and [Specialized Roles Discovery](https://documentation.sailpoint.com/identityiq/9.0/help/ai_driven_identity_security/discovering_common_access.html). # Enabling Automatic Approvals in Individual Certifications You can use automatic approvals in these types of certification: - Targeted - Manager - Application Owner - Advanced - Role Membership Important Exercise caution when staging certifications that have automatic approvals enabled. If you include a staging period with a certification that has automatic approvals enabled, then later disable either access recommendations or automatic approvals, items that were flagged for automatic approval during staging will lose the starred automatically-approved icon, but will remain approved and will still show initially on the reviewer's Review tab rather than the Open tab. To enable automatic approvals in **Targeted** certifications: 1. Click **Setup > Certifications**. 1. Click **New Certification > Targeted**. 1. In the **Additional Settings** section, click **Advanced Options**. 1. Select both the **Show Access Recommendations** and **Automatically Approve Recommended Items** boxes. 1. Set the rest of your certification parameters as needed and schedule the certification. To enable automatic approvals in all other supported certification types: 1. Click **Setup > Certifications**. 1. Click **New Certification** and choose one of the certification types that supports automatic approvals (Manager, Advanced, Role Membership, or Application Owner). 1. On the **Behavior** tab, select both the **Show Access Recommendations** and **Automatically Approve Recommended Items** boxes. 1. Set the rest of your certification parameters as needed and schedule the certification. # Enabling Recommendations Using AI ## Enabling Recommendations for Access Request Approvals Note This option is not available until init-ai.xml is imported into IdentityIQ and a connection to AI-Driven Identity Security is configured. AI-Driven Identity Security can make access recommendations for decisions on access requests. This feature must be enabled in your Lifecycle Manager settings, in order to generate access recommendations for access request approvals. 1. Log in as an IdentityIQ administrator. 1. Under the **gear** icon, select **Lifecycle Manager**. 1. In the **AI-Driven Identity Security Approval Recommendation** section of the Configure tab, check the **Enable the generation of AI-Driven Identity Security access recommendations on approvals** option. 1. **Save** your changes. After this option is enabled, your access reviewers can see decision access recommendations when they review access requests. See [Approving Access Requests](https://documentation.sailpoint.com/identityiq/9.0/help/lifecycle_manager/app_access_req.html#approving-access-requests) for more information. ## Enabling Recommendations for Access Requests Note This option is not available until `init-ai.xml` is imported into IdentityIQ and a connection to AI-Driven Identity Security is configured. IdentityIQ can make access recommendations for self-service requests for roles, using AI-Driven Identity Security. AI-Driven Identity Security uses peer group analysis, based on information such as the user's manager, department, location, and colleagues, to make access recommendations about what access a particular user should have. The access recommendations and the final decision are captured in reports, supplying important information about access decisions for auditors. This feature must be enabled in your Lifecycle Manager settings, in order to generate access recommendations for access requests. 1. Log in as an IdentityIQ administrator. 1. Under the **gear** icon, select **Lifecycle Manager**. 1. In the **AI-Driven Identity Security Approval Recommendation** section of the Configure tab, check the **Enable the generation of AI-Driven Identity Security Access recommendations on access requests** option. 1. **Save** your changes. After this option is enabled, your users have the option to see access recommendations when they request access. See [Requesting Access](https://documentation.sailpoint.com/identityiq/9.0/help/lifecycle_manager/manage_user_access/request_access.html) for more information. ## Enabling Access Recommendations and Automatic Approvals Globally for Certifications Note This option is not available until `init-ai.xml` is imported into IdentityIQ and a connection to AI-Driven Identity Security is configured. AI-Driven Identity Security can provide decision access recommendations during the access certification process, and can also make automatic approvals. Access recommendations and automatic approvals can be enabled globally for *all* applicable certification types, or can be enabled at the individual certification level. Note Items automatically marked as approved still require a reviewer's sign-off to complete the certification. Reviewers retain the option of changing the automated decision, as needed, before signing off on the review. ### To set a global default for all applicable certifications 1. Log in as an IdentityIQ administrator. 1. Under the **gear** icon select **Compliance Manager**. 1. In the **Decisions** section, check the **Show Access Recommendations** option. 1. If you want to automatically mark access review items as approved and move them from the Open to the Review tab of the access review, check the **Automatically Approve Recommended Items** option. When you enable automatic approvals, your reviewers will still have the opportunity to review and, if needed, change decisions before their final sign-off on the access review. 1. **Save** your changes. To change the default setting on an individual certification, refer to [Introduction to Certifications and Access Reviews](https://documentation.sailpoint.com/identityiq/9.0/help/certifications_and_access_reviews/index.html#introduction-to-certifications-and-access-reviews) for information on scheduling specific certification types. After this option is enabled, your certifiers can see decision access recommendations when they perform access reviews. # Sharing IdentityIQ Data with AI-Driven Identity Security IdentityIQ connects to AI-Driven Identity Security though a bespoke SailPoint Human Fabric tenant. Customers deploy an AI-Driven Identity Security Virtual Appliance for all communication, which requires configuration of a firewall to allow outbound HTTPS traffic. For more information on the SailPoint Human Fabric tenant and the AI-Driven Identity Security Virtual Appliance, see [Getting Started with AI-Driven Identity Security for IdentityIQ](https://documentation.sailpoint.com/saas/help/ai/iiq/iiq_ai_get_started.html). For each identity, customers can configure identity attributes collected during the provisioning of their tenant. All data movements are done via encrypted channels, via Amazon Kinesis Data Firehose, which encrypts data using AWS Key Management Service, and AWS SQS. ## IdentityIQ Data Collected for AI Select data, as configured by each individual organization, is gathered by the AI-Driven Identity Security Virtual Appliance and stored in both SailPoint Human Fabric and AI-Driven Identity Security repositories. All data movements are done via encrypted channels. Data, once transmitted, is stored according to the mechanisms of the final repository. These are the objects and the associated information that is collected from IdentityIQ and stored in the AI-Driven Identity Security repository: ### Application - ID - Name - Created - Modified - Extended attributes (as defined in the ObjectConfig attribute definitions) - Connector - Type - isAuthoritative - Features - Owner ### Bundle (Role) - Id - Name - Created - Modified - Type - Description - displayableName - Selector summary (getSelector().generateSummary() - roleTypeDefinition (used to determine if the role is assignable) - activationDate - deactivationDate - Owner - Profiles - Inheritance - Requirements - Permits ### Certification - Id - Name - Created - Modified - isComplete - Phase - isBulkReassignment - Cert definition (used to calculate the due date) - Signed date - Finished date - Expiration date - Tags - isElectronicallySigned - isProcessRevokesImmediately - Application - certificationGroups - Reviewers - Signer - Manager - Parent certification (if there is one) ### CertificationGroup - Id - Name - Created - Modified - Certification definition (used to find the cert type) - Status ### CertificationItem - Id - Name - Created - Modified - Use item type and Identity name (to calculate item name) - Type - summaryStatus - hasDifferences - Subtype - Completed date - Action object - action.approved - action.status - action.decisionDate - action.isBulkCertified - action.isRemediationCompleted - action.remediationAction - action.mitigationExpiration - Certification - Id (of the identity) - Actor - Certification definition (used to check showRecommnedations) - Recommendation - DataOwner - nativeIdentity - Instance - isAccountOnly - Application - Related Link objects - Managed attributes tied to the entitlement - Type of Bundle (bundle id) - Type of PolicyViolation - constraint name - policy name - status - mitigationExpiration - identity - revokedRoleIds - revokedEntitlementReferences ### Identity For the Identity object, a configurable list of identity attributes is collected. These additional attributes include details such as first name, last name, department, and other attributes. These attributes are at the customer's discretion and are configured during the provisioning of the customer's tenant. - Id - Name - Created - Modified - Attributes (certain attributes can be excluded) - Score - Links - Manager - assignedRoles - detectedRoles - Workgroups - IdentityEntitlement objects - policyViolations - Type - softwareVersion - Administrator ### For Workgroup Identities - Id - Name - Created - Modified - All attributes - Owner ### IdentityRequest Categorized as accessRequest, passwordRequest, identityChangeRequest, or identityRequest. - Id - Name - Created - Modified - Type - endDate - executionStatus - completitionStatus - Priority - requesterDisplayName - targetIdentity - Requester - affectedAccounts - affectedApplications - affectedBundles - affectedEntitlements - Items ### IdentityRequestItem - Id - Name - Created - Modified - Application - Instance - nativeIdentity - displayName - Name - Value - Annotation - Operation - Startdate - Enddate - isApproved - isRejected - provisioningState - compilationStatus - expansionCause - Retries - provisioningEngine - Owner - Approver - targetIdentity (to get affected accounts) - affectedApplications - affectedBundles - affectedEntitlements - Recommendation - Number of attachments ### Link For the Link object, a configurable list of identity attributes is collected. These additional attributes include details such as first name, last name, department, and other attributes. These attributes are at the customer's discretion and are configured during the provisioning of the customer's tenant. - Id - Name - Created - Modified - nativeIdentity - isDisabled - isLocked - Application - Attributes (certain attributes can be excluded) - Identity ### ManagedAttributes - Id - Name - Created - Modified - displayableName - Attribute - Value - Description - isAggregated - isRequestable - Owner - Application - Permissions ### PolicyViolation - Id - Name - Created - Modified - constraintName - policyName - Status - migrationExpiration - Identity - revokedRoleIds - revokedEntitlements ### Profile - Id - Name - Created - Modified - accountType - Owner - Application - Bundle - Managed attributes (for entitlement references) # About Applications and Connectors IdentityIQ uses configured applications to connect to your enterprise’s target systems and read data from those applications into IdentityIQ. This data is used for creating/updating Identity Cubes, building IdentityIQ’s entitlement catalog, and bringing information about users' accounts and group membership into IdentityIQ. Many, but not all, applications can also write information back to target systems, to reflect changes made within IdentityIQ. Although the terms "application" and "connector" sometimes seem to be used interchangeably, it's important to understand the differences: **Connectors** are how IdentityIQ provides the base functionality for communication with the target system. Connectors are in essence templates for connecting to target systems. They define how connectivity to the target system is accomplished, provide the ability to connect to a source, to read from and (in some cases) write to the source, and to create a normalized resource object representing the data read from the source. **Applications** are configured instances of connectors. They contain specific information for connecting to specific target systems, such as a unique name, connection parameters for connecting to a particular system, and a specific account schema. For example, you may need to aggregate data from several different delimited files. Using the delimited file connector, you can create many unique delimited file applications, each pointing to a particular file, and using a specific schema that defines the data to be aggregated from the file. ## Documentation for Specific Connectors This guide provides general concepts and common practices that apply to all connectors. For detailed information about a specific connector, refer to the corresponding SailPoint connector guide. Connector-specific guides include information such as supported features, connection parameters, account schema details, and other connector-specific configuration requirements. Connector documentation is available in the following formats: **Online connector documentation**: Documentation for the [current](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) version of each of the connectors supplied by SailPoint is available online on the [SailPoint documentation portal](https://documentation.sailpoint.com/#identityiq). **Offline connector documentation**: Connector guides can also be downloaded from [SailPoint Community](https://community.sailpoint.com/). Offline connector guides are updated with each IdentityIQ release. For connector documentation for previous IdentityIQ versions, see the *Supported Connectors for IdentityIQ* page on SailPoint Community and download the documentation ZIP file for your specific version. ### Additional Resources for Connectors These other SailPoint resources can be useful sources of additional information on connectors: [SailPoint Community](https://community.sailpoint.com/) – in SailPoint Community, you can engage with peers and experts to ask questions and share answers, submit ideas, read wiki articles and technical white papers, watch webinars, and more. SailPoint's [Customer Support knowledge base](https://support.sailpoint.com/csm?id=kb_view2) – you can search here for technical notes about specific connectors, from SailPoint's Customer Support team. # Activity Data Source Configuration Use the Activity Data Source Configuration page to add or edit activity data sources. Activity collectors access activity data sources such as event or audit logs, collect the activity information that is to be monitored, and transform that data into a format that can be read by IdentityIQ. These Activity Data Sources are use for all activity aggregation and reporting. Changes made on this page are not committed until a save is performed on the application with which they are associated. For example, if you add or delete a data source on this page and click **Save**, you do not see that change reflected on the application until you click **Save** on the application page and commit the change. For each activity data source enter or edit the following: - The general data source information in Activity Data Source Configuration. - Activity target information found on the Activity Target tab for each source type, see [Activity Targets](#activity-targets) - The unique connection and query setting for each activity data source type. - [JDBC Collector Settings](#jdbc-collector-settings) - [Windows Event Log Collector Settings](#windows-event-log-collector-settings) - [Log File Collector Settings](#log-file-collector-settings) - [RACF Audit Log Collector](#racf-audit-log-collector) - [CEF Log File](#cef-log-file) ## Activity Data Source Fields - **Name** - A short, descriptive name for the activity data source. - **Description** - A brief description of the activity data source. - **Transformation Rule** - The transformation rule required to convert the data collected from the data source into a format that can be used by IdentityIQ. Note Click the icon to launch the Rule Editor to make changes to your rules if needed. - **Correlation Rule** - The correlation rule that should be used to correlate the activity data collected with identities. Note Click the icon to launch the Rule Editor to make changes to your rules if needed. - **Activity Data Source Type** - The type of data source from which the activity is being collected. The **Activity Data Source Type** dropdown list contains the types of data source from which activity information can be collected. This list will grow and change to meet the needs of IdentityIQ users. Note When **CEF Log File** is selected from the dropdown list, the Transformation Rule and Correlation Rule fields are displayed with the following respective values: - Transformation Rule: CEFTransformRule - Correlation Rule: CEFActivityCorrelation ## Activity Targets The Activity Targets tab is used to specify targets within this data source for use in activity searches. A target is a specific object within a data source that is acted upon. For example, a target might be a machine name for a login action, or a file name for a create action. The targets specified here are used to populate lists on the Activity Search page. These targets can be grouped with targets specified on other applications to create categories of targets. For example, if you have inventory applications at three different locations and a procurement database on each, you can set each procurement database as a target, create a Procurement category, and then collect activity for all three procurement databases using a single activity search. On the Activity Targets tab you can add activity targets for the data source with which you are working. Type the name of the activity target in the field at the bottom of the list and click Add Activity Target. To remove activity targets, use the selection boxes on the left of the table and click Delete. ## JDBC Collector Settings Use these settings when using a JDBC collector. ### JDBC Connection Settings IdentityIQ uses the connection settings to access the activity data source. - **Connection User** - A valid JDBC user with access to the data source being accessed by this collector. - **Connection Password** - The password associated with the Connection User if a password is required. The password is encrypted and is not displayed with the activity data source information. - **Database URL** - The full URL to the activity data source. For example, `jdbc:mysql://localhost/db` - **JDBC Driver** - The driver class of the activity data source. For example, `com.mysql.jdbc.Driver` ### Query Settings The query settings are used to control the activity information that is collected when an Activity Aggregation task is run. - **SQL Statement** - The SQL statement used to query activity from the database. - **Condition Builder** - Transforms the data mapped in the rule selected as the Position Builder into a SQL statement used by subsequent queries to determine start position. - **Position Builder** - Rule that converts the last row in the result set returned by the query into a configuration map that is persisted into the IdentityIQ database. The data that is mapped in this rule is used by the condition builder to create a SQL statement used in future queries to determine the start location. This enables IdentityIQ to perform scheduled activity aggregations without having to scan entire data sets with each subsequent aggregation. ## Windows Event Log Collector Settings Note Before you can use the Windows Event Log Collector, the IQService must be installed and registered. See [Install and Register the IQService for Use with Windows](https://documentation.sailpoint.com/identityiq/help/installation/installregiqservice.html) for information on installing and registering the IQService. ### Event Log Settings SailPoint IdentityIQ uses the connection settings to access the activity data source and the query settings to control the activity information that is collected when an Activity Aggregation task is run. - **User** - Valid Windows user name with access to the event log containing the activity data. - **Password** - The password associated with the user specified. - **IQ Service Host** - The host name where the IQ service is running. - **IQ Service Port** - The listening port of the IQ service. - **Event Log Server** - The server where the activity data source resides. - **Query String** - The MQL query use to specify the activity data to collect during the activity aggregation. - **Block Size** - The number of events to retrieve with each activity aggregation performed on this activity data source. ## Log File Collector Settings ### Transport Settings The transportation settings are used to access the server where the log file containing the activity data resides. - **Transport Type** – depending on the transport type selected you will see the following: - **local** - If the log file containing the activity data is on the same server as IdentityIQ, no further connection-type information is required. - **ftp** - **FTP User** – a valid user name with authentication access to the FTP host. - **FTP Password** – the password associated with the FTP user. - **FTP Host** – the host where the log file resides. - **scp** - **SCP User** – a valid user name with authentication access to the SCP host. - **SCP Password** – the password associated with the SCP user. - **SCP Host** – the host where the log file resides. - **SCP Private Key** – the private key that is used to encrypt the collected data. ### Log File Settings The log file settings are used to define the query used to collect the activity data on. - **File Name** - The name of the log file containing the activity data. - **Lines to Skip** - The number of lines to skip before starting the scan for activity information. - **Filter Nulls** - Skip lines that don't conform to the defined format. - **Multi-lined Data** - A single record in this file spans multiple rows. - **Regular Expression** - A regular expression groups that can be used to tokenize each record in the file. ### Log Fields The log field settings are used to create the log fields based on the column headings in the log file. - **Name** - The name of the log field to create based on a column name from the log file. - **Trim Value** - Remove white space around the column name before creating the log field. - **Drop Nulls** - If the column by this name is null, ignore this record. For example, if the user field is null, then the record cannot be correlated to a IdentityIQ identity and, therefore, cannot be used by IdentityIQ. ## RACF Audit Log Collector ### Transport Settings The transportation settings are used to access the server where the log file containing the activity data resides. - **Transport Type** – depending on the transport type selected you will see the following: - **local** - If the log file containing the activity data is on the same server as IdentityIQ, no further connection-type information is required. - **ftp** - **FTP User** – a valid user name with authentication access to the FTP host. - **FTP Password** – the password associated with the FTP user. - **FTP Host** – the host where the log file resides. - **scp** - **SCP User** – a valid user name with authentication access to the SCP host. - **SCP Password** – the password associated with the SCP user. - **SCP Host** – the host where the log file resides. - **SCP Private Key** – the private key that is used to encrypt the collected data. ### Log File Settings The log file settings are used to define the query used to collect the activity data. - **File Name** - The name of the log file containing the activity data. - **Lines to Skip** - The number of lines to skip before starting the scan for activity information. - **Filter Nulls** - Skip lines that don't conform to the defined format. ## CEF Log File ### CEF Log File Transport Settings The transportation settings are used to access the server where the log file containing the activity data resides. - **Transport Type** – depending on the transport type selected you will see the following: - **local** - If the CEF log file containing the activity data is on the same server as IdentityIQ, no further connection-type information is required. - **ftp** - **FTP User** – a valid user name with authentication access to the FTP host. - **FTP Password** – the password associated with the FTP user. - **FTP Host** – the host where the log file resides. - **scp** - **SCP User** – a valid user name with authentication access to the SCP host. - **SCP Password** – the password associated with the SCP user. - **SCP Host** – the host where the log file resides. - **SCP Private Key** – the private key that is used to encrypt the collected data. ### CEF Log File Settings The log file settings are used to define the query used to collect the activity data. - **File Name** - The name of the CEF log file containing the activity data. - **Lines to Skip** - The number of lines to skip before starting the scan for activity information. - **Filter Nulls** - Skip lines that do not conform to the defined format. - **Multi-lined Data** - A single record in this file spans multiple rows. - **Regular Expression** - A regular expression groups that can be used to tokenize each record in the file. The format of CEF Log File. For example, (\\w\\w\\w\\s\\d\\d\\s\\d\\d:\\d\\d:\\d\\d)\\s(.*)CEF:(.*)|(.*)|(.*)|(.*)|(.*)|(.*)|(.*)|(.*)(.*) ### CEF Log Fields The log field settings are used to create the log fields based on the column headings in the log file. - **Name** - The name of the CEF log field to create based on a column name from the CEF log file. - **Trim Value** - Remove white space around the column name before creating the CEF log field. - **Drop Nulls** - If the column by this name is null, ignore this record. For example, if the user field is null, then the record cannot be correlated to a IdentityIQ identity and, therefore, cannot be used by IdentityIQ. IdentityIQ uses connectors to extract data and transform it into a format it can read. A connector is a Java class that extends the IdentityIQ AbstractConnector class and implements the IdentityIQ Connector interface. Connectors provide the means by which IdentityIQ communicates with targeted platforms, applications and systems. Each application type requires different information to create and maintain a connection. For detailed connector information refer to the connector documentation delivered with IdentityIQ. # Application Maintenance Windows Applications may need to be taken offline for maintenance at various points and for various reasons. You can set a maintenance window in IdentityIQ for any application; maintenance windows are timeframes you specify when an application offline. During a maintenance window, aggregation tasks and provisioning operations are suspended for the application until the maintenance window ends. ## Defining a Maintenance Window To set a maintenance window for an application: 1. Navigate to **Applications > Application Definition** and open the application you want to edit. 1. On the **Details** tab, check **Maintenance Enabled**. To set the timeframe for the maintenance window, you can either: - Set a specific date and time when the maintenance window should end and the application should return to online status. - Leave the expiration field blank to keep the application in maintenance mode until you are ready to bring it back online. In this case, you can return to the application definition to manually disable the **Maintenance Enabled** checkbox when the maintenance window is over. 1. **Save** your changes. ## Maintenance Windows and Aggregation During a maintenance window, IdentityIQ automatically skips the application when running aggregations. A warning message is recorded in the TaskResult for skipped applications. ## Maintenance Windows and Provisioning When an application is in a maintenance window, any provisioning operations (which might be launched by Identity Refresh tasks, certifications, LCM business processes, or custom business processes) are prevented from running for the application. A status of "retry" is automatically returned for any provisioning requests to the applications. In processes that are launched by a **business process**, the provisioning will use the standard "retry" behavior configured for the workflow, to attempt to provision again later. In **task-based** provisioning processes (such as an Identity Refresh task), retries are handled through Request objects that are created each time the process runs. These are automatically re-processed through the built-in Request Processor retry logic. For example, if you have an Identity Refresh task scheduled to run twice per day, and an application is in a maintenance window for 5 days, IdentityIQ will create 10 Request objects for that action. **Certification remediations** will also generate retry Request objects when the target application is in a maintenance window. If you want to change the retry behavior, you can do so in these ways: - It is possible, but not recommended, to modify business process retry behavior through the Provision with retries subprocess. Refer to [LCM Subprocess Workflows](https://community.sailpoint.com/t5/Technical-White-Papers/LCM-Subprocess-Workflows/ta-p/75856) for more information. - In the Identity Refresh task, you can select the *"Do not schedule retry requests during application maintenance windows"* option to prevent retries. - For certifications, there is not an option to turn retries off; certification remediations need to be set for retry, because certification cannot be simply "rerun" in the way that tasks and business processes can be. # Application Concepts Here are some general concepts you should be familiar with as part of planning your application onboarding and configuring your applications. ## Aggregation Aggregation is the process wherein information that resides on the target system is discovered and read in to IdentityIQ. The specific information that is brought into IdentityIQ through aggregation will vary depending on the type and purpose of the target system, what data is available in the target system, and how the application is configured. For example, when reading from a system of record such as a Human Resources system, you might want to aggregate a lot of information about each user, such as full name, department, job title, manager, and location. For a business-specific system such as an Accounts Payable system, you may aggregate only a limited set of information, such as which groups your users belong to, and which features each user has access to. While the details of what is aggregated is largely defined by your application configuration, the actual work of aggregation is accomplished by the **Account Aggregation** and **Account Group Aggregation** tasks. These tasks have many configuration options that allow you to fine-tune the behavior of the aggregation for each application. For more information, see: - Tasks Overview - Account Aggregation - Account Group Aggregation ## Correlation Correlation is the process of matching aggregated accounts to existing identities. When you aggregate from an authoritative source, IdentityIQ creates an Identity Cube for each account on that source. When you aggregate from a non-authoritative source, correlation logic helps match aggregated accounts to an authoritative Identity Cube. Correlation logic can be implemented several ways: - Through **direct mapping** of attributes – for example, the application's account attribute "mail" is mapped directly to the identity's attribute "email." Attribute mapping can be defined both in the application configuration feature and in the Rapid Setup feature. - Using **conditions** that assign application accounts to existing identities by defining attribute conditions. For example, the root account on Unix typically does not have any identifying attributes that can help when trying to correlate it to an existing identity using direct attribute mapping, so you can use a condition, such as whether the identity is a Unix application owner, to drive the correlation. Condition-based correlation can only be defined in the application configuration feature. The correlation configurations you define based on conditions can be saved and shared across multiple applications. - Through **rules** – custom BeanShell rules let you create your own specialized logic for correlation. Rules for account and manager correlation are specified in the **Rules** tab of the application. Rules can be built outside of IdentityIQ and imported as XML objects, or can be defined using the rule editor that can be opened in the application configuration Rules tab. For more information on working with rules, see [Rules and Scripts in IdentityIQ](https://documentation.sailpoint.com/identityiq/9.0/help/system_administration/rules_scripts.html). ### Resolving Uncorrelated Accounts The correlation logic you define in the application does not always successfully match newly-aggregated accounts to Identity Cubes. For example, accounts belonging to employees who are no longer part of your organization, or mismatched accounts that use variations on an employee's name, can result in accounts without a clear association to an existing identity. The **Identity Correlation** feature lets you manually correlate these accounts to specific identities. Manual correlations are permanently retained; IdentityIQ does not change these correlations during subsequent aggregations. If a manual correlation has been made in error, it can be changed in the Identity Warehouse on the relevant Identity Cube's **Application Account** tab. For more information, see [Identity Correlation](https://documentation.sailpoint.com/identityiq/9.0/help/identity_management/identity_correlation.html#identity-correlation). ## Provisioning Provisioning is the process of writing information (that is, the attributes and values you want to update) back to your target system, based on changes made within IdentityIQ. For example, an access request managed in IdentityIQ may create a new account for the user in a target system, or a policy violation may result in a user having certain access on the target system revoked. Provisioning propagates these changes to target systems, using a Provisioning Policy as the instruction or a template for what to include as part of provisioning; this includes the creation of new accounts when new access is granted on a target system where a user does not already have an account. Each application can have its own configurations that specify which attributes to include in provisioning, and how to set their values. You can configure distinct provisioning policies for different actions, such as creating accounts, updating accounts, and deleting accounts. Only some connectors support provisioning. For more information about specific connectors, refer to the [IdentityIQ Connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) documentation on SailPoint's documentation portal. For more information, see the [IdentityIQ Provisioning Guide](https://documentation.sailpoint.com/identityiq/9.0/help/provisioning/index.html). ## Attribute Synchronization Attribute synchronization is an automated process of pushing changes in identity attributes (such as name, email, or department) to target systems. These identity attribute changes often come from aggregation from an authoritative source, but they also might come from edits made to identities directly in IdentityIQ. Attribute synchronization is configured globally for IdentityIQ, in the **gear menu > Global Settings > Identity Mappings UI**. When you set your identity mappings, you will select which configured application(s) are updated, and which attributes (defined in the configured application schema) store the values to be synchronized. When an attribute change comes through aggregation, attribute synchronization is initiated through a refresh task that has the Synchronize Attributes option selected. See the Identity Refresh task for information about configuring and running this task. For more information, see [Attribute Synchronization](https://documentation.sailpoint.com/identityiq/9.0/help/provisioning/attribute_synchronization.html#attribute-synchronization). ## Rapid Setup Rapid Setup provides an alternative way of defining application behavior and the events and processes for managing identities, in user-friendly, guided UI. Rapid Setup lets you separate the technical and IT-centric steps of onboarding and configuring applications (such as defining connection parameters and schemas) from the business-centric steps of defining the business processes the application should follow (such as how to onboard applications and handle common identity management scenarios such as joiner, mover, leaver, and terminating identities). It provides preconfigured processes that follow best practices for managing identities. Rapid Setup also provides a simple UI for defining attribute-based account and manager correlation. For more information, see [Rapid Setup](https://documentation.sailpoint.com/identityiq/9.0/help/rapid_setup/index.html). # Editing an Application's Configuration in the Application XML The majority of the options you will use to create and configure an application are available in IdentityIQ's UI. Each configured application is stored in IdentityIQ as an application object. These objects can be viewed in the Debug pages, and they can be exported for modification and testing, then imported to implement these changes in your production environment. Only users with system administrator or similar elevated rights in IdentityIQ have access to the Debug pages. In some limited cases, specific behaviors for certain connectors can only be configured by editing the application's XML. Where these occur, they are described in the specific connector guides. For more information about specific connectors, refer to the [IdentityIQ Connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/) documentation on SailPoint's documentation portal. Important Use caution when editing application objects in the Debug pages, as **there is no mechanism in the Debug pages for rolling back changes once they have been saved**. It is a best practice to export the application object, edit the XML outside of IdentityIQ, and then import the updated object to a test environment for validation before importing into your production instance. This also allows you to manage your application changes in a source control system, to facilitate rollback.\ For modifying a single application, the iiq console **checkout** command is preferable to the **export** command, because **checkout** lets you write a copy of a single object, whereas **export** will write all objects of the class you specify. For more information, see [IdentityIQ Console](https://documentation.sailpoint.com/identityiq/9.0/help/iiq_console/index.html#identityiq-console). Only users with **system administrator** or similar elevated rights in IdentityIQ have access to the Debug pages. To access an application object in the Debug pages: 1. In the IdentityIQ menu, select the **wrench icon > Object**. 1. In the Object Browser, select the **Application** object. 1. The configured applications are listed alphabetically. Scroll or use the search box to locate the application object. 1. Double-click the object to open the application XML. # File Access Manager Applications File Access Manager enables enterprises to discover and govern access to sensitive data and better address the security threat to unstructured data. As a key component of SailPoint's Identity Governance strategy organizations can take a comprehensive approach to govern access across all users, applications and data with enhanced visibility while reducing risk. Use File Access Manager to: - Identify and govern access to exposed sensitive data found within cloud and on-premises file stores. - Enable business users to manage access to data they know best, alleviating IT burden and over-permissioned access. - Leverage a comprehensive identity governance solution that extends to unstructured data throughout the enterprise. When you create a new application of type File Access Manager, this application by default will start with an alert schema, as well as unstructured and associations schemas. The unstructured and associations schemas are used to define the makeup the Target and TargetAssociation respectively. For more information, you can also refer to the [File Access Manager documentation](https://documentation.sailpoint.com/file_access_manager/help/). ## File Access Manager Attributes/Configuration Schemas are defined on the Configuration tab. If an alert schema is defined, this will include the configuration needed to set up the Alerts. If the Unstructured schema is defined, this will include the configuration needed to set up the Target / Target Permissions. ### Connection Settings - **Database URL** - the jdbc connection URL for the File Access Manager database. - **Driver Class** - the SQLServer JDBC Driver class to use for the connection. This should be the appropriate jar for the version of SQLServer you are using with File Access Manager. It must be contained in the corresponding jdbc SQLServer jar file, and located in your IdentityIQ installation's`\lib` directory. - **UserName** - the database user name - **Password** - password for the configured user name - **Schema** - schema used for the File Access Manager database ### General Settings - **Referenced Applications** - This is a list of applications to which the given permission are correlated. The target permissions are correlated to either a Link or ManagedAttribute belonging to one of the applications in the list. - **Aggregate Inherited** - True to aggregate inherited permissions. If set to true, the dataset will be much larger. If false, only the top level permissions are aggregated, and inheritance is assumed as defined on the native source. - **Target Hosts** - The File Access Manager Business Application Monitors (BAMs) from which to aggregate permissions. - **Target Host Paths** - This is a CSV of paths from which to aggregate. This aggregation starts at the given root paths, and discovers all permissions under these paths. If not specified, all target / target permissions for the specified BAM are aggregated. ### Rules The rules tab within the Application Definition user interface enables the defining of rules for given object types. The Application level rules and schema level rules, for schemas that allow them, are shown with the ability to select / edit (based off of correct capabilities) the given rules. The unstructured schema support Correlation/Creation/Customization/Refresh rules on the schema level. Creation rules for unstructured schema will be of **Rule Type** TargetCreation Refresh rules for unstructured schema will be of **Rule Type** TargetRefresh Correlation rules for unstructured schema will be of **Rule Type** TargetCorrelation Note Customization rules might run multiple times, updating the same ResourceObject. For example, once for the provisioning result, once for the result in the provisioning plan, and once for the result in the account request. Customization rules for unstructured schema will be of **Rule Type** ResourceObjectCustomization The unstructured / associations schema AttributeDefinitions are used to define the columns to include in the query. # Native Change Detection Configuration Native change detection is a mechanism in IdentityIQ's application connectors that can detect changes made in account information outside of IdentityIQ's control. The native change detection can detect newly created accounts, deleted accounts, or modified accounts. The changes are detected on aggregation by comparing stored information with newly read information. If any changes are detected, actions can be taken to respond to these changes. These actions include automatic recertification, approval, notifications or even automatically reverting the changes. Native change detection is enabled **on each application separately**. Once enabled, aggregation will start detecting changes (while filtering SailPoint requested items) and storing them with other Lifecycle Events on the identity. If you make native changes you will see them being stored on the Identity object. Note For Native Change Detection to operate you must have both a lifecycle event defined and the application enabled. To configure IdentityIQ to detect native changes during aggregation, do the following: 1. Run an aggregation to obtain the baseline information for the application. 1. Configure a Native Change life cycle event on the Lifecycle Events page. There are two lifecycle change events included with IdentityIQ and you can configure your own as needed: **Lifecycle Event -- Email manager for all native changes** - Sends a formatted email to the manager describing the changes detected. **Lifecycle Event -- Manager Approval for all native changes** - Generates an approval work item for each change detected. Any items rejected are undone / reversed and provisioned. This business process also creates an access request within IdentityIQ so that once the changes are made they will be visible from the Access Request page. 1. Go to **Applications > Application Definition** and select an application. 1. Enable **Native Change Detection** on the Details panel of the application configuration UI. 1. Define the operations to include when detecting native changes -- **Create**, **Modify**, **Delete**. 1. Define the attributes to compare when detecting native changes: Entitlements: All entitlement attributes User Defined: Manually enter the names of the attributes to compare, one per line 1. Run or schedule aggregations to detect and store any changes. 1. Run an Identity Refresh task with the Process Events option enabled to trigger the lifecycle events for any changes detected since the last time the events were processed. # Reconfiguring an Application The application reconfiguration option enables you to change the application type without losing history associated with the application or having to create a new application. For example, if you first deployed your instance of IdentityIQ using a flat file connection, but now want to use some of the more advance features, such as provisioning. The type defines the way in which IdentityIQ connects to the application. Application types that have the same value format for identity and group attributes in the original and reconfigure target are best suited for reconfiguration. The following application types can be reconfigured: Note Even in the following scenarios, there might be some connectors that do not re-configure correctly. See [Application Reconfiguration Considerations](https://documentation.sailpoint.com/identityiq/help/appconfig/appreconfigconsiderations.html#admin_configuration_applications_1656461757_2895752). - Delimited file to the corresponding direct connector (Delimited File to Active Directory -- Direct) - JDBC connector to corresponding direct connector (JDBC to Oracle Applications -- Direct) - Agent based connector to direct connector (Active Directory -- Full to Active Directory -- Direct) - To a rewritten connector for better performance or more functional support (Google Apps -- Direct) ## Application Reconfiguration Considerations Take the following points into consideration before deciding to reconfigure an application. Do the identity attribute of account and group in the original application match the identity attribute of account and group in the reconfigured application? For example: - Two application types (Delimited File and Active Directory – Direct) use distinguishedName as the identity attribute of account, and use the same identity attribute for group. Since both of these applications refer to the same identity attribute of both account and group, they would be good candidates for reconfiguration. - Two application types (Oracle Application – FULL and Oracle Application – Direct) use different identity attributes for account, USER_ID in one and USER_NAME in the other and, USER_ID and USER_NAME differ in format. These are not good candidates for reconfiguration. Note If there are special attributes (native identity, managed attribute, entitlement) that split into multiple attributes in the new application type, reconfiguration is not recommended. - Profiles in SAP–Full refer to both profiles and groups in the managed system, whereas in SAP–Direct, profile refers to profiles and group refers to the groups in the managed system. These are not good candidates for reconfiguration. ## Before Application Reconfiguration Perform the following actions before you begin the reconfiguration process: - Backup the application xml and application type specific customizations such as rules and business processes. - Plan the attribute mapping of the original and new applications for accounts and group schema. If there are attributes in the original application type that are not in the reconfigured application type, you might lose some configuration and historical data. - Check the provisioning policies of the target application and decide which policy to use, the policy from the original application type or the policy from the reconfigured application type. ## How to Reconfigure an Application Note While reconfiguring an application the target application must have a static schema and not a dynamic schema like JDBC or DelimitedFile connectors. There is the button named Discover Schemas to generate the schema. 1. Go to **Applications > Application Definition** and select an application. 1. On the Application Configuration page, select **Reconfigure** to display the Select New Application Type dialog. 1. Select an application type from the New Application Type dropdown list and select **Save**. 1. Confirm your selection to go to the Application Configuration page in edit mode. The tabs that contain information requiring attention are marked with an red asterisk. 1. Go to the Attributes tab and enter the valid configuration attribute settings and test the connection. 1. Go to the Schema Mapping tab and map the Previous Schema Attributes to the New Application Type Schema Attributes for the Account and Group. Use the **Add Missing Attributes** and **Keep Extra Attributes** options to select to add missing attributes from the old (original) application type to the new application type, and to keep attributes that are on the new application type but were not on the original application type. 1. Go to the Provisioning Policy tab and select the provisioning policy to use for the reconfigured application. It is recommended that you use the policy that corresponds to the application type of the newly reconfigured application. You can use a different policy, but you must manually edit that policy to match the changes made during the reconfiguration process. 1. Save the reconfigured application. ## After Application Reconfiguration Check the reconfigured application for the following when the process is complete: - Attributes that were not mapped might not work, and the values might not get populated. - Unmapped attributes affect configurations (for example, policy or business roles), and context based historical data (for example, viewing certification history), that is based on a population that relies on the attribute. - Related populations might not be populated with identities. - Pending provisioning operations that contain that attribute might fail. - Verify other places that use the attribute, such as identity mapping, account mapping, roles, policies, and policy violations. - Verify the application definition for unwanted entries like build map rules or provisioning rules - Run the account and account group aggregation task - Run the refresh Identity Cube task - Run a task to prune the Identity Cubes # Configuring an Application An application in IdentityIQ is an instance of a configured IdentityIQ connector, that includes all of the configuration and connection details required to connect IdentityIQ to a third party application for the purposes of governing and provisioning access to these applications. Applications can be read-only, or read-write. There are two types of connector in IdentityIQ: application-type connectors that collect account information, and activity-type connectors that collect activity information. IdentityIQ uses the information from both types to maintain Identity Cubes. To configure applications, from the menu bar, click **Applications > Application Definition**. ## Application Definition Page The Application Definition page displays all of the applications currently configured. The Application List contains the following information: | Column | Description | | ----------------- | ------------------------------------------------------------------------- | | Name | The name of the application. | | Description | Description of the application. | | Host | Host where the application resides. | | Type | The application type, such as LDAP or JDBC. | | Aggregation Types | The object, such as account or group, for which aggregation is supported. | | Modified | The date when the application was last modified. | | Owner | Owner of the application. | | Actions | An ellipsis menu to edit or delete the application. | You can perform the following actions to customize the application list: | Action | Description | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Display or hide columns | From the **Columns** dropdown, select or clear the checkboxes of the columns to manage their visibility. | | Resize columns | To change a column width, drag the border of the column header to the desired size. | | Reorder columns | To reorder columns, drag a column header and drop it into the desired position. | | Filter applications | To filter applications based on the application type, modified date range, and application owner, select **Filter** in the upper-right corner, specify filter criteria in the **Filters** panel, and select **Apply Filters**. To clear the applied filters, open the **Filters** panel again, and then select **Clear Filters**. | | Search applications | To find a specific application, enter your search text in the **Search** box. IdentityIQ scans the **Name** column for matching text, using the 'Contains' logic. Results are paginated at 25 records per page by default, with navigation controls (First, Previous, Next, Last) and an Items per page dropdown (10, 25, 50, 100). | | Sort applications | To sort the application list, click any sortable column header (**Name**, **Type**, **Modified**, or **Owner**). Sortable columns display a double arrow icon. Once sorted, this icon changes to a single up or down arrow to indicate ascending or descending order. | Note The Application Definition feature-list view preserves your working context (including search query, table columns, column order, sort order, and pagination) when you navigate to another page within Application Definition and return. However, a complete browser refresh only preserves table configurations, sort order, and pagination; it does not preserve the entire prior state. Click on icon for an existing application **>** **Edit** to open the Edit Application page or click **Add New Application** to create a new application definition. See [Using the Edit Application Page](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/index.html#using-the-edit-application-page). ## Common Application Configuration Details The Details tab for each application includes options that are common to all applications. ### Application Type The Application Type list contains all the connectors that are enabled for your instance of IdentityIQ. Many of the application types are specific to particular target systems, such as Workday or Box. Others are more general-use types that can be used on various systems or sources, such as JDBC and SCIM 2.0. The application type determines which configuration options appear in the application configuration UI. Some options are unique to the selected application type. Note that some connectors may not be enabled by default in your instance and so may not appear in the application type list; if you do not see an application type listed here that you think you should have access to, contact your Customer Success Manager or Professional Services resource. For more information about specific connectors, refer to the [IdentityIQ Connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) documentation on SailPoint's documentation portal. ### Owner The owner specified here is typically the business owner of the system, who is familiar with the system, its entitlements, and who should have access it it. The owner responsible for access reviews for this application from application owner certifications, account group permissions certifications, and account group membership certifications. The application owner can also be selected as an approver in targeted certifications. By default, the application owner is also responsible for approving access requests for entitlements associated with this application, although this behavior can be modified in the business process that manages access requests. Tip An application owner can be either an individual or a workgroup; it is a best practice to set a workgroup as the owner of the application. Assigning ownership to a workgroup makes it possible for multiple people to share responsibility for managing application-related activities that must be performed by someone, but do not necessarily need to be owned or performed by a specific person. See [Workgroups](https://documentation.sailpoint.com/identityiq/9.0/help/roles_groups_and_populations/workgroups.html#workgroups). ### Revoker If you want to designate a user or workgroup that is responsible specifically for handling requests to revoke access (which typically occur as a result of a certification decision or policy violation), enter that identity or workgroup here. If no user is specified in this field, all revocation requests are assigned to the application owner by default. ### Authoritative Application An authoritative application is a target system that represents the primary and most trusted information for employee information for your enterprise, such as a human resources application. When this option is selected, designating this application as an authoritative one, the IdentityIQ aggregation process will create an authoritative Identity Cube for each account in this application. For applications that are not marked as authoritative, IdentityIQ will attempt to correlate aggregated accounts to existing authoritative identities. Your organization can have multiple target systems designated as authoritative sources. For more information, see [Authoritative and Non-Authoritative Data Sources](https://documentation.sailpoint.com/identityiq/9.0/help/application_management/index.html#authoritative-and-non-authoritative-data-sources) . # Application Connection Parameters Connection parameters define how the application will connect to and communicate with the target system. For example, for a delimited file application, you will need to specify the name and location of the delimited file, as well as what the delimiter is, and any file encoding. For a JDBC application, your connection parameters will include the database URL, the JDBC driver, and a username and password for the connection. The required configuration parameters vary by connector, based on the specific requirements of the target system. For more information about specific connectors, refer to the [IdentityIQ Connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) documentation on SailPoint's documentation portal. # Application Dependencies Your business may have dependency requirements, where a user's access to one application is dependent on access to another application. For direct-connection applications, you can define **Application Dependencies** on the **Provisioning** tab, to specify that a user must have an account on one system before they can have an account on another system. When an Application Dependency has been defined, IdentityIQ's provisioning process will check to see if there is an account on the application(s) listed. If not, when IdentityIQ processes a provisioning request for a new account, a request for the an account on specified system(s) is added. When Application Dependencies have been defined, you can use values from these applications as part of your Provisioning plans. When you select Value Settings in the provisioning form, you will see dependent as an option. You can choose the application and the attribute to retrieve from it in your form. # Application Schemas For every application, you must define the specific data you want to aggregate from the target system. The target system may have dozens or hundreds of attributes for each user, not all of which may be relevant for your identity governance program, and which therefore do not need to be brought into IdentityIQ. The schemas you define for the application specify which attributes to include when aggregating data from the target system. Most connectors include **predefined** default schemas, which you can use as a starting point for defining the schemas you need. When a connector supports a predefined schema, you will see the attributes listed and defined for you on the **Configuration > Schema** tab. You can add or remove attributes from a predefined schema as needed. ## Account Schemas Every configured application must include an account schema, which defines which data about accounts to read from the target application and identifies the accounts you want to manage. The account schema must designate one of the attributes as the **Identity Attribute**, which is the unique identifier for the account on the source. ## Group Schemas For many applications, account entitlements are memberships in groups. Many connectors also support the use of group schemas, allowing the application to aggregate additional details about the group structures from the target system. Once a group schema is defined, you will need to connect the account schema to the group schema so IdentityIQ can recognize that the account entitlements identify group memberships. This is done by setting the **Type** for the entitlement attribute in the account schema to a value that matches the Native Object Type of the group schema. This value is often "group"; however, some connectors support multiple group schemas or offer more flexible options for schema definitions, so in some cases this may be a value other than "group." Values for the entitlement attribute on accounts will be mapped to the Identity Attribute selected for the group schema to associate the groups with those users. Some connectors support only a single group schema, and others support multiple group schemas.For more information about specific connectors, refer to the [IdentityIQ Connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/) documentation on SailPoint's documentation portal. ## Properties of Attributes in Account and Group Schemas Attribute properties determine how attributes are used and managed in IdentityIQ. For example, you may want some attributes to support multiple values, or to be included in the Entitlement Catalog. Select icon to open the **Advanced Properties** panel to edit the attribute properties for accounts and groups. ***Entitlement*** Marking an attribute as an entitlement indicates that this is an access right you want to track for your identities (for example, to use in certifications). If you want this attribute to be able to be requested, to have an owner, and to have a description and display name, you must also mark it as Managed. ***Managed*** Attributes designated as Managed can be viewed and managed from the Entitlement Catalog page. Managed attributes can be made requestable, can be assigned an owner (for approvals or entitlement certifications), and can have display names and descriptions that will help users identify and understand them. They can also be used in policies and risk calculations. When you do a group aggregation, all groups read from the aggregation are automatically included in the entitlement catalog as managed attributes. ***Multi-valued*** For some attributes, multiple values might be returned during aggregation (for example, an attribute indicating group membership). These should be marked as Multi-valued. Values for attributes flagged as multi-valued are stored as a list. Even objects that have a single value for a multi-value attribute are stored as a single-item list. ***Correlation Key*** The Correlation Key flag is only used for activity and unstructured data aggregation. If activity aggregation is not being used, Correlation Key should not be selected. This flag specifies attributes that IdentityIQ can use to correlate activity discovered in the activity logs for this application with information stored in Identity Cubes. For information about correlating aggregated accounts to existing identities, see **Correlation** in [Application Concepts](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/application_concepts.html#application-concepts). For example, activity logs might contain the full name of users instead of unique account ids. Therefore, correlation of the activity discovered by an activity scan and the Identity Cube of the user that performed the action must key off of the user's full name. ***Minable*** Attributes that you want to use for role and profile creation should be marked as minable. This allows the Role Mining feature to mine applications for attributes and permissions when creating roles and profiles, rather than requiring manual entry of the values. Only attributes designated as minable are returned by those searches. ***Remediation Modifiable*** Attributes that are remediation modifiable can have their values and permissions modified as part of a certification, for the identity being certified. Options are: - Select – in the certification, display a select list of all possible values or permissions for this attribute. - Free text – in the certification, display a text field in which a certifier can enter any value. - Readonly – the value cannot be modified. ## Discovering Schemas Some connectors support the discovery of schemas. For those application types, you can select **Discover Schema Attributes** to automatically populate your schema information in the Schema page. ## Previewing Data for a Schema Each defined schema offers a **Preview** button; this is useful for checking the schema against a small sampling of the source system's data before aggregating. ## Avoiding Conflicts Between Schema Attributes and Extended Attributes If your IdentityIQ instance makes use of extended attributes, you should ensure that the names of your extended attributes names do not duplicate any attribute names in your application's schema(s). If an extended attribute name matches a schema attribute name, there is a risk that attribute values will not be updated correctly during an aggregation. For more information on extended attributes, see [Extended Attributes](https://documentation.sailpoint.com/identityiq/9.0/help/system_configuration/identityiq_global_settings/entitlement_catalog_attributes.html#extended-attributes). # Provisioning Policies Provisioning policies in an application configuration define the set of attributes which are needed to complete a provisioning request, whether that request is to create an account, modify an account, add a role to an identity, etc. In some cases, values for the attributes can be auto-calculated based on the field's definition in the provisioning policy; in other cases, the fields are presented to a user who can provide their values. When auto-calculation is possible, it is encouraged as a best practice, because it is typically more efficient and less error-prone than user-provided values. Provisioning policies are implemented as **forms** that specify which attributes to include in provisioning requests, and how the values of those attributes are provided – manually by an IdentityIQ user, or in an automated manner, either through a static value, or a value that IdentityIQ calculates using a script or rule. For example, if you are provisioning a new account on an LDAP application, the provisioning policy should provide the minimum required attributes (such as user name and email) to successfully create a new account on the LDAP application. In addition, optional attributes can be included in the provisioning policy to set additional values as needed. Provisioning policies can be configured so that all values are provided automatically by IdentityIQ. Alternatively, attributes can be specified without a value but marked as required, so that IdentityIQ will prompt a user to provide the data manually. In this example, the values for First, Last, and Login are auto-calculated based on identity attributes; values for Status and Locked are specified as static values. | Attribute | Value | | --------- | ------------------------- | | First | return identity.firstname | | Last | return identity.lastname | | Login | return identity.name | | Status | A | | Locked | N | Based on this policy, IdentityIQ can automatically build a provisioning plan to pass the required values to the connector to create a new account on the target system. For some connector types, the provisioning policy for creating accounts is pre-defined; however, predefined policies can be modified as needed, according to your business needs. When a user submits a Lifecycle Manager request, such requesting a business role or unlocking an account on a target system, IdentityIQ pulls the list of required attributes from the provisioning policy, and includes those attributes and their values in the provisioning plan. ## Using the Form Editor for Configuring Provisioning Policies A provisioning policy is essentially a collection of fields. These fields are defined in a form editor UI. For each field, you can define a variety of settings that determine what type of information is required and how IdentityIQ provides it. The provisioning policy's **Name** field should match the corresponding native attribute on the application. If **Review Required** is selected for a field, the field is always presented on a form during provisioning-request processing, even if a default value is provided or calculated successfully. For details about working with form fields, see Working with the Form Editor (LINK IN DOC). # Using Rules in Applications Rules in applications allow the addition of custom business logic to extend the functionality of IdentityIQ in aggregating from or provisioning to the application. Some rules are applicable to and can be used in all applications. Other connector types support rules that are specific to the connector type. For more information on connector-specific rules, see [Rules Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/rules_tab.html#rules-tab). When implementing rules for applications, be aware of potential performance impacts. Complex rules that act on every record being processed by IdentityIQ can have a significant performance impact. For general information about implementing rules, see [Rules and Scripts in IdentityIQ](https://documentation.sailpoint.com/identityiq/9.0/help/system_administration/rules_scripts.html#rules-and-scripts-in-identityiq). # Using the Edit Application Page Use the **Edit Application** page to configure applications for your enterprise. The Edit Application page displays the default **Details** tab and includes the following additional tabs: Note Some tabs only appear after an application has been defined and configured. - [Configuration Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/configuration_tab.html#configuration-tab) - [Correlation Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/correlation_tab.html#correlation-tab) - [Accounts Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/accounts_tab.html#accounts-tab) - [Risk Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/risk_tab.html#risk-tab) - [Activity Data Sources Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/activity_data_sources_tab.html#activity-data-sources-tab) - [Unstructured Targets Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/unstructured_targets_tab.html#unstructured-targets-tab) - [Rules Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/rules_tab.html#rules-tab) - [Password Policy Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/password_policy_tab.html#password-policy-tab) - Tiers Tab - This tab is available only for Logical application types. See detailed information about configuring Logical applications in the [IdentityIQ connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) documentation. The information on each tab is determined by the type of application specified on the **Application Type** dropdown list. Use these tabs to define how each application interacts with IdentityIQ. The **Edit Application** page also lists any extended attributes that were configured for your deployment of IdentityIQ; these are displayed at the bottom of the tab. For each application enter or edit the following information: ## Edit Application Details Fields ### Application Type The **Application Type** dropdown list specifies the supported target application type (for example, LDAP or JDBC) to which IdentityIQ can connect. This list is updated as new application types are introduced or existing types are deprecated. When editing an existing application, the **Application Type** dropdown list is disabled and cannot be modified. However, if you do need to change the Application Type, click **Reconfigure** button at the bottom of the page. To learn more, see, [Reconfiguring an Application](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/reconfigure_app.html). ### Name The name of the application. This is the name used to identify the application throughout IdentityIQ. Note In IdentityIQ the specified application name cannot be exactly 32 characters and can neither be comprised only of 0-9, a-f and A-F. Special characters ' < > " % are not allowed. There is a maximum character limit of 128 characters for the application name. The name ‘IdentityIQ’ is reserved for internal use, hence select a different application name. ### Owner The owner specified here is typically the business owner of the system, who is familiar with the system, its entitlements, and who should have access to it. The owner responsible for access reviews for this application from application owner certifications, account group permissions certifications, and account group membership certifications. The application owner can also be selected as an approver in targeted certifications. Application ownership can be assigned to an individual identity or a workgroup. If the application ownership is assigned to a workgroup, all members share certification responsibilities, are assigned certification request associated with the application and all can take action on those requests. ### Revoker The default IdentityIQ user or workgroup to be assigned revocation requests associated with entitlements on this application. If no user is specified in this field, all revocation requests are assigned to the to application owner by default. ### Proxy Application A proxy application is an application that handles the processing (aggregation and provisioning) on behalf of your application. Configuring a proxy application is optional. Here are some examples of proxy applications: - Multiplex applications: In this case you define an application and, most often, a build map rule that sorts the data out in multiple sub-applications. In that case, the sub-applications have the main application as the proxy. - Similar to the multiplex applications are the connectors for legacy identity management systems such as, BMC, Novell/NetIQ, IBM Tivoli, and Sun/Oracle Waveset. - The Cloud Gateway connector tunnels all aggregation and provisioning requests to the gateway in another network. The gateway then acts on behalf of IdentityIQ. All applications that live in the remote network need to have the cloud gateway connector set as the proxy. ### Profile Class This is an optional class used to associate this application with a larger set of applications, for role modeling purposes. For example, you might set a profile class of XYZ on all of the applications where any user that has read account privileges should be assigned the role XYZ Account Reader. You can then create a single profile for that role instead of a separate profile for each instance of the applications. During the correlation process any user with read account privileges on any of the applications with the profile class XYZ is assigned the role XYZ Account Reader. ### Description A brief description of the application. If your instance of IdentityIQ is configured to support multiple languages, you can use the language selector to enter description in multiple languages. The dropdown list displays any languages supported by your instance of IdentityIQ. The description displayed throughout the product is dependent on the language associated with the user's browser. If only one description is entered, that is the description used by default. ### Scope This field is only visible if scoping is enabled for your instance of IdentityIQ. When a scope is assigned, only the owner of the application or users that control the designated scope can work with this application. Objects associated with this application, such as entitlements in a certification request, are visible to a user with any or no controlled scope, but if a new object is being created (for example, a certification schedule), this application does not appear on the select list unless the creator controls the scope assigned. Depending on configuration settings, objects with no scope assigned might be visible to all users with the correct capabilities. ### Authoritative Application An authoritative application is a target system that represents *the primary and most trusted information* for employee information for your enterprise, such as a human resources application. When this option is enabled, designating this application as an authoritative one, the IdentityIQ aggregation process will create an authoritative Identity Cube for each account in this application. Note that your organization can have multiple authoritative applications. ### Case Insensitive Enable this option to cause case insensitive comparisons of account attribute values when evaluating provisioning policy. ### Native Change Detection Enable this option if this application should be included when IdentityIQ performs native change detection during aggregation. For more detailed information about configuring native change detection, see [Native Change Detection Configuration](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/native_change_detection.html). ## Native Change Definitions ### Native Change Operations Select which operations are included when detecting native changes. If no operations are selected, native change detection is disabled. ### Attributes to Detected Indicates which attributes are compared when accounts are modified. If the **Entitlement** option is selected, all entitlement attributes are included. If you select **User Defined**, enter the name of the attributes to compare in the **Attribute Names** box. ## Maintenance: Take an application offline for maintenance ### Maintenance Enabled When maintenance is enabled, the application is excluded from provisioning and aggregation during the defined maintenance period. See [Application Maintenance Windows](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/app_maintenance_windows.html) for more information. ### Maintenance Expiration The date and time at which the maintenance will end. If no date and time are defined, this application will be in maintenance indefinitely. After adding the application information, click **Save** to save your changes and return to the Application Definition page. Note If you navigate away, log out, refresh, go back, or change the Application Type without saving, a warning popup appears with two options: **Leave/Continue** (discards unsaved data and resets the page to the Details tab) or **Cancel/Stay** (dismisses the popup with no changes). # Accounts Tab Note This tab is only visible after an application is defined and configured. The Accounts Tab lists the following information for the selected account: - Account ID - Account Name - Status - Last Refresh - Identity Name Click on the account name to view details about the account, such as the last login time and date. Click on the Identity name to show the details of the Identity. Clicking on the checkbox from the list offered in the **Columns** option allows you to configure additional columns; simply unchecking removes the column name from the list. Sorting options are also available on all the options except for status. To **Search**, enter a character, or combination of letters into the search bar. Search can be done by **Account ID**, **Account Name**, **Identity Name** or **Identity ID** field. # Activity Data Sources Tab The Activity Data Source tab is used to configure the data sources from which activity information is collected. The information collected from these sources is normalized and then stored by IdentityIQ and used to monitor activity information for users and applications. Activity information is collected and correlated using the Activity Aggregation task. Activity information displayed on the or returned by activity searches is based on the information stored by IdentityIQ since the last aggregation and correlation tasks were run. The Activity Data Sources table contains the following information: ***Name*** A descriptive name for the activity data source from which the activity data is collected. ***Type*** The activity data source type, for example JDBC Collector, Log File, CEF Log File or Windows Event Log Collector. ***Modified*** The date when the activity data source was last modified. To configure a data source, click on the **Add Activity Data Source** button and provide details in the form. To **Edit** an activity data source, click on the added data source or click on icon and select **Edit** to modify the corresponding data source. To delete a data source, click on the icon under the **Actions** column and select Delete from the menu. See [Activity Data Source Configuration](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/act_data_source_config.html#activity-data-source-configuration). # Configuration Tab The information displayed on the Configuration tab changes depending on the application type specified. Note The terms account group and application object are use interchangeably in this document but have the same meaning. Some application can have multiple application objects. An account group can be the name of one of those objects. ## Settings Tab The **Settings** tab contains the information that IdentityIQ uses to connect and interact with the target system. **Each application type requires different connection information and the fields on this tab are changed accordingly**. For more information on connection parameters, see [Application Connection Parameters](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/application_connection_parameters.html). For more information about specific connectors, refer to the [IdentityIQ Connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) documentation on SailPoint's documentation portal. If your enterprise is going to use partitioning for account aggregations, identity refreshes, and manager certification, you must enable that function here. Each application type requires different partitioning information. This is also where you enable an application for data merging and delta aggregation. Enter the information on this tab as required by the application type being configured. Click **Test Connection** to verify the information is correct. #### Credential Cycling A note is displayed at the top of this tab if the application is configured to use credential cycling. For those applications, the credentials are stored and maintained on a Privileged Access Management (PAM) module, and verification is performed using existing hook points that support the retrieval of passwords from application credential management solutions such as, CyberArk Application Identity Manager (AIM) or BeyondTrust PowerBroker Password Safe. See [Privileged Account Management](https://documentation.sailpoint.com/identityiq/9.0/help/privileged_account_management/index.html) and [Privileged Account Management Credential Cycling](https://documentation.sailpoint.com/identityiq/9.0/help/privileged_account_management/privileged_acct_mgmnt_credential_cycling/index.html) for more information. Note To enable credential cycling, BeyondTrust PowerBroker Password Safe application passwords must be configured in the JSON format: `{"bt_user":"MyUserName","bt_password":"MyPasswordValue"}` ## Schema Tab The Schema tab is used to define the attributes for each object type in the application being configured. Use the following fields to define attributes for use with the IdentityIQ application. The field content is dependent on the application being configured. For more details on configuring schema information, see [Application Schemas](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/application_schemas.html). For more information about specific connectors, refer to the [IdentityIQ Connectors](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) documentation on SailPoint's documentation portal. ### Adding Object Types For most application types you see account and group object types. Certain application types, however, enable you to create multiple application object types, each with their own schema. These application object types are sometimes referred to as account groups and that term might be used interchangeably in discussion around this feature. To add a new object type, enter a name for it and click the + button. This function is only available if the application type is associated with a connector that is enabled to handle multiple application object types, or multiple schemas. This + button is also displayed if you recently upgraded your instance of IdentityIQ and the application type now supports multiple schemas. In that case, you must add the supported application object type here and then run the Account Group Aggregation task to import the new information. Multiple application object types can be directly correlated, for example an application object type is also an attribute in the schema of another, or they can be indirectly associated, for example they are both objects (schemas) in the same application. These objects and their associations are tracked throughout IdentityIQ and appear in place such as reports, policy violations, searches, and certifications. When initially configuring applications, click on icon to **Add New Schema Attribute** to define the attributes for each object. Most application types include a default set of schema attributes. For more dynamic application types (JBDC or DelimitedFile), schemas should be defined manually. Click icon to display the **Advanced Properties** panel. Important A schema attribute name must not duplicate any extended attribute names that have been defined in your IdentityIQ instance. If an schema attribute name matches an extended attribute name, there is a risk that attribute values will not be updated correctly during an aggregation. The connectors for some application types enable the automatic discovery of the base schema attributes for those applications. For such application types, click **Discover Schema Attributes** to automatically populate your schema tables. After using the automatic discovery function you must designate the Identity Attribute and Display Attribute for the application. Click **Preview** to test the respective schema configuration. A pop-up sample table displays to indicate a successful configuration. These tables automatically update when you make changes so that you can use this feature before committing your changes. Only one table can be open at one time. Failures result in an error message specifying the point of failure, for example, a file path and name. Note The Preview function does not apply to applications which do not support aggregation. Note When configuring display names, it is highly recommended to use clear, user-friendly names. This data is visible to reviewers during access reviews for the corresponding managed attributes, so intuitive naming helps ensure accurate and seamless review decisions. | | | | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Fields | Descriptions | | Native Object Type | LDAP default types are iNetOrgPerson and groupOfUniqeNames for groups. This is a required field. The type of object with which the attributes are associated. For example, User and Group for Active Directory LDAP or DBA_USER and DBA_ROLES for Oracle. | | Identity Attribute | This is a required field. Do not change the identity attribute on connectors with pre-defined schema.The attribute that is used by the IdentityIQ application to identify the object. | | Include Permissions | Enable this option to automatically add directPermissions to the schema. This option is available for any application that has `DIRECT_PERMISSIONS` in the `featureString`, for example, Oracle, DelimitedFile, and sybase HR. With this option activated, IdentityIQ correctly pulls in permission data for identities. | | Index Permissions | Enable this option to let IdentityIQ treat direct permissions on aggregated entitlements (groups/roles/profiles) as searchable targets in the effective-access index. It does not change connector behavior; it changes what the Target Index task writes into `TargetAssociation`, which powers permission-based search, LCM discovery, SOD checks, and effective access views. | | Display Attribute | This is a required field. The attribute that is used as the object name as it appears throughout the IdentityIQ application. | | Instance Attribute | The attribute that uniquely identifies a specific instance of an application. Instance Attributes are not supported for Managed Attributes. | | Remediation Modifiable | Accounts that are remediation modifiable can have their values and permissions modified from the Certification Report page for the identity being certified. Specify the method of modification for this attribute: - **Read only**: the certifier can either approve or revoke the values or permissions for the identities, but not change them. - **Select**: display a select list of all possible values or permissions for this attribute. - **Free text**: display a text field in which a certifier can enter any value. | | **Additional Group Attributes:** | | | Description Attribute | Used during group aggregation to indicate which of the group attributes is used to populate the corresponding ManagedAttribute description. The value set here overwrites any set during the Account Group Aggregation task. | | Group Membership Attribute | The attribute that is used by the IdentityIQ application to identify the group. | | **Attributes:** | | | Name | Attribute names cannot begin with IIQ\_. Attributes with names that begin with IIQ\_ are considered internal, reserved attributes and are not displayed in the product. The name of the attribute. | | Description | A brief description of the attribute. | | Type | The type of attribute being defined. For example, string or boolean. Select from the dropdown list. | | Properties | The properties assigned to a respective attribute in a Schema. for example, Correlation Key, Entitlement, Managed, Minable or Multi-Valued. Select the corresponding check box using the **Settings** icon under **Advanced Properties** panel. | | **Advanced Properties:** Click icon to open the **Advanced Properties** panel to edit the attribute properties. | | | Managed | Specify attributes to be promoted to a first-class object in the IdentityIQ database so that they can be associated with other objects with that value, for example a description or an owner. Any attribute can become managed: department, location, title, but the most common attribute to be managed is the one holding group memberships. Managed attributes can be viewed and managed from the Entitlement Catalog page. | | Entitlement | Specify attributes to be used as entitlements on this application. Attributes specified as entitlements are used by IdentityIQ as follows: - As additional entitlements during certification. - When creating profiles based on exiting users on this application. Profiles are created on the IdentityIQ Modeler and are used to create roles. - In account group certifications. - In Lifecycle Manager. | | Multi-Valued | Specify attributes for which multiple values might be returned during aggregation. Attributes flagged as multi-valued are stored as a list. Even objects that have a single value for a multi-value attribute are stored as a single-item list. Multi-valued attributes are used for queries throughout the product. Before multi-valued attributes are available for use in searches, they must be mapped on the Edit Account Attribute page. Refer to the IdentityIQ system configuration documentation for information on how to add or edit account attributes. | | Correlation Key | Specify attributes that IdentityIQ can use to correlate activity discovered in the activity logs for this application with information stored in identity cubes. For example, activity logs might contain the full name of users instead of unique account ids. Therefore, correlation between the activity discovered by an activity scan and the identity cube of the user that performed the action must key off of the user's full name. Correlation Key is only used during activity aggregation. If activity aggregation is not being used, Correlation Key should not be selected. | | Minable | Specify attributes for use during role and profile creation. When creating roles and profiles it is possible to mine applications for attributes and permissions to use in those objects rather than manually entering the values. Only attributes designated as minable are returned by those searches. | | Remediation Modifiable | Attributes that are remediation modifiable can have their values and permissions modified from the Certification Report page for the identity being certified. Specify the method of modification for this attribute: - **Read only** - the certifier can either approve or revoke the values or permissions for the identities, but not change them. - **Select** - displays a select list of all possible values or permissions for this attribute. - **Free text** - displays a text field in which a certifier can enter any value. | | Set as Identity Attribute | Designates this attribute as the unique identifier (Account ID / Native Identity) for target accounts or entitlement objects on this application schema. | | Set as Display Attribute | Designates this attribute as the human-readable label displayed across the IdentityIQ UI instead of the raw account identifier. | | Set as Instance Attribute | Identifies an attribute used to differentiate specific target domains, partitions or instances in multi-instance configurations. | Note Modifying the **Set as Identity Attribute**, **Set as Display Attribute**, or **Set as Instance Attribute** schema attributes updates the application configuration, but changes take effect only after performing an Account Aggregation or Reaggregation. ## Provisioning Policies Tab [Provisioning Policies](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/provisioning_policies.html) are used to define application object attributes that must be managed due to a Lifecycle Manager request. With a provisioning policy in place, when a role or entitlement is requested, the user must input specified criteria into a generated form before the request can be completed. A policy can be attached to an IdentityIQ application object or role and is used as part of the provisioning process. For applications that support multiple application objects, each object is displayed in a separate table containing the provisioning policies those objects support. Not all application objects support all the provisioning policies listed below. In order to be able to provision to a DN with a backslash () to an Active Directory application through the Cloud Gateway you will need to set the following properties in `catalina.sh` or `catalina.bat` on the Cloud Gateway instance: ```text set CATALINA_OPTS=%CATALINA_OPTS% -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true set CATALINA_OPTS=%CATALINA_OPTS% -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true ``` Setting the dependencies between applications and accounts implies ordering in provisioning. IdentityIQ includes the following types of provisioning policies: - Create - Update - Delete - Enable Account - Disable Account - Unlock Account - Change Password - CreateGroup - UpdateGroup Click an existing provisioning policy or click on icon, which displays the option to **Add New Policy** to create a new one using the Add New Policy Form or displays the option to **Add Policy Reference** to reference an existing policy. Only one of each policy type is supported. To edit an existing provisioning policy, click the corresponding icon and click **Edit Policy Form** to modify the policy details or **Delete Policy Form** to delete the corresponding provisioning policy. Use the **Application Dependencies** dropdown list to create the list of applications where this application is dependent for provisioning. If no account is detected on an application where this application is dependent, an account request is added to the provisioning plan and the provision policy for this application is processed as expected. The Provisioning Policy Editor panel contains the following information: | Field Name | Description | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | The name of your provisioning policy. | | Description | A brief description of the provisioning policy. | | Owner | The owner of the provisioning policy. This is determined by selecting from the following:- **None** -- no owner is assigned to this provisioning policy. - **Application Owner** -- identity assigned as owner of the application in which the provisioning policy resides. - **Role Owner** -- identity assigned as owner of the role in which the provisioning policy resides - **Rule** -- use a rule to determine the owner of this provisioning policy. - **Script** -- use a script to determine the owner of this provisioning policy. | #### Edit Provisioning Policy Fields Panel Use the Edit Provisioning Policy Fields panel to customize the look and function of the form fields generated from the provisioning policy. | Field Name | Description | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | The name of the field. | | Display Name | The name displayed for the field in the form generated by the provisioning policy. | | Help Text | The text you wish to appear when hovering the mouse over the help icon. | | Type | Select the type of field from the dropdown list. Choose from the following:- **Boolean** -- true or false values field - **Date** -- calendar date field - **Integer** -- only numerical values field - **Long** -- similar to integer but is used for large numerical values - **Identity** -- specific identity in IdentityIQ field - **Secret** -- hidden text field - **String** -- text field | | Multi Valued | Choose this to have more than one selectable value in this field of the generated form. Click the plus sign to add another value. | | Read Only | Determine how the read only value is derived:- **Value** -- value based on the selection from the drop-down list - **Rule** -- value is based on a specified rule - **Script** -- value is determined by the execution of a script | | Hidden | Determine how the hidden value is derived:- **Value** -- value based on the selection from the drop-down list - **Rule** -- value is based on a specified rule - **Script** -- value is determined by the execution of a script | | Owner | The owner of this provisioning policy field. This is determined by selecting from the following:- **None** -- no owner is assigned to this provisioning policy. - **Application Owner** -- identity assigned as owner of the application in which the provisioning policy resides. - **Role Owner** -- identity assigned as owner of the role in which the provisioning policy resides. - **Rule** -- use a rule to determine the owner of this provisioning policy. - **Script** -- use a script to determine the owner of this provisioning policy | | Required | Choose whether or not to have the completion of this field as a requirement for submitting the form. | | Review Required | Choose whether or not to require the person who is approving the workflow item to approve this field. | | Refresh Form on Change | Select this option to have the form associated with this policy refresh to reflex changes to this policy. | | Display Only | Set this field as display only. | | Authoritative | Boolean that specifies whether the field value should completely replace the current value rather than be merged with it; applicable only for multi-valued attributes | | Value | Determine how the value is derived. Select from the following:- **Literal** -- value is based on the information you provide - **Rule** -- value is based on a specified rule - **Script** -- value is determined by the execution of a script | | Validation | Gives the ability to specify a script or rule for validating the user's value. For example, a script that validates that a password is 8 characters or longer. | # Correlation Tab Use the correlation tab to configure how application accounts are assigned to identities within IdentityIQ using account and identity information. To configure **Account Correlation** you can select an existing correlation configuration from the list and click **Edit** to modify the selected configuration or create a new configuration by clicking the **New** button. The new configuration form provides help with text to add both attribute based and condition based correlation details. In the **Manager Correlation** section, configure how assigned managers should be resolved to identities using existing information. ***Attribute Based Correlation*** Use attributes of the application's account to find identities based on attribute values stored on Identity objects. This is how accounts are typically correlated to Identities. For example, you can correlate the application's account attribute "mail" with an identity's attribute "email." To configure Attribute Based Correlation, select the value in the **Application Attribute** field from the dropdown followed by **Identity Attribute**. Multiple attributes and values can be associated with a single identity by clicking on the icon. You can also delete the conditions by clicking on the icon. ***Condition Based Correlation*** Assigns application accounts to existing identities by defining attribute conditions. Service and Administrator accounts might be handled using condition based correlation. For example, the root account on Unix typically does not have any identifying attributes that can help when trying to correlate it to an existing identity. In cases where the account owner is known because they are the application owner, a direct mapping can be used. To configure Condition based correlation, select the value in the **Identity to Receive Matching Accounts** field from the dropdown followed by **Application attribute** and the **Value**. Multiple attributes and values can be associated with a single identity by clicking on the icon and you can also delete the conditions by clicking on the icon. Once the condition is defined, click on the **Add Conditions** button. To edit an existing condition, click on the icon and then click on the **Save Conditions** button once the edit is complete. To configure Manager Correlation you must select two attributes, the Application Attribute and the Identity Attribute. ***Application Attribute*** The name of the application's account attribute that hold the reference to the manager. ***Identity Attribute*** The name of the identity attribute to use when searching for managers. For example, if the application has an attribute `managerEmail` with the value set as the email address of the manager of every user with an account on the application, and you have an identity attribute email configured within IdentityIQ with the value set as the email address for every identity cube, you would correlate the application attribute `managerEmail` with the identity attribute email to perform manager correlation. # Password Policy Tab Use the password policy tab to select and create password policies which apply to specified applications. The **Password Policies** panel contains the following: ***Name*** The name of your password policy. ***Description*** A brief description of the password policy. To configure an existing password policy, select the policy from the **Existing Policy** dropdown or click **New** to create a new policy from scratch. Note By default, the **Password Policies** section displays no results. When a Password Policy is configured by either selecting from existing policies or creating a new one, and clicking on **Apply Changes**, only then will the **Password Policies** section display the corresponding details. The **Password Policies** section contains the following details, once you have already configured password policies: **Name** The name of your password policy. **Description** A brief description of the password policy. **Actions** Click on the icon to **Edit** or **Delete** the policy. #### Password Policy Fields (for **Edit Policy** or **Add Policy** section): | Field Name | Description | | ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Password Policy Name | The name of your password policy. | | Password Policy Description | A brief description of the password policy. | | Minimum number of characters | The minimum number of characters required for a valid password. | | Maximum number of characters | The maximum number of characters allowed for a valid password. | | Minimum number of letters | The minimum number of letters required for a valid password. | | Minimum number of character type constraints to meet | The minimum number of character types (digits, upper case, lower case, special) allowed for a valid password. | | Minimum number of digits | The maximum number of numerical digits allowed for a valid password. | | Minimum number of uppercase letters | The minimum number of uppercase letters required for a valid password. | | Minimum number of lowercase letters | The minimum number of lowercase letters required for a valid password. | | Minimum number of special characters | The minimum number of special characters required for a valid password. | | Number of repeated characters allowed | The maximum number of consecutive repeated characters allowed in a valid password. For example, if this option is set to 2, "cloudd" and "cclooud" are valid, but "clouddd," "cloooud" and "cccloud" are invalid. This value also sets the maximum number of occurrences of repeated characters allowed in a valid password. For example, if this option is set to 2, "happy123" is valid, however, "happy22" and "happpy123" are not. In this example, when "cclooudd" is an invalid password, the following error message is displayed: Password should not contain more than 2 occurrence(s) of the repeated characters. When "clouddd" is an invalid password, the following error message is displayed: Password should not contain more than 2 consecutive repeated characters. Setting this value to zero has the same effect as leaving this field blank, allowing any number of repeated and consecutive characters. To prevent the use of any **consecutive** repeated characters, set this value to 1. Setting the value to 1 does not prevent using a character more than once, as long as the characters are not consecutive. For example, with a value of 1, "kitkat" is valid but "kitten" is not. | | Password history length | The number of past passwords that cannot be used again. | | Triviality check against old password | Ensure that the shorter of the old and new password is not a substring of the other. Both passwords are changed to upper case prior to the check. | | Minimum number of characters by position | The minimum number of unique characters by position the new password. Can be used to ensure that not just the first or last character is being changed. Select **Case sensitive check** to ensure that more than just the case is changing in the new password. | | Validate passwords against the password dictionary | Select this option to disallow the use of any password defined in the password dictionary. The password dictionary is a configurable list of terms unavailable for use as passwords. The `passwordDictionary.xml` file located in `IdentityIQ/WEB-INF/config/`. | | Validate passwords against the identity's list of attributes | Select to disallow the use of Identity attribute values as passwords. | | Validate password against the account's display name | Select to disallow the use of the account's display name as the password (exact match by default). Enter a **Minimum word length** to define the minimum length of a substring of the account’s display name allowed in the password. | | Validate password against account ID | Select to disallow the use of the account's ID as the password (exact match by default). Enter a **Minimum word length** to define the minimum length of a substring of the display name of the account allowed in the password. | | Validate passwords against the identity's account attributes | Select to disallow the use of Identity link attribute values as passwords. Enter a **Minimum word length** to define the minimum length of a substring of the account's ID allowed in the password. | **Configure Password Filter** - Select a filter that selects the identities to which this password policy applies. Select from the following filters: - **All** – all identities have this password policy applied Match List – only identities whose criteria match that specified in the list. The criteria is configured using the tools provided. Add identity attributes, application attributes and application permissions. Customize further by creating attribute groups to which this password policy applies. Note If Is Null is selected, the associated value text box is disabled. When the is null match is processed, the term matches users on the chosen application who have a null value for that attribute/permission. - **Filter** – use an XML filter or compound filter to determine the identities to which this password policy applies. - **Script** – use a BeanShell script to determine the identities to which this password policy applies. - **Rule** – use a rule to determine the identities to which this password policy applies. - **Population** – select a population to which this password policy applies. # Risk Tab The application Risk tab provides a current application risk score and a detailed view of the raw and compensated risk score for each category used to derive that score. This page also provides a list of the top composite score contributors providing further information on how the score was derived and providing clues on the areas of highest risk. These scores are based on the latest information discovered by IdentityIQ. IdentityIQ uses a combination of base access risk and compensated scoring to determine the overall application risk scores, or composite risk score, used throughout the application. All scores are calculated by first determining the percentage of accounts that have the qualities tested by the component score. For example, if 10 out of 100 accounts are flagged as service accounts, then the raw percentage is ten percent (.10). This number is then multiplied by a sensitivity value which can be used to increase or decrease the impact of the original percentage. The default sensitivity value is 5 making the adjusted percentage fifty percent (.50). This final percentage is then applied to the score range of 1000 resulting in a component score of 500. After the component score is calculated a weight, or compensating factor, is applied to each component score to determine the amount each contributes to the overall risk score for the application. For example, a few violator accounts might increase risk more than many inactive accounts. Service, Inactive, and Privileged component scores look for links that have a configured attribute. For example, the component service with a configured value true. The Dormant Account score looks for a configured attribute that is expected to have a date value, for example `lastLogin`. This algorithm has an argument, `daysTillDormant`, that defaults to thirty (30). If the last login date is more than thirty (30) days prior to the current date, the account is considered dormant and is factored into the risk score. The Risky Account score looks for links whose owning identity has a composite risk score greater than a configured threshold. The default threshold is five hundred (500). The Violator Account score looks for links whose owning identity has a number of policy violations greater than a configured threshold. The default threshold is ten (10). # Rules Tab These are the rules that can be customized to handle data the manipulation requirements of the aggregation or provisioning processes for each application. Rules are specific to connectors and are used throughout the product. You can write more than one of each type and select the rule to use from dropdown lists. A file containing an example of each rule type is included in the IdentityIQ installation package. The `examplerules.xml` file is located in the `IdentityIQ_HOME/WEB-INF/config` directory. Many rule types apply to all applications and are called by the aggregation process. Other connectors may include additional rule options that are specific to the connector type. For an overview of developing and using rules in IdentityIQ, see [Rules and Scripts in IdentityIQ](https://documentation.sailpoint.com/identityiq/9.0/help/system_administration/rules_scripts.html#rules-and-scripts-in-identityiq). ## Aggregation Rules These rules define behavior when aggregating data from the application. Aggregation Rules are used during part of the aggregation process that occurs after the connector has created valid ResourceObjects for the accounts or groups being aggregated, which occurs after the defined connector rules have all been run. ***Correlation Rule*** This rule type is used to define identity correlation for applications whose accounts cannot be correlated to Identities through a simple attribute match in a correlation configuration. A correlation rule is required if the logic to correlate accounts is more complex than a correlation configuration will support (for example, correlating based on multiple attributes taken together). ***Creation Rule*** This rule is only run when a new identity is being created during the aggregation. Some examples of operations which might be performed in a creation rule include setting an identity's password, changing the name of aggregated identities, or setting an attribute to all caps. Typically, this rule is only used for authoritative applications, though one could be specified for a non-authoritative application if needed. ***Manager Correlation Rule*** A manager correlation specifies how one identity should be linked to another in a Manager – Direct-report relationship. This can often be accomplished with a simple attribute mapping correlation on the Correlation tab, but when a more complex matching algorithm is required, this rule type can be used. ***Customization Rule*** This is an open-ended rule which is available to all application types in IdentityIQ for manipulating or customizing the aggregated data before the account (or group) is saved to the database. This rule type is most often used for manipulating data on application types which do not offer Connector Rules, since for those applications, this rule is the only account-manipulation rule offered. ***Managed Entitlement Customization Rule*** The Managed Entitlement Customization rule is called during creation of Managed Entitlements in an aggregation or refresh task, or in the Missing Managed Entitlements Scan task. This rule can modify the Managed Entitlement as it is being created, to set fields such as owner, requestable, or descriptions before they are saved. "Managed Entitlements" are "ManagedAttribute" objects, which are Entitlement Catalog entries. ## Provisioning Rules These rules run during the processing of provisioning requests. Some are connector specific and some apply for all connectors, as indicated in their descriptions. Provisioning-related rules which apply to all application types are: ***Before Provisioning*** The Before Provisioning rule is executed immediately before the connector's provisioning method is called. This gives customer the ability to customize or react to anything in the Provisioning Plan before the requests are sent to the underlying connectors used in provisioning. This rule is not connector-specific; it runs for all applications regardless of connector type. ***After Provisioning*** An application's After Provisioning rule is executed immediately after the connector's provisioning method is called, but only if the provisioning result is in a committed or queued state. This gives customers the ability to customize or react to anything in the Provisioning Plan that has been sent out to specific applications after the provisioning request has been processed. This rule is not connector-specific; it runs for all applications regardless of connector type. ## Schema Rules Schema rules vary by connector and are used for customization. Schema rules allow you to segregate business logic account and group objects respectively, avoiding the need to check whether the resource object represents an account or non-account object. ## Connector Rules Connector rules are used during aggregation from specific connectors, such as Delimited File, JDBC, and SAP. Connector rules generally run before Aggregation rules in the aggregation process. These rules are used to implement pre-processing of data, implement post-processing of data, and manipulate, merge, or otherwise transform the incoming data as it is being read. Connector rules vary by connector type. # Unstructured Targets Tab Unstructured target information is used to define unstructured data sources from which the connector is to extract data. Unstructured data is any data that is stored in a format that is not easily readable by a machine. For example, information contained in an Excel spread sheet, the body of an email, a Microsoft Word document, or an HTML file is considered unstructured data. Unstructured targets pose a number of challenges for IdentityIQ connectors, because not only is the data stored in a format that is hard to extract from, the systems and directory structures in which the files reside are often difficult to access. The most common unstructured data type supported by IdentityIQ is an operating system's file system permissions. This target collector requires an IdentityIQ Service to be installed on a machine that has visibility to the directory or share to include in the target scan. See **Installation** documentation for information on installing and registering the IdentityIQService. The unstructured targets defined on this tab are used by the Target Aggregation task to correlate targets with permissions assigned to identities and account groups for use in certifications. Each of the Target Source Types require unique details or attributes for their configuration, but share some basic information. To configure a target source, select an existing source from the list and click **Edit** or create a new target source by clicking on the **New** button. The new configuration form provides help text to define the basic information for each of the Target Source Types: ***Name*** The name of this unstructured target configuration. ***Description*** A brief description of this configuration. ***Rules*** Specify the rules used to transform and correlate the targets. Note Click the icon to launch the Rule Editor to make changes to your rules if needed. ***Creation Rule*** The rule used to determine how the unstructured data extracted from data source is transformed into data that can be read by IdentityIQ. ***Correlation Rule*** The rule used to determine how to correlate account information from the application with identity cubes in IdentityIQ. ***Provisioning Action*** The provisioning action used to pass information to the affected applications. # Aggregation Aggregation is the process by which data about identities and their access is read from your enterprise systems into IdentityIQ. IdentityIQ aggregates Account data (which includes information about identities and their accounts and entitlements on the outside systems) and Account Group data (which includes account groups and application object types that are the basis for creating entitlements that represent group membership). IdentityIQ uses configured applications to connect to these enterprise systems, and uses tasks to do the work of reading the data into IdentityIQ and correlating it to identities stored in IdentityIQ. ## Aggregation and Applications A configured Application is the component that lets IdentityIQ communicate with an enterprise system. The enterprise system is the source of information about accounts and account groups, which will be read into IdentityIQ. Applications use a system-specific connector type (such as JDBC, LDAP, Active Directory, Azure, Workday, etc.) to set up a connection to the system that is the source of the data. The configuration options are flexible; many elements of the configuration depend on the connector type, but they all have several things in common: - **Connection parameters** – the information IdentityIQ needs in order to communicate with the data source. This typically includes a path to the data source and credentials for logging in/authenticating, but may include more. - **Account schema** – how IdentityIQ defines and organizes the data that is being read in. - **Correlation logic** – how IdentityIQ maps data from the source system to what is stored in IdentityIQ. For more information on configuring applications, see the **Connectors & Integrations** section on the [SailPoint Product Documentation portal](https://documentation.sailpoint.com/). ## What Data Is Aggregated? **Account aggregation** is the process through which account data from a configured application is read into IdentityIQ and stored in Link (account) objects connected to Identities. Aggregation is an integral part of every IdentityIQ installation. Account aggregation reads in information about identities, which typically includes: - **Account information** – the accounts the identity has on the system being aggregated. - **Entitlements** – the access the identity has on the systems that it has accounts on. - **From authoritative sources** – information about the identity, such as name, department, email address, etc. **Account Group** aggregation is used to create entitlements (managedAttributes) representing an application's group objects. See [Entitlement Catalog](https://documentation.sailpoint.com/identityiq/9.0/help/application_management/entitlement_catalog.html#entitlement-catalog). ## Authoritative and Non-Authoritative Data Sources The enterprise systems that provide information about identities and their access may be numerous, and information about identities may not always be synchronized across all systems. For this reason, some sources of data are designated as **authoritative** sources. An authoritative source is any repository for employee information for your enterprise that represents the primary and most trusted information about identities, such as a human resources application. This is in contrast to **non-authoritative** sources that may contain some accurate information about identities but is not considered the system of record for information about the identity itself. A simple example is when an employee's name changes – Pat Smith becomes Pat Jones. In this example, Human Resources will change the employee's name, and perhaps the email address, in an authoritative source, such as Active Directory. The changes then need to be propagated out to other accounts that the user has, such as JIRA, Sales Force, Outlook, etc. A system is designated as an authoritative source by checking the **Authoritative Application** flag in the application configuration for that source. For more information, see the [Using the Edit Application Page](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/index.html#using-the-edit-application-page). Note that your organization can have multiple authoritative sources. ## Partitioned Aggregation Partitioning can increase processing throughput and speed of data processing, by breaking operations into multiple pieces, or partitions, allowing data processing to split across multiple hosts, and across multiple threads per host. Aggregation is one of the areas in IdentityIQ where partitioning can be used to improve performance. Partitioned aggregation can occur at either the application level or the task level. ### Application Configuration for Partitioning Some connector types support partitioning at the application level. To use partitioning for account and account group aggregation, you must configure the application for partitioning, and enable partitioning when defining an account aggregation or identity refresh task. Application-level partitioning requires connector support and some use of partitioning statements to obtain mutually-exclusive data sets for parallel processing. This creates multiple connections to a target system and also spreads aggregation processing across the task servers. Partitioning is supported by many but not all connectors, and can be enabled as part of the application's configuration. The way partitioning is configured varies by connector. For the most current information about a particular connector's partitioning support, refer to the [IdentityIQ Connectors documentation](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) on SailPoint's documentation portal. ### Aggregation Task Configuration for Partitioning Task-level partitioning is an alternative when application-level partitioning is not available or is undesirable. This variation pulls data from the target system into IdentityIQ using a single connection and multi-threads the processing across the task servers. The best practice is to use application-level partitioning whenever possible, as it has superior throughput potential when compared to task-level partitioning or traditional single-threaded aggregation, which uses a single thread for both data source connection and data processing within IdentityIQ. Activating partitioning on an aggregation task only requires selecting the **Enable Partitioning** option in the task definition user interface page. This must be enabled for each aggregation task which will use partitioning, as this setting is disabled by default. In addition, you can configure the number of objects per partition. This option sets the maximum number of records to include in each partition. IdentityIQ divides the accounts from the data source into as many partitions as required to create mutually-exclusive segments, with each containing no more than the specified number of accounts. Only some tasks support partitioning: account aggregation, account group aggregation, identity refresh, identity request maintenance, propagate role changes, and system maintenance. ## Delta Aggregation Delta aggregation is the process of only aggregating accounts or account groups that have changed since the last aggregation. Delta aggregation can be run as an alternative to a full aggregation, which brings in all accounts or account groups, regardless of whether they are unchanged since the last aggregation. Using delta aggregation to bring in only the changes can be much faster than full aggregations, and can allow processes to occur at a much more rapid pace. The option to enable delta aggregation is set in the aggregation task. You can set this option in the tasks for aggregating accounts and for aggregating account groups. However, delta aggregation requires support by the connector; not all connector types support delta aggregation. ### Partitioning in Delta Aggregation Delta aggregation can in some cases support partitioning. Partitioning in delta aggregation relies on the connector having partitioning implemented; if the connector does not include partitioning functionality, the partitioning option will be ignored and delta aggregation will work in the default, singled-threaded mode. For the most current information about a particular connector's partitioning support, refer to the [IdentityIQ Connectors documentation](https://documentation.sailpoint.com/connectors/identityiq/landingpage/landingpages/identityiq_connectivity_landing.html) on SailPoint's documentation portal. For more information on aggregation tasks, see [Tasks for Aggregatio](#tasks-for-aggregation). ## Tasks for Aggregation Tasks drive the actual work of retrieving info from the data source. There is a task type for aggregating accounts, and a task type for aggregating groups. You use the task type as a template to set up your own specific tasks, and you can have many defined tasks for each type – for example, it typical to have a separate account aggregation task for each one of your source systems. You can also have more than one aggregation task for a given system – for example, one that runs daily to only pick up changes from that day [Delta Aggregation](#delta-aggregation), and a more thorough one that runs monthly to refresh *all* your data from that specific source. The aggregation tasks can be configured with options that determine which of the task's available actions are performed in the aggregation. An **Account aggregation task** is responsible for: - Reading the account data from the designated data source - Creating a Link object to represent the account or updating an existing Link object with any data changes for the account - Associating the accounts (Links) to an existing Identity in the system or creating new Identities to hold the accounts There are several additional options that an Account aggregation task can be configured to perform, such as: - Deleting any Links for accounts that no longer exist - Recalculating active scopes for the installation when scoping is enabled - Executing some of the Identity Refresh task options An **Account Group aggregation** task aggregates information about groups. Group aggregation can only be done for applications which have a group schema defined. IdentityIQ aggregates group data from one application at a time, repeating this process for each application specified in the aggregation task (in the "applications" parameter of the task). **Other tasks** make updates based on aggregated data, and therefore should be run after aggregation: - **Identity Refresh**: This task scans all identities to ensure that all identity information is up-to-date and accurate. Identity Refresh scans are also used to detect and report on policy violations, which may arise due to changes in account or group associations. - **Effective Access Indexing**: Effective Access is any indirect access that was granted through another object, such as a nested group, an unstructured target, or another role. This task indexes effective access so that it can be shown on a single view of an identity. For more information, see: - [Tasks](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/index.html#tasks-overview) - [Account Aggregation](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/task_types/acct_agg_task.html#account-aggregation) - [Account Group Aggregation](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/task_types/acct_group_agg_task.html#account-group-aggregation) - [Identity Refresh](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/task_types/identity_refresh.html#identity-refresh) - [Effective Access Indexing](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/task_types/eff_access_indexing.html#effective-access-indexing) # Activity Target Categories Use this page to create or edit target categories that point to the activity targets defined on your applications. A target is a specific object within a data source that is acted upon. For example, a target might be a machine name for a login action, or a file name for a create action. The targets specified here are used to populate lists on the Activity Search page. These targets can be grouped with targets specified on other applications to create categories of targets. For example, if you have inventory applications at three different locations and a procurement database on each, you can set each procurement database as a target, create a Procurement category, and then collect activity for all three procurement databases using a single activity search. # Correlation Correlation refers to how IdentityIQ maps data from the source system to authoritative identities stored in IdentityIQ. Correlation logic can be implemented in a variety of ways, including: - Through direct mapping of attributes – for example, the application's account attribute "mail" is mapped directly to the identity's attribute "email." - Using conditions that assign application accounts to existing identities by defining attribute conditions. For example, the root account on Unix typically does not have any identifying attributes that can help when trying to correlate it to an existing identity using direct attribute mapping, so you can use a condition, such as whether the identity is a Unix application owner, to drive the correlation. - Through rules – custom BeanShell rules let you create your own specialized logic for correlation. - Manually – the **Identity Correlation** feature lets you select an application, retrieve a list of all uncorrelated accounts for that application, then select a target identity to correlate the uncorrelated account to. See [Identity Correlation](https://documentation.sailpoint.com/identityiq/9.0/help/identity_management/identity_correlation.html#identity-correlation). For more information about correlation, see: - The [Correlation Tab](https://documentation.sailpoint.com/identityiq/9.0/help/application_configuration/configure/using_edit_application_page/correlation_tab.html#correlation-tab) in **Application Configuration** - [Identity Correlation](https://documentation.sailpoint.com/identityiq/9.0/help/identity_management/identity_correlation.html#identity-correlation) - In the Rapid Setup feature: [Account and Manager Correlation](https://documentation.sailpoint.com/identityiq/9.0/help/rapid_setup/using_rapid_setup.html#account-and-manager-correlation) and [Service Account and RPA Account Correlation in Rapid Setup](https://documentation.sailpoint.com/identityiq/9.0/help/rapid_setup/using_rapid_setup.html#service-account-and-rpa-account-correlation-in-rapid-setup) # Elevated Access IdentityIQ has the capability of protecting sensitive access with the Elevated Access feature. Administrators, application owners, or entitlement owners can classify specific roles or entitlements as having elevated access. Classifying a role or entitlement as allowing elevated access provides clear visibility to users when they request, certify, or approve the role or entitlement. When a role or an entitlement has elevated access, it is displayed with a badge (a check mark inside a shield icon) to alert the user to the elevated access status. This helps ensure that the item is treated with appropriate care. A property on these items makes it possible to include them in reports, to facilitate auditing and to help identify high risk areas. Audit activities can focus on this access by leveraging these reports. You can create workflows to handle elevated access items, by incorporating the "iiqElevatedAccess" property from a role or entitlement. ## Role Configuration 1. To add the elevated access flag to roles, navigate to **Setup > Roles**. Once at the Role Management screen, find the appropriate role that needs Elevated Access. 1. Scroll to the bottom of the Role Information and click **Edit Role**. 1. Select **Elevated Access**. 1. Click **Submit**. ## Entitlement Configuration 1. To add the elevated access flag to entitlements, navigate to **Applications > Entitlement Catalog**. Once at the Entitlement Catalog screen, select the appropriate entitlement. 1. Select **Elevated Access**. 1. Click **Save**. The following are locations where a user can see or edit elevated access: - Manage User Access - Access Reviews - Targeted Certification: Additional Settings - Identity Warehouse - Identity Details - Entitlement Catalog – Advanced Search - Role Editor - Entitlement Details Dialog - Role Details Dialog - Work Items - Role Search Criteria - Reports - Match List # Entitlement Catalog Note The terms "account group" and "application object" are used interchangeably in this document but have the same meaning. Some applications can have multiple application objects. An account group can be the name of one of those objects. Use the Entitlement Catalog page to view and manage all of your managed attributes including entitlements, account groups / application objects, and permissions. Managed attributes can be specific to one application or shared among multiple applications of the same type. Managed attributes can also be defined in multiple languages. A managed attribute is the value of an account attribute that has been promoted to a first-class object in the IdentityIQ database so the system can track other data related to these attributes, such as a description or an owner. Any attribute can become managed, but the most common attribute to be managed is one holding group memberships. ## What is Included in the Entitlement Catalog The Entitlement Catalog lists the managed attributes in your IdentityIQ instance. A managed attribute is indicated by checking the **Managed** box for the attribute, in the account schema on the Application Definition page. As accounts are aggregated, IdentityIQ detects the values for each managed attribute and promotes these to ManagedAttribute objects. For example, if Location is managed, and you aggregate three accounts with locations Austin, Dallas, and Houston, there will be three ManagedAttribute objects for those values. If the attribute is multi-valued, such as groups or memberOf, IdentityIQ creates one ManagedAttribute for each value in the list. The expectation is that most of the attributes that are managed are entitlement attributes, which usually means a group attribute. Because of this, the language in the product is oriented around the word *entitlement*. For example, we refer to "managing entitlements" and the "Entitlement Catalog." It is possible, however, to have managed attributes that are not entitlements, but it is unusual. Managed attributes that are also groups have additional features. If the connector supports group aggregation, IdentityIQ can import the definitions of those groups and store them in the ManagedAttribute object. Managed attributes for groups have editable tabs that contain the definition of the group that can, optionally, be used for provisioning. If a groups managed attribute is available for provisioning, any change made on the Object Properties tab is sent to a connector to modify the target application. Note The additional Object Properties tab is only available if Lifecycle Manager is installed and the Enable Account Group Management options was selected during Lifecycle Manager configuration. See the Lifecycle Manager [Configure Tab](https://documentation.sailpoint.com/identityiq/9.0/help/lifecycle_manager/lifecycle_manager_config.html#configure-tab) for more information. ## Requestable Attributes When Lifecycle Manager is enabled, items in the Entitlement Catalog can be flagged as **Requestable** by checking the Requestable option in the item's standard properties. The Entitlement Catalog shows a check icon in this Requestable column for all attributes that can be requested. See [Standard Properties Tab](#standard-properties-tab). ## Viewing the Entitlement Catalog To access the Entitlement Catalog, select **Applications > Entitlement Catalog**. From this page you can add new managed attributes and edit the existing manage attributes. You can also use this page to import lists of managed attributes into IdentityIQ or export them back out to other applications. | Column | Description | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Application | The application to which the managed attribute belongs. | | Attribute | The attribute (in the case of an Entitlement or Group) or target (in the case of a Permission) that the managed attribute represents. | | Display Name | Display name of the managed attribute. If no display name was defined, this field displays the value of the attribute. When an application has Elevated Access, the display name will have the Elevated Access icon next to it. | | Name | The raw attribute value for the managed attribute. This column is hidden by default. | | Type | The type of managed attribute that is shown. There are two types: Entitlement and Permission. However, entitlements can be marked with the boolean group property if they represent a group object type for the application. Since applications can have more than one group object type, the object type name, for example Group or Role, is shown here for those managed attributes. | | Description | The description for the locale that is specified in the combination box between the search area and the grid. | | Owner | The Identity who owns the managed attribute. | | Requestable | Any managed attribute that can be requested has a check icon in this column. | | Last Refreshed | The date and time that the managed attribute was last modified. This column is hidden by default. | ### Viewing Entitlement Details To see details of an entitlement, double-click it, or right-click it and choose **Edit**. The Edit view for entitlements includes these tabs. - [Standard Properties Tab](#standard-properties-tab) - [Members Tab](#members-tab) - [Access Tab](#access-tab) - [Classifications Tab](#classifications-tab) - [Associated Roles Tab](#associated-roles-tab) ### Standard Properties Tab The **Standard Properties** tab is common to all managed attributes, regardless of type. | | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Field** | **Description** | | Application | The application associated with the attribute. | | Type | Application object type. | | Attribute | This field is read-only when editing an existing managed attribute. This field has different behavior based on the selected type:- **Entitlement** -- this field is labeled **Attribute**, and the input is a suggest box populated with all attributes in the selected application's account schema. - **Group** -- this field is also labeled **Attribute**, but no input choice is provided. The attribute is set to the reference attribute defined in the application's group schema. - **Permission** -- this field is labeled **Target** and the input is a free-form text box. | | Value | This field is only displayed for groups and entitlements. This field is read-only when editing an existing managed attribute. For groups with provisioning enabled, this field contains information on how the value was derived. The attribute value represented by the managed attribute. | | Display Value | This field is only displayed for groups and entitlements. The value used to concisely represent this managed attribute in IdentityIQ. In many cases, this is the same as the value. Sometimes (when the value is an LDAP domain, for instance) this only contains a small, relevant portion of the value No provisioning is launched when this field is changed. | | Requestable | This option is only displayed if you have SailPoint Lifecycle Manager enabled. Indicates whether or not the entitlement can be requested from the Lifecycle Manager. | | Required End Dates & Times | Requires an end date and time on all access requests and approvals for this entitlement. When enabled, users requesting this entitlement must specify an end date, and approvers must approve the request with an end date. For more information, see [Configuring Temporary Access for Entitlements](#configuring-temporary-access-for-entitlements). | | Maximum Access Request Time | Specifies the maximum duration for which a user can request access to this entitlement. The user cannot select an end date and time that exceeds this limit. This duration is calculated as the difference between the requested end date & time and the start date & time. If no start date and time is specified, the current date and time is used. For more information, see [Configuring Temporary Access for Entitlements](#configuring-temporary-access-for-entitlements). | | Elevated Access | When editing an entitlement, select Elevated Access to display when an entitlement has this feature. | | Description | A localized description. You must Save the description before changing languages to enter another description. Use the language selector to enter description in multiple languages. The dropdown list displays any languages supported by your instance of IdentityIQ. The description displayed throughout the product is dependent on the language associated with the user's browser. If only one description is entered, that will be the description used by default. | | Owner | The owner of the managed attribute. No provisioning is launched when this field is changed. | | This tab might contain additional extended attributes that were defined as part of the configuration process. Extended attributes only apply to IdentityIQ's representation of the managed attribute and no provisioning is launched by them. | | ### Members Tab This is a read-only tab that lists all of the Identities with detected roles with profiles that match the edited managed attribute. This tab only pertains to Group type managed attributes. ### Access Tab This is a read-only tab that lists any effective access for the entitlement. ### Classifications Tab This tab lists any classifications that have been assigned to the entitlement. Classifications flag and categorize entitlements, most typically to identify entitlements that permit access to sensitive or protected data such as financial, personal, or health-related information. You can also add and remove classifications on this tab. To add classifications to the entitlement, choose the entitlement(s) from **Assign Classifications to this Entitlement** and click **Add**. You can add as many classifications to the entitlement as you wish. To remove classifications from the entitlement, check the classifications to remove, then click **Remove Selected**. For more information, see [Classifications](https://documentation.sailpoint.com/identityiq/9.0/help/classifications/index.html#classifications). ### Associated Roles Tab The Associated Roles tab is included for any entitlement that is directly provisioned by a role. It lists the roles that directly provision the entitlement, showing the **Display Name** and **Description** of the role. For more information on Associated Roles and how they can help you visualize the relationship between roles and the access they provide, see [Understanding Relationships Between Roles and Entitlements or Permissions](https://documentation.sailpoint.com/identityiq/9.0/help/roles_groups_and_populations/roles/role_management_concepts.html#understanding-relationships-between-roles-and-entitlements-or-permissions) ## Adding or Editing Entitlement Parameters Note You can only add new managed attributes of type Entitlement. Open the **Edit** page by clicking **Add New Entitlement** or clicking on an existing managed attribute from the list. The Edit page enables you to change properties on a managed attribute. The title and content of this page varies depending on the type of attribute being edited. The **Save** button at the bottom of the page launches a business process that persists the changes to the managed attribute. If necessary, the business process launches provisioning. By default, changes to entitlements must be approved. See [Approvals for Changes to Entitlements](#approvals-for-changes-to-entitlements). ## Approvals for Changes to Entitlements Beginning with version 8.2 of IdentityIQ, the default behavior is to require an approval when an entitlement is changed. The approval path is managed by the **Entitlement Update** business process. This business process identifies an **approver**, which by default is the owner of the entitlement. If no owner has been specified for the entitlement, the approval is routed to the **fallback approver**, which by default is the owner of the application that is the source for the entitlement. ### Disabling Approvals for Changes to Entitlements If you don't want to require approvals for changes to entitlement, you can edit the business process to disable approvals: 1. Click **Setup > Business Processes**. 1. Select the **Entitlement Update** business process. 1. Click the **Process Variables** tab. 1. Edit the **approver** variable to set the **Initial Value** to **String**. Make sure that the **Value** field is blank. 1. **Save** the change. Note that if you reopen the **approver** value to verify your changes, no type of **Initial Value** will show as selected. 1. Edit the **fallbackApprover** variable in the same manner, changing **Initial Value** to **String** and making sure the **Value** field is blank. 1. **Save** your change. For more information on IdentityIQ business processes, see [Business Processes](https://documentation.sailpoint.com/identityiq/9.0/help/business_processes/index.html). ## Configuring Temporary Access for Entitlements You can define when an individual user's access to an entitlement ends. This feature offers an efficient, automated way to grant access to sensitive entitlements or entitlements that for any reason are intended to have a limited access duration. To support this, you can require an end date and time for entitlement requests and also define a maximum duration for which users can request access. When specified, users requesting the entitlement must specify an end date and time. The approvers must validate the request with the required end date and time. Before you begin, enable the start and end dates on entitlement assignment as follows: 1. Go to **Admin** **> Global Settings > IdentityIQ Configuration**. 1. On the **Roles** tab: - Under **Role Start/End Dates**, select the **Enable Start/End Dates & Times on Role and Entitlement Assignment** checkbox. - Under **Business Processes**, select a business process in the **Scheduled Role/Entitlement Assignment** dropdown list. When the access start date is in the future, this business process assigns the entitlement to the user on the specified start date. A standard business process, **Scheduled Assignment**, is provided by default. However, you can implement a custom business process as required. 1. Save your changes. To make the end date required and specify a maximum access duration for an entitlement, perform the following steps: 1. Create a new entitlement or edit an existing entitlement. 1. In the **Standard Properties** tab, under **Access Start/End Dates & Times**, 1. To make the end date and time required for entitlement requests, select the **Require End Dates & Times** checkbox. 1. To specify the maximum access duration a user can request for this entitlement: 1. Select the **Maximum Access Request Time** checkbox. 1. Specify the duration in hours, days, weeks, or months. The default duration is 1 day. This duration is calculated as the difference between the requested end date & time and the start date & time. If users do not specify a start date and time, the limit is calculated from the current date and time. The users cannot select an end date and time that exceeds this limit. 1. Select **Submit** to save your changes. For more information, see [Specifying Access Start and End Dates with Time](https://documentation.sailpoint.com/identityiq/9.0/help/lifecycle_manager/manage_user_access/access_start_end_dates.html). ## Deleting a Managed Entitlement To delete an entitlement, right-click on the entitlement and choose **Delete**, then confirm the deletion. Deleting a managed entitlement does not directly remove the entitlement from the product. Instead, a group update business process is launched as a task. You can track the progress of this task on the **Setup > Tasks > Task Results** tab. ## Importing and Exporting Managed Attributes Use the **Import** and **Export** buttons to import new managed attributes from a CSV file, or to export existing managed attributes to a CSV file. Each option opens a dialog with instruction on how to continue. ### Defining Import Data The import data file must be in a CSV format, with a comment line at the top of the file to define the contents. The comment line should contain set of comma-separated of values, to define the properties corresponding to the values on subsequent lines. The imported Entitlements' properties will be set accordingly. Here is an example of a comment line defining the properties of a CSV file: `#value`, `displayName`, `owner`, `application` The properties on this line can be any of the following: - application - attribute - value - displayName - requestable - owner - classifications - iiqElevatedAccess ### Specifying Default Values When Importing Entitlements You can specify default values for the imported Entitilements' properties by including an assignment statement in the comment line that defines the file's contents. Here is an example of an assignment statement in the comment line: `#application=Active_Directory` ### Special Considerations for Importing Descriptions When importing attribute descriptions, you must include the description's locale(s) in the comment line; use locale(s) instead of the `description` property to ensure that descriptions are imported correctly. Here is an example of a comment line that includes US English (en_US) and Canadian French (fr_CA) descriptions: `#type, attribute, en_US, fr_CA` You can also get an example of this formatting by exporting existing data, and including languages in your export. . To export a file that includes an example of the description format: 1. Go to the Entitlement Catalog page, **Applications > Entitlement Catalog**. 1. Select **Export**. 1. Choose either **All Applications**, or uncheck the **All Applications** box and choose one or more specific applications from the dropdown list. 1. For **Export Type**, choose **Descriptions**. 1. Use the **Choose description languages to export** dropdown to choose the locale(s) you want to include in the export. The list shows all locales that have been enabled in your installation. 1. Select **Export**. Note There might be a size limit set on the imported entitlement description during the configuration of IdentityIQ. If you run into issues, contact your administrator. A message is displayed at the bottom of the browser window when the export is complete. From there, you can view or save the exported descriptions. For more information on locales and enabling multi-language descriptions in IdentityIQ, see the IdentityIQ Configuration [Miscellaneous](https://documentation.sailpoint.com/identityiq/9.0/help/system_configuration/identityiq_global_settings/identityiq_configuration/miscellaneous.html#miscellaneous) section. # Supporting Active Directory Native Move or Rename In many places in IdentityIQ, the default identifier for Active Directory accounts and groups is Distinguished Name (DN). Some native changes, such as when an account or group is moved within the Active Directory OU or when a person's name changes, result in a change to the DN. Beginning with version 8.3, IdentityIQ uses the Active Directory GUID, a globally unique identifier, to determine when an account or group object's DN has changed. When a change is detected, the object is updated, and the change is propagated to all DN references throughout IdentityIQ. When a changed DN is updated on aggregation, IdentityIQ creates an event to propagate the changes to these areas: For account groups: - Bundle/Profile - Policy - Form - Rule - GroupDefinition - Identity - Dynamic Scope - PasswordPolicy/PasswordPolicyHolder - Widgets For accounts: - Form - Rule - GroupDefinition - Identity To process the event, a Native Identity Change Propagation Request is created, which propagates changes to the appropriate destinations based on the event type. After all propagations to the destinations have completed successfully, the event is marked as DONE. If the event fails for any reason, the event and request are both marked as FAILED. Note Failed events can be restarted or pruned from your system using the Reset Failed NativeIdentityChangeEvents task. For more information on using this task, see [Reset Failed NativeIdentityChangeEvents](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/task_types/reset_failed_native_events.html#reset-failed-nativeidentitychangeevents). If a DN has been updated in response to a native move or rename, the DN is also replaced with the new one in the Provisioning plan at provisioning time, to ensure that there will be no errors on provisioning. ## Disabling the Propagation of DN Changes The propagation behavior is enabled by default. If you want to disable it, to prevent the propagation of changes throughout IdentityIQ, follow these steps. 1. Navigate to **gear icon > Global Settings > IdentityIQ Configuration > Miscellaneous** tab. 1. In the **Native Identity Change Event Propagation Settings** section, uncheck the **Enable Native Identity Change Event** propagation checkbox. 1. **Save** your changes. ## Customizing How DN Changes Are Propagated System administrators can customize the areas where DN changes are propagated by editing the **Native Identity Change Propagation** object in the Debug pages. This object is a **Request Definition** object. ## Rename Detection in the Account Aggregation Task The Account Aggregation task includes an option to **Enable rename detection on managed attributes**. This option affects aggregation from Active Directory. It enables IdentityIQ to detect when an account group DN has changed due to being renamed. IdentityIQ determines whether a DN is new or is a rename of an existing DN, by examining the relevant account group's GUID or UUID. Enabling this option can prevent unintended changes to access that is based on assignment rules which use DN as assignment criteria. Note that when a change is made in Active Directory to an OU which contains accounts or groups (such as renaming or moving it), a delta aggregation does not pick up the changes. This is due to a limitation in Microsoft DirSync Control.To avoid this issue, perform a full aggregation to capture the changes and update the child objects. You might have to do this regularly to ensure the data is up to date. For more information, see [Account Aggregation](https://documentation.sailpoint.com/identityiq/9.0/help/tasks/task_types/acct_agg_task.html#account-aggregation). ## Handling Duplicate Distinguished Names in Active Directory During aggregation, if IdentityIQ detects two Active Directory accounts or account groups with the same Distinguished Name but different UUIDs, it will update the UUID to the most recent value, and treat the two accounts or account groups as the same. This handles the case where an account or group is accidentally deleted and re-added. Consequently, it is not advisable to reuse the same DN with a different meaning. IdentityIQ will not detect this as an account or account group change to any attribute but UUID. ## Handling Future Actions If there are future actions that may be impacted by a DN move or rename, such as a end date on an entitlement, or a mitigation end date for a policy violation, be cautious about pruning events. Otherwise, if a DN changes for an account included a start / end action, IdentityIQ may not perform the provisioning action because it will contain the "old" DN. This is particularly important for dates far in the future. In policy violation mitigations, if the DN on an account changes during the mitigation period, the next time Check Policy Violations is run, the policy violation can reappear and need to be mitigated again. ## Pruning Native Identity Change Events in the System Maintenance Task You can also use the System Maintenance task to prune Native Identity Change Events. Use the Prune Native Identity Change Events to include this action as part of your system maintenance task. This task will prune events that are older than the age specified in your system configuration. The age value is set in the `` key in your system configuration. The value is the age, in days, of events to be pruned. Note that a value of zero means that no events will be pruned, ever. Important Events that are processed successfully are retained in your IdentityIQ instance. Use this task and option to prune all events, not just failed events. ## DN Changes Initiated within IdentityIQ Changes made to Distinguished Name that are initiated within IdentityIQ (for example, through Rapid Setup or customizations) result in appropriate updates to all IdentityIQ objects. These changes are not treated as new identities, but are recognized as moves or renames. A `"noCustomRenamePropagation"` argument can be set to true in the provisioning plan to disable this functionality. # Business Process Management A Business Process is a sequence of operations or steps that are launched to perform work. IdentityIQ Business Processes include standard out-of-the-box processes and custom installation-specific processes. The informal term **workflow** is also used in this document to refer to a business process. System events trigger both standard and custom IdentityIQ Business Processes. Events that can trigger a workflow include: - Role creation or modification - Account Group creation or modification - Identity update - Identity refresh - Identity correlation - Deferred role assignment, de-assignment - Deferred role activation, deactivation - Any Lifecycle Manager event - Any Lifecycle Event (marked by changes to an Identity's attributes) Custom workflows can be defined to do a wide variety of processing tasks. You can use: - IdentityIQ workflow library methods and rules. - Custom BeanShell scripts and rules. Customizing or creating workflows generally involves a combination of XML and Java / BeanShell programming. You can manage some customization activities with the IdentityIQ graphical process editor that is included in the product. To customize or create new workflows, typically you need to be comfortable writing XML and Java. - [Workflow Basics](https://documentation.sailpoint.com/identityiq/9.0/help/business_processes/workflow_basics.html#workflow-basics) - [Using the Business Process Editor with Workflows](https://documentation.sailpoint.com/identityiq/9.0/help/business_processes/using_bp_editor_workflows/index.html#using-the-business-process-editor-with-workflows) - [Editing Workflow XML](https://documentation.sailpoint.com/identityiq/9.0/help/business_processes/editing_workflow_xml.html#editing-workflow-xml) - [Workflow Library Methods](https://documentation.sailpoint.com/identityiq/9.0/help/business_processes/workflow_library_methods.html#workflow-library-methods) - [Monitoring Workflows](https://documentation.sailpoint.com/identityiq/9.0/help/business_processes/monitoring_workflows.html#monitoring-workflows) - [Advanced Workflow Topics](https://documentation.sailpoint.com/identityiq/9.0/help/business_processes/advanced_workflow_topics.html#advanced-workflow-topics) # Advanced Workflow Topics This section includes these advanced Workflow topics: - Loops within Workflows - Launching Workflows from a Task or Workflow - Workflow Forms ## Loops within Workflows A loop occurs when a step transitions back to a step that executed previously. The state of that step is reinitialized and the step is executed again. A loop can transition back any number of steps. You define a loop transition the same way you would any other transition. However, you must just select a target step that appears before the loop transition in the process designer. In most case, when you create a loop transition, you want to give it a conditional *When* expression. If a loop transition is unconditional, the workflow can enter an infinite loop and not be able to finish. ## Launching Workflows from a Task or Workflow You can launch workflows from tasks or other workflows without using a system event to trigger the workflow. ### Workflows Launched from Custom Tasks You can launch workflows from a custom task in IdentityIQ. Because tasks are compiled java classes, the custom task must be written as a Java method. To create a workflow from a custom task: 1. Create a WorkflowLaunch object in the Java method. 1. Populate the object with the data the workflow requires. 1. Use the *Workflower* class to launch the workflow. It is often necessary for one workflow to launch another workflow. This can be performed in Beanshell using code similar to the previous example. However, using the workflow library method *scheduleWorkflowEvent* is easier. Not only does this method launch a workflow, it also allows you to delay the launch until a time in the future. To have one workflow to launch another workflow, create a step and select scheduleWorkflowEvent as the action. This method requires the following arguments: ```text import java.util.HashMap; import sailpoint.api.sailpointContext; import sailpoint.api.Workflower; import sailpoint.integration.ProvisioningPlan; import sailpoint.integration.ProvisioningPlan.AccountRequest; import sailpoint.integration.ProvisioningPlan.AttributeRequest; import sailpoint.object.Identity; import sailpoint.object.Workflow; import sailpoint.object.WorkflowLaunch; import sailpoint.tools.GeneralException; import sailpoint.tools.xml.XMLObjectFactory; HashMap launchArgsMap = new HashMap(); String myIdentityName = "T339222"; Identity myIdentity = context.getObjectByName(Identity.class, myIdentityName); //Create Provisioning Plan and add needed attribute values ProvisioningPlan plan = new ProvisioningPlan(); plan.setIdentity(myIdentity); AccountRequest accountRequest = new AccountRequest(); AttributeRequest attributeRequest = new AttributeRequest(); accountRequest.setApplication("IIQ"); accountRequest.setNativeIdentity(wbIdentity); accountRequest.setOperation("Modify"); attributeRequest.setOperation("Add"); attributeRequest.setName("assignedRoles"); attributeRequest.setValue("Benefits Clerk"); accountRequest.add(attributeRequest); plan.add(accountRequest); //Add needed Workflow Launch Variables to map of name/value pairs launchArgsMap.put("allowRequestsWithViolations","true"); launchArgsMap.put("approvalMode","parallelPoll"); launchArgsMap.put("approvalScheme","worldbank"); launchArgsMap.put("approvalSet",""); launchArgsMap.put("doRefresh",""); launchArgsMap.put("enableRetryRequest","false"); launchArgsMap.put("fallbackApprover","admin"); launchArgsMap.put("flow","RolesRequest"); launchArgsMap.put("foregroundProvisioning","true"); launchArgsMap.put("identityDisplayName","John.Smith"); launchArgsMap.put("identityName","John.Smith"); launchArgsMap.put("identityRequestId",""); launchArgsMap.put("launcher","admin"); launchArgsMap.put("notificationScheme","user,requester"); launchArgsMap.put("optimisticProvisioning","false"); launchArgsMap.put("plan",plan); launchArgsMap.put("policiesToCheck",""); launchArgsMap.put("policyScheme","continue"); launchArgsMap.put("policyViolations",""); launchArgsMap.put("project",""); launchArgsMap.put("requireViolationReviewComments","true"); launchArgsMap.put("securityOfficerName",""); launchArgsMap.put("sessionOwner","admin"); launchArgsMap.put("source","LCM"); launchArgsMap.put("trace","true"); launchArgsMap.put("violationReviewDecision",""); launchArgsMap.put("workItemComments",""); sailpoint.object.ProvisioningPlan spPlan = new sailpoint.object.ProvisioningPlan(); spPlan.fromMap(plan.toMap()); launchArgsMap.put("plan", spPlan); //Create WorkflowLaunch and set values WorkflowLaunch wflaunch = new WorkflowLaunch(); Workflow wf = (Workflow) context.getObjectByName(Workflow.class,"myWorkflowName"); wflaunch.setWorkflowName(wf.getName()); wflaunch.setWorkflowRef(wf.getName()); wflaunch.setCaseName("LCM Provisioning"); wflaunch.setVariables(launchArgsMap); //Create Workflower and launch workflow from WorkflowLaunch Workflower workflower = new Workflower(context); WorkflowLaunch launch = workflower.launch(wflaunch); // print workflowcase ID (example only; might not want to do this in the task) String workFlowId = launch.getWorkflowCase().getId(); System.out.println("workFlowId: "+workFlowId); ``` ### Workflows Launched by Other Workflows Installations often have one workflow start another workflow using the scheduleWorkflowEvent method in the Standard Workflow Handler. One of the initiating workflow steps launches the method through a call action. Arguments to the step include the following: | Name | Value | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | workflow | Name of the workflow to launch. | | requestName | Name to be assigned to the request. If not specified, the name of workflow is the default. | | scheduleDate | Date and time you want the workflow to launch. Must be specified with a java.util.Date value. If this argument is not set, the workflow launches immediately. | | scheduleDelaySeconds | An alternative to using scheduleDate. When set, the value is the number of seconds to delay before launching the workflow. | | caseName | Specify a user friendly name for workflowCase to be displayed in the user interface. If no name is specified, the default is the name of workflow. | | launcher | Name of the identity to be displayed as the *launcher* of the new workflow case. If this argument is not specified, the launcher of the initiating workflow is used. | A workflow that is launched by another workflow is different from a workflow that is launched as a subprocess. If a workflow is launched as a subprocess, the calling workflow waits until the subprocess is completed. After the workflow returns control to the caller, the processing continues. A workflow that is launched by another workflow causes a completely separate workflow to begin launching. After the new workflow is started, the original or calling workflow moves on to its next step. ## Workflow Forms Standard work item forms are available for presenting approval or other data requests to approvers. However, some installations prefer to use custom forms for these activities. Based on the type of the data collection effort, a custom form might be required. You can build a custom form using a element in the XML that is embedded within the element. Note The element can be used to collect data from a user, even if the workflow is not an approval. You generally use custom forms for these activities because the normal approval forms do not apply. However, you can also use custom forms for traditional approval activities when you need a different presentation format. The basic elements in a Form definition are: ```text
(map of name/value pairs that influence the form renderer)