Manage Provisioning Transaction Results

This feature can be disabled and might not appear in your instance of IdentityIQ. Contact your system administrator for details.

Use the Provisioning Transactions table to view the status of all provisioning transactions in your implementation of IdentityIQ: connectors, manual work items, and IdentityIQ operations.

To access the Provisioning Transaction table, click the gear icon > Administrator Console > Provisioning.

Four pages of data are available for review: All, Failure, Success, and Pending. The first page (All), which is displayed by default, shows all logged provisioning transactions. The other three pages display transactions which ended in failure, success, and pending statuses (retry) respectively, depending on the logging configuration, which is described in the section below.

Managing the Contents of the Provisioning Transaction Table

By default, the Provisioning Transaction table only displays transactions that have resulted in a failure condition, but it can be configured to display all provisioning transactions which are processed through IdentityIQ.

To change this default, change the logging level for Provisioning Transactions:

1. Click the gear icon > Global Settings > IdentityIQ Configuration > Miscellaneous.

2. In the Provisioning Transaction Log Settings section, change Maximum Log Level to Retry or Success.

   • Retry means the system will log provisioning transactions that return a Failure result or a Retry result (an error message indicating a temporary condition that means a later retry of the provisioning operation will likely succeed and should therefore be auto-retried after a delay interval).

   • Success means the system will log all provisioning transactions, regardless of their provisioning result status values.

   • Days before provisioning transaction event deletionNote.

3. Optionally, set a Days before provisioning transaction event deletion value. If you set the Maximum Log Level to Success, the provisioning transaction log will record high volumes of records.Therefore, it is particularly important in that case to also set the Days before provisioning transaction event deletion value to the number of days you want to retain these records so they will be automatically purged after that time. Leaving this value as the default "0" means these records will never be deleted, which can fill your database quickly. Even when using a Retry or Failure maximum log level, this value should be set to purge records you no longer need.

4. To turn off provisioning transaction logging entirely, clear the Enable Provisioning Transaction Log box.

5. Save your changes.

Use the tabs at the top of the table to limit your view by transaction status: All, Failure, Success, or Pending. Use the Filter options or search field to further limit the transactions displayed.

Reporting on Provisioning Transactions

Use the report/download button to launch a Provisioning Transaction Object report in the background. From the Report Launched window, you can click Get Email Notification to receive an email when the report is complete, or View Report to display the Report Results page.

The information on this page is also available in two reports available from the Intelligence > Reports menu: the Provisioning Transaction Object Report and the Detailed Provisioning Object Report. See Provisioning Transaction Object Report and Detailed Provisioning Transaction Object Report for more information.

Click the information icon for any transaction to view detailed information. The Transaction Details window displays all available details about the selected provisioning transaction, including attribute-level information about the request and any applicable error messages.

The Transaction Details window provides very detailed information, including the reasons for a Failed or Pending status. After viewing, you can take the appropriate actions to correct the reasons for the failure or delay.

Forcing Retries for Retryable Errors

Retryable errors are recorded as Pending transactions in the Provisioning Transactions table. Though these transactions will automatically retry after a configured interval, an administrator can override the retry interval and force a transaction to retry immediately. For example, suppose a network error causes a retryable error. Ten minutes later, the problem is fixed but the wait period on the retry is set for the transaction to retry after two hours. The administrator can speed up the process by forcing the retry to occur immediately after the network issue is resolved.

For any Pending transaction, a Retry button is shown in the Actions column. These retryable transactions appear on both the All page and the Pending page, and can be forced to retry from either page.

To force an immediate retry of a pending transaction, click its Retry button. The Retry Launched pop-up window appears, confirming that the retry has begun.

Failed transactions cannot be retried; you must use the override option to create a new work item for those transactions.

Overriding Failed Transactions with Manual Work Items

Transactions which appear as Failures are considered permanent failures and will never be retried automatically by the system. Likewise, they cannot be forcibly retried from the Provisioning Transactions table user interface. However, they can be reprocessed manually by creating a manual work item assigned to a person to complete the request outside of IdentityIQ's automated operations. In short, the transaction reprocessing is done just as if it were a provisioning request for a disconnected system (an application with no automated provisioning channel from IdentityIQ).

The administrator can view failed transactions on the All and Failure pages. To reprocess a failed transaction through a manual work item, click Override in the Actions column.

Next, choose the user to whom the manual work item should be assigned, and enter comments to communicate with that person; the comments are included in the manual work item. The choices for assignee are the Application Owner for the target application, yourself, or Other (another user). If you choose Assign to Other, you will be prompted to select the target user from a list.

Finally, click Override on this pop-up window to complete the failure override process and generate the manual work item. An Override Success message appears , confirming that the override has been completed and the manual work item has been generated.

The original transaction remains in the Provisioning Transactions table with a Failure status, for historical information purposes, though it no longer offers the Override option because the override has already been done. A new Provisioning Transactions table entry gets created for the override manual work item. Both the new manual record and the failed auto record reflect the umber, so they can be connected through that information as needed.