Workflow Types

Each workflow must have a specified type. The type determines which workflow libraries are available to it, and which activities it can be assigned to.

Default workflows have pre-defined workflow types. IdentityIQ uses these assigned types to determine which workflows to present in the Business Process configuration list boxes. Workflows can be specified to activate based on a specific system event.

For example, role create, update, and delete actions can trigger a RoleModeler type of workflow. Only workflows of that type are listed in the drop-down list for that configuration option.

Note: You can assign custom types to workflows. However, custom type workflows can only be triggered through the user interface on Lifecycle Events, which can trigger workflows of any type.

This table lists the workflow type associated with each type of action within IdentityIQ.

Process Type

Description

Policy Violation

Workflow activated to launch policy violation actions.

Batch Provisioning

Workflow activated to launch batch requests.

Scheduled Assignment

Workflow activated to when a role is ready to be assigned.

Scheduled Role Activation

Workflow activated when a role is ready to be enabled or disabled.

Managed Attribute

Workflow activated when an entitlement is created or edited.

Identity Correlation

Workflow activated when performing identity correlation tasks.

Identity Event

Workflow activated for identity event. For example, sunrise/sunset dates for deferred entitlement, role assignment, or role removal.

Identity Lifecycle

Workflow activated for Lifecycle events. For example, Lifecycle Event - Joiner or Lifecycle Event - Leaver.

Identity Update

Workflow activated when you update an identity through the Identity -> Identity Warehouse page. Typically requires few or no approvals.

Identity Refresh

Workflow activated for identities that are refreshed using the Identity Refresh task. This type of process can be used for additional customization during refresh, and to present provisioning policy forms if accounts need to be created as a result of automated role assignment.

LCM Identity

Workflow associated with Lifecycle Manager Identity related tasks, for example, LCM Create and Update.

LCM Provisioning

Workflow activated for Lifecycle Manager provisioning tasks.

LCM Registration

Workflow activated for registration tasks.

Policy Violation

Workflow activated to initiate policy violation actions.

Role Modeler

Workflow associated with Role functions. For example, Owner Approval and Role Activation.

Subprocess

Designation of a workflow which is part of a larger workflow.

Password Intercept

Workflow activated when a password change interception event is received.

Some complex workflows are divided into multiple sub-process workflows that are activated by a master workflow. Using sub-process workflows with a master workflow can:

  • Simplify the structure of the master workflow

  • Make workflows easier to manage

  • Promote re-usability because more than one master workflow can reference the same sub-processes

As a standard practice, these smaller workflows are assigned the Subprocess type of workflow. This type is not associated with any system functionality. However, using the Subprocess type designation enables you to easily identify the workflow as a sub-process of a larger workflow.

Transient workflows are launched in a special mode that does not persist any information to the database. A workflow remains in the transient state until the workflow reaches an approval step. If the workflow launches to completion without an approval step, nothing is stored in the database unless the browser terminates or the session times out the workflow and any progress made is lost.

Note: If the browser terminates or the session times out the workflow and any progress made is lost.

Examples of transient workflows include:

  • QuickLaunch workflows that can present a series of forms before performing any relevant actions.

  • Self-registration workflows that do not require authentication

  • Workflows for users trying the registration process, who do not have an inbox where they can see their past attempts

To create a transient workflow, add a variable named transient and set the value to true.

For transient workflows to work correctly, the user interface code needs to manage the workflow case in a special way, through a WorkflowSession.

The case persists when any of these things happen:

  • An approval for someone that is not the submitting user

  • A step with a wait='x' in it

  • A step with background='true'