Skip to content

Workflow Basics

This section contains some key concepts for developing and using workflows. Topics include:

  • Terminology(LINK IN DOC)

  • Important Workflow Objects(LINK IN DOC)

  • Workflows Operation(LINK IN DOC)

  • Triggering Workflows(LINK IN DOC)

  • IdentityIQ Default Workflows(LINK IN DOC)

Terminology

The terms business process and workflow are used synonymously in IdentityIQ and throughout this document.

The IdentityIQ user interface refers to these sets of connected actions as business processes, which is the term that business managers often use. System implementers and users working in the object model typically use the term workflow.

Important Workflow Objects

The IdentityIQ Object Model uses four key objects in workflows. To work with workflows, you need a basic understanding of these objects.

Note

The most important object for writing workflows is the WorkflowContext object, which tracks the launchtime state of the workflow and performs other critical functions. Because WorkflowContext methods are used in workflows, data can be extracted from it as needed within any step of the workflow.

Object Usage
Workflow Defines the workflow structure and steps involved in the workflow processing.
WorkflowCase Represents a workflow in progress. Contains a workflow element in which the process is outlined and current state data is tracked. Contains identifying information about the workflow target object.
WorkflowContext Tracks launchtime information the Workflower maintains as it advances through a workflow case. Passed into rules and scripts and to the registered WorkflowHandler. Contains all workflow variables, step arguments, current step or approval, workflow definition, libraries, and WorkflowCase.
TaskResult Records the completion status of a task, or in this case, the workflow.\
Contained within the WorkflowCase.

Workflows Operation

Note

If multiple identities are modified at one time in a way that requires a workflow to launch for all of the identities, a separate workflow case is created to track the processing of the workflow for each single identity.

Workflows carry out a sequence of defined actions based on a triggering event and can be used for a variety of activities within the system. In its launching state, a workflow is tracked through a workflow case, which manages only one target entity at a time (one identity, one role, one provisioning plan, etc.).

Provisioning Plans in Workflows

A provisioning plan contains a list of requested changes to an identity. Most workflows that change identities contain a single provisioning plan in a workflow variable. When performing Workflow customization you commonly need to inspect and sometimes need to modify the provisioning plan.

Note

Customization rules might run multiple times, updating the same ResourceObject. For example, once for the provisioning result, once for the result in the provisioning plan, and once for the result in the account request.

Note

Only one provisioning plan can be referenced in a workflow case at a time.

When you request changes for more than one identity at a time, even if the same change is requested for all the identities:

  • A separate provisioning plan is created for each identity.

  • A separate workflow case is created to manage the provisioning plan created for each identity.

Triggering Workflows

Note

You can also configure an IdentityIQ task to trigger a workflow. This workflow set up is a more complex process. See Advanced Workflow Topics .

Events that occur in other parts of IdentityIQ and changes to attributes can trigger Workflows. Common Workflow triggers include:

  • Lifecycle Manager Actions – Requests to change an identity's roles, entitlements, or accounts can activate workflows.

  • Lifecycle Events – Creating an identity, deactivating an identity, or moving an identity from one manager to another manager can activate workflows.

  • Non-Lifecycle Events – Editing a role, editing an account group, and changing a password can active workflows.

  • Identity Attribute Change – Value changes can activate workflows.

  • Policy Violations – A policy violation can activate workflows.

This table lists the main areas of IdentityIQ where you can associate Workflows to system activities.

Workflow Trigger IdentityIQ Setup
Lifecycle Manager Requests Select Lifecycle Manager from the gear icon menu and go to the Business Processes tab.
Lifecycle Events Select Lifecycle Events from the Setup menu and specify the business process behavior.
Non-LCM-related Events Linked to triggering events. Select Global Settings from the gear icon menu and go to the IdentityIQ Configuration page. Select the Identities, Roles, or Miscellaneous tab and then select a business process.
Identity Attribute Change Configured with a Value Change Workflow. Select Global Settings from the gear icon menu and go to the Identity Mapping page. Click an attribute to edit or add a new attribute. On the Edit Identity Attribute page, go to the Advanced Options > Value Change Workflow option to select the business process.
Policy Violation Select Policies from the Setup menu, select or create a new policy, and specify the business process behavior.

IdentityIQ Default Workflows

IdentityIQ is preconfigured with various standard workflows that manage activities. The following workflows are examples of default workflows that are included with the product:

  • Provisioning of roles or entitlements

  • Account management

  • Identity creation

  • Password management

The default workflows can be configured and customized to address the specific business requirements of each installation. Additionally, you can write new workflows and apply them to any of the actions in IdentityIQ that support workflows.

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 predefined 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 dropdown 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.

Workflow Types and Associated Actions

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, start / end 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.

Sub-process Workflows

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

  • Simplify the structure of the master workflow

  • Make workflows easier to manage

  • Promote reusability because more than one master workflow can reference the same subprocesses

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 subprocess of a larger workflow.

Transient Workflows

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'