Sun Identity Manager Deployment Reference

Workflow Process Components Overview

Each workflow process is defined by one or more of the following components. These components are discussed at greater length below.

Workflow Activity

An activity is a single step in the workflow process. An activity can contain multiple components, including transitions, variables, and actions, but must contain start and end activities.

Neither start nor stop activities have associated actions. A start activity has one or more transitions to the activity that begins the process, but end activities should have no actions associated with them.

Workflow Action

A workflow action describes an operation that is performed within a workflow Activity. Each activity can contain multiple actions. Identity Manager provides the following types of actions.

Workflow Action Variables

Table 1–2 Workflow Action Variables

Workflow Action Variable  



(Optional) inherited from WorkflowComponent. Action names are typically null. 


Identifies each action by a unique numeric ID. This is currently the index into the action array of the activity. 


(Optional) Used to calculate a title for this action in the Workflow summary diagram. By default, the title is name, but this variable can include information such as variable values. 


Indicates whether the action is manual (flag). This value has priority over all other action type fields. 


Used to calculate the request string for a manual action’s work item. This text is displayed in the product interface, should be brief, and should clearly describe what is requested of the user (for example, Approve Role Engineering, Supply account ID, and Answer a question. If no request is supplied, Identity Manager uses the result of the title. If there is no title, Identity Manager generates a string based on the name and/or title of the Activity.


Used to calculate the requester string for a manual action’s work item. This text is displayed in the product interface. It should be the name of a user or administrator that is considered to be the originator of the request. When null, Identity Manager assumes that the requester is the subject that launched the workflow case. 


Used to calculate the description string for a manual action’s work item. This text is displayed in the product interface. It is typically larger than the request string. 


Specifies one of the following options:

  • For manual actions, defines the maximum number of minutes that Identity Manager waits for this action to be performed. If the timeout is reached, the workflow executor considers the action completed. Variables must be used to determine the control flow after a timeout

    The workflow engine sets the WF_TIMEOUT variable to true in the scope of this activity if the item was completed due to timeout.

  • Specifies an expression that yields a timeout value.


Specifies the root of the expression tree that defines the action. If this value is set, it takes priority over the subprocess, and application fields. 


Specifies one of the following options:

  • Specifies the name of a subprocess to invoke. This can either be an internal or external subprocess. If external, it can be a type-qualified name, for example, TaskDefinition:example or Configuration:example.

  • Specifies a rule that generates a subprocess name. The returned object can be a String or an ObjectRef. If a String, it can identify an internal or external process such as subprocess.


Specifies the name of an application that is to be called. This can either be the abstract name of a built-in application, or may be a fully qualified class name of a class that implements the WorkflowApplication interface. 

The names of the built-in applications are defined by WorkflowExecutor. 


If the action type is manual, this field must hold the name of the owner for whom the WorkItem will be created. 

It can be an Administrator name, or use variable reference syntax (for example, $(ADMIN_NAME)). 


Specifies an expression used to calculate the delegator string for a manual action’s work item. This text is displayed in the GUI, it should be the name of a user or administrator that is considered to be the delegator of the request. 


Specifies an expression that will calculate the work item name. Usually the name will be a randomly generated unique identifier, but in some cases it is desirable to pre-compute the name so that it may be used in email notifications, embedded in a URL that will jump directly to the work item. 


Specifies an expression that will calculate the work item name. Typically, the name will be a randomly generated unique identifier, but in some cases you might want to pre-compute the name so that it can be used in email notifications, embedded in a URL that will jump directly to the work item. 


Manual actions can define a form object that can be used by the work list application to prompt the user for the variables expected to be returned when the action is complete. 

There are three ways to specify a form: 

  • set a self-contained form in _localForm

  • set a reference to a form in _formRef

  • have an XPRESS rule that generates a name.


Specifies a reference to an object containing a Form to use when editing the work item for a manual action. 


Specifies a rule that will generate the name of a form or a Form object itself. 


For all action types, a list of arguments can be specified. These are similar to Variables, but they live in a different namespace, sort of like a local Action variable so you don’t have to worry about collision with variable names. 


A list of locally defined action variables used by manual actions. This is needed when iteration is being used. 


A list of declarations of action return values. This defines a mapping between variables defined within the action result, and variables defined in the activity/process. 

This needs more thought, but its the only reasonably simple way I could come up with to perform the mapping without having variable chaos, or introducing path expressions to reference variables created in other scopes (for example, activity.action.variable) 


Specifies an object that defines optional iteration settings for the action. 


Specifies a list of result declarations for this action. 


Indicates that the action is to be hidden from the workflow summary diagram. (Boolean) 


Specifies an optional conditional expression. If this is set, the value of the expression must be true, in order to execute the action, if false, the action is ignored. 


Indicates whether the action will be run. When true, the action will be run only if the value of WF_ACTION_ERROR is null. This is shorthand for a very common <Condition>. 


(Optional) Contains arbitrary comments. 


Indicates that the WorkItem created for a manual action should have the synchronous execution flag set. As a result, when the owner checks in a change to the work item, the workflow should be advanced synchronously rather than scheduled for background execution. 

This is true for “wizard” style workflows where a workflow controls a sequence of pages. 


For manual actions, lists the variables that are to be included in the work item. The names can be GenericObject path expressions. If this list is null, then all variables are included. 


Lists variables that can be edited in the work item and assimilated back into the case (manual actions only). If this list is null, then any variable in the exposedVariables list is considered editable. If exposedVariables is null, then all workflow variables are editable.

Use to avoid collisions where many variables must be exposed to multiple approvers, but each approver is allowed to modify only a subset of the variables. 


Lists variables that contain views. Inclusion of a view on this list causes Identity Manager to refresh the view when the work item is refreshed. 


Typically, when a work item times out and is deleted while the user is viewing or editing the item, Identity Manager throws an exception and displays an error page. Occasionally, though, Identity Manager uses a work item only to display (not edit) summary information. These work items can have a short time-out to allow the workflow to continue processing. 

Setting this option to true causes the Work Item View handler to avoid throwing an exception. It does not affect the behavior of the process. 


Specifies an authorization type to be assigned to the WorkItem that is created for a manual action. Use this variable if you want work items to be authorized differently (for example, granting someone the rights to approve Resource requests but not Organization request.). 


Specifies a user-defined type name for the WorkItem created for a manual action. Use this variable to assign custom categories of work items (for example, “approval” or “wizard”). 


Optional. Contains the Identity Manager ID of the object being acted on by the work item. 


Optional. Contains the Identity Manager Name of the object being acted on by the work item. 


Optional. Contains the objectclass name of the object being acted on. 

What is an Application Action?

Application actions permit you to invoke more complex Java calls than you can invoke with script actions.

What is a Manual Action?

A manual action is part of the workflow process definition that defines a manual interaction. When the Workflow Executor processes a manual action, Identity Manager creates a WorkItem object in the Repository. The work item must be marked complete before the workflow can proceed. You must associate an owner with a Manual Action. An owner can be an expression that determines an owner.

Because most manual actions are used to solicit approvals, the work item table is located under the Approvals tab of the Administrator Interface. Any manual action that belongs to a workflow is represented by a WorkItem object in the Repository. The WorkItem view contains a few attributes that pertain to the WorkItem object itself, as well as values of selected workflow variables copied from the workflow task. These include attributes, such as owners of pending approvals, and the form used to approve the WorkItem. Identity Manager incorporates ManualActions in the standard workflow and allows approvals for organizations, roles, and resources.

You can assign a time-out to a manual action.