This is not the latest version of Identity Director documentation.
View available documentation.

View service transactions

In the Management Portal at Transactions, view information about service transactions in your environment. A transaction is the entire process of the delivery or return of a service. It can have any of the following statuses:

Status

Explanation

Aborted

The transaction was aborted before completion.

Completed

The transaction has completed.

Expired

The transaction expired (one or more actions exceeded their expiration time).

Failed

The transaction failed to complete.

On Hold

The transaction is put on hold and the system is in fail-safe mode.

If you enabled the transaction safeguard in your environment, and one or more thresholds are exceeded, the system goes into "fail-safe mode". This puts the entire set of transactions “on hold”, and suspends further transactions. The Management Portal shows a clear warning that urgent attention is required, and the Transactions page lists the “suspect” transactions for review. You can troubleshoot the fail-safe mode by identifying whatever triggered it, and decide to continue regular operations or to abort the “suspect” transactions.

Pending

The transaction is in progress.

Unlicensed

The transaction did not start, because no licenses were available to service the subscriber.

If you have defined custom End Workflow states at Setup > General, these are displayed and can be selected on the Filter by dialog:

  1. Select the State for which your custom end state is an alias: Completed or Failed. The Custom state field becomes available.
  2. In the Custom state field, select your custom end state.

For more information about creating custom End Workflow states, see Configure the general behavior of the Web Portal.

Configuration

  • Click Pause Transactions to halt processing of transactions within seconds.
    When paused:
    • A Transactions paused message is displayed to all users of the Management Portal, on all pages.
    • New requests for services are not processed.
    • Pending workflow actions are not processed. Users can give input (for example: provide requested information), but that input will not take effect until transactions are resumed.
    • Messages in the Web Portal are not moved to Archive after the user has performed the requested action.
    Click Resume Transactions to restore normal operation.
  • Click Select all to select all transaction records, with the current filter taken into account. An indicator shows how many transactions are selected. This makes it easier to perform bulk operations like delete, retry or abort multiple transaction records.
  • Click Auto-refresh to refresh the page automatically every 10 seconds.
    • The auto-refresh functionality is disabled by default. Your selection is browser- and computer-specific: it is stored as a cookie on the computer from which you access the Management Portal. If, for some reason, you delete this cookie, the default behavior applies again.
  • The time in all transactions is UTC time.
  • Click Abort in the relevant transaction to abort a transaction that is in progress (Pending).
  • Click Retry in the relevant transaction to retry a failed or aborted transaction.
  • Click a transaction to view its details.
    • In the Transaction details page, the timeline shows which actions were executed in the course of the transaction.
      • Each action that is executed during a transaction is numbered. When you click an action, the right side of the Transaction details page automatically navigates to this action and become highlighted. For example, in complex workflows that contain a Jump action, this makes it easier to view how many times a Jump action was executed and why.
      • Failed actions are highlighted in red, which makes it easier to find out which actions failed and why.
    • When you view a transaction that contains an Invoke Run Book action and you have configured Automation redirection, at Setup > Ivanti Automation, click the Run Book name to open the Ivanti Automation Management Portal and view the Run Book.

Example 1

Consider the following scenario:

  1. Service A is configured to automatically request service B as part of its workflow.
  2. The user John Smith requests service A.
  3. Delivery of service A triggers the delivery of service B.

In this scenario, the request of service A is a user action, with John Smith logged as the requester. The request of service B is a system action, with System logged as the requester.

Example 2

Consider the following scenario:

  1. Service C is configured to be delivered as soon as someone qualifies.
  2. A data connection synchronization places the user Celia Jones in an organizational element that qualifies her for service C.
  3. Service C is delivered to her.

In this scenario, the request of service C is a system action, with System logged as the requester.

See also