Action Type

Scripts are java BeanShell code that you write in order to execute a desired action. You write scripts directly in the Source box in the detail window for the step.

Note: The script examples in this document all show very short java BeanShell code blocks. There is no set length for a script. A script block within the XML can be any length needed to accomplish the required processing. However, long scripts are frequently encapsulated in rules, as discussed in the next section.

Rules are also blocks of java BeanShell code. Code encapsulated in a rule is available for reuse by other areas of the application that can launch a rule of the same type. Rules created through this window are of type Workflow and can be used by any workflow. When you choose Rule as the Action, you can select an existing workflow rule from the list or create a new rule in the rule editor. To open the rule editor, Click the [. . .] icon.

Subprocesses are other workflows. You can use subprocesses to subdivide complex processes into smaller segments that can be easily managed and reused by other workflows. Subprocesses are complete workflows that contain a start step, a stop step, and as many processing steps as are needed to complete their activities.

You can enable step replication to enable multiple subprocesses to run to completion at the same time instead of having them run serially. For example, in an approval step, you can launch multiple approval subprocesses, to multiple approvers, that can take an approval all of the way through provisioning instead of the approval step waiting for all approvals to complete before provisioning can begin.

When you enable replication, you must select an item from the main workflow for replication and an argument that is passed to the action containing the replicated item. Only one item can be replicated per step, and all of the items must be passed the same argument. A new subprocess is generated for each item replicated.

The IdentityIQ workflow library contains a set of methods that you launch within a workflow. Methods are exposed through the standard workflow handler that the workflow engine calls every time an action occurs in a workflow. Every workflow has access to the methods in the standard workflow handler. Additional libraries of methods are also available to use in workflows.

Note: When no library list is specified for the workflow, the default includes access to the Identity, Role, PolicyViolation, and LCM libraries.

Through the XML, you can specify other libraries, including custom libraries for an installation. The user interface does not provide an option to manage the library list.

Note: Specifying a library list overrides the default. You must explicitly include in the library list any default libraries that contain methods the workflow needs. See Workflow Element for more details on specifying a library list.

When Call Method is selected for the workflow step, Action, the method name is selected from the Call Method list. The methods in these workflow libraries are listed and briefly described in Workflow Library Methods.

When steps are first added through the Process Designer, only three icon types are available: Start, Stop, and Generic Step. A variety of other icons are available. You can use different icons to make it easier to determine the actions each step performs.

To change an icon for a step:

1. Right-click the step icon and click Change Icon.

2. Select the desired icon style from the pop-up window.

Approval steps are a special type of step in IdentityIQ. You can use Approvals to gather data from a user through a work item. In an approval, the user is asked to review a requested action, such as, granting a role to an identity, and then give their approval for the action to be processed.

To create a basic approval through the user interface:

1. Right-click the step.

2. Click Add Approval.

Note: A step can contain an action or an approval, but not both. Approval steps are used for approval processing. Approval steps are not used to perform other actions such as scripts, subprocesses, etc.

To edit an approval that exists in a step

1. Right-click the step and click Edit Approval.

2. Alternatively, you can choose Edit Approval from the Step Details window.

Approvals are flexible and meet a variety of business needs. An approval can be constructed many ways. approvals range from a simple one-person approval to a complex approval process that involves multiple people with different approval modes and notification schemes.

Every approval includes the following fields to be completed on the Details tab for the approval:

You can set arguments to the approval on the Arguments tab. Generally, variables are passed to approval through the send list. However, any arguments that require transformation, through script, rule, or library method, must be sent through an Arg element. Args defined with reserved system names are passed through the Arg element with the reserved name specified. See Approval Steps for information on reserved system names.

You can specify some details about the notification and escalation / reminder policy for a work item on the Work Item Configuration tab. The work item appears in the owner's IdentityIQ inbox and requires their input. If no configuration is specified, the default work item configuration is used.

To change the configuration for the work item

1. Select Override Work Item Configuration.

2. To include an electronic signature in the approval step, select Override Electronic Signature Configuration.

The following configuration options are available on the Work Item Configuration tab:

Use Child Approvals to customize approval processing or presentation for the different sets of identities involved in the approval process. For example, a change in a user's assigned region requires someone in HR sign off and also requires manager approval. Although the approval of the user's own manager is required, any HR individual can completes the sign-off. This type of approval can be created through child approvals.

