Workflow Types

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.

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'