Identity Refresh

Provisioning workflows generally includes an Identity Refresh step than can be enabled or disabled as needed for the provision activity. To perform an identity refresh to update Identity Cube, you must:

• Include an Identity Refresh step in the Workflow

  Or

• Run an Identity Refresh task after the Workflow completes

To enable the Refresh step in the workflow the doRefresh variable must be set to True.

General Guidelines

Direct Read-write connectors – for Direct read-write connectors that process requests immediately, the Identity Refresh step is generally enabled. The changes to application accounts that the connectors make are usually displayed immediately in IdentityIQ.

Queued Requests – requests that were queued are not applied to Identity Cube until a reaggregation has occurred from the application involved. As a result, the Identity Refresh step is typically disabled for provisioning workflows that are managing integration configuration-driven provisioning activities, because the refresh can not detect any changes until after an aggregation from the source system.

Items that were processed as Work Items from the unmanaged plan are treated as queued requests, because manually closing a Work Item does not necessarily indicate all the work was completed. To confirm that the request was processed, you must perform a reaggregation from the source system. This aggregation must be followed by an identity refresh to update Identity Cube with the information.

Because the Application Accounts tab for Identity Cube displays account data that is recorded on the Link object for the identity, the tab lists the provisioned access immediately following the read-write connector commit or following a reaggregation from integration configuration-managed applications. However, the entitlement data on the Entitlement tab and in any certification is not updated until the Identity Refresh task has run.