To create a child approval:

1. Click Add Child Approval on the Details tab for the parent approval.

2. Click the child approval in the Approval Children hierarchy to select it for editing.

To set up the approval described in the example, create two child approvals:

• HR Approval set up – any of the identities who meet the criteria can make the decision for the group

• Manager Approval set up – identity's manager specified as the owner.

Note: The reference variables HRApprovers and identityManager for the example are process variables defined with initialization scripts that retrieve the appropriate sets of Identities.

If either approval requires a custom work item configuration, you can specify the configuration on the Work Item Configuration tab for the approval. Work item configurations are inherited by child approvals if configurations are not specifically overridden for the child. If you want a single custom work item configuration for the entire set of approvals, the configuration should be specified on Work Item Configuration tab for the parent approval. In this case, the child approvals inherit the parent configuration.

An approval step can also display a form. Forms are a general way to request information from the user and do not necessarily represent an approval. For example, you can use forms to request a missing attribute such as the department name for an identity or ask the requester for more information about why they are making the request.

You can define a form inside the workflow step or you can reference an external form that is shared with other workflows.

To reference an existing form:

1. Right-click the step and click Add Form.

2. In the first screen, click Reference Form.

3. In the form reference screen, select a form from the table and select the owner who will be shown the form.

To create a custom form for gathering data from a user:

1. Right-click the step and click Add Form.

2. In the first screen, click Create.

3. In the form editor, specify the general form properties.

A form includes one or more fields that define what information you want to show and the information you are asking the user to provide. This form field editor is similar to the field editor for provisioning policies and uses most of the same options.

The form editor also provides the option to specify buttons to include on the form.

To add a button definition:

1. Click Add Button.

2. Select the button Action and specify a behavior of the button.

3. Specify addition button options as described in the table below, and click Save.

During initial form specification, defined buttons and fields are listed together in the left panel in the order they are added. If some buttons were added before some fields, the button can be intermixed. On the final form, buttons are always grouped together at the end of the form. When the Form Editor is revisited later, the fields are listed together first, in the order they were created, and then the buttons follow in the order they were created.

Note: Buttons can be reordered in the XML to display in a different order on the form.

Custom forms can also be created or edited through XML. Various advanced form options, such as sections, multi-column layout, are only available through the XML. See Forms for more information.

Normally when a transition is made into a step, the step action is executed. In some cases you might want the execution of the step to be optional. You can add a step condition to control whether or not the step action executes. Step conditions can also simplify transition lines in the process because you do not have to create many complex transitions to skip over steps. You can advance from one step to another and let the step conditions determine if the step is executed.

To edit the step conditions:

1. Right-click any process step.

2. Click Add Step Condition.

3. Specify addition button options as described in the table below, and click Save.

You can express conditions as any of the following:

Selecting the Negate option changes the evaluation to the opposite condition. For example, if the condition evaluates to False, the negate option changes it to True.

Steps are connected through Transitions. Transitions can connect one step to the next sequentially. Alternatively, steps can include evaluation statements that enable conditional processing, such as certain data conditions that can cause the workflow to execute Step A versus Step B.

To add a transition do the following:

1. Right-click the process step for starting the transition and select Start Transition.

2. Navigate to the process step for ending the transition, right-click and select End Transition.

3. Right-click the transition icon and select Edit Transition to set the condition.

4. To add additional conditions to this transition, repeat the process.

To edit the transition conditions:

1. Right-click the transition diamond

2. Click Edit Transitions.

3. Specify addition button options as described in the table below, and click Save.

A step can have as many transitions to next steps as needed. Transition conditions are evaluated in the order they are listed. The first transition that has no condition, or whose condition evaluates to true is taken. Use the up and down arrows in the transitions dialog box to reorder the transitions. As a recommended practice, the final transition should have no condition. That transition is taken when no other transition conditions are met. If a step only has transitions with conditions, and none of the conditions are met, the workflow ends.

Conditions can be expressed as any of the following:

Transition conditions must evaluate to Boolean values. If the value is true, the workflow moves to the step that the transition references. If the value is false, the next transition in the list is evaluated.

Selecting the Negate option changes the evaluation to the opposite condition. For example, if the condition evaluates to False, the negate option changes it to True.