Step Elements

The transition element indicates the name of the next step the process executes following completion of the current step and is always nested within a step in the model. Transitions can contain conditions based on a string, script, rule, call method, or reference (similar to a variable initialization). The return value for conditions must be a Boolean (True / False). When multiple transitions are stipulated, they are evaluated in the order they are listed, and the transition for the first condition met is followed. The last transition in the list should, as a best practice, not contain any conditions so it can be used as the default action.

Transitions contain two attributes:

• to – next step

• when – condition for progressing to the next step

When a script is evaluated as the condition for a transition, it is often specified through these nested elements instead of as a when attribute on the transition element, especially if you use a long script.

Example:

<Transition to="end">
    <Script>
       <Source>
           ("cancel".equals(violationReviewDecision) || ((size(policyViolations) 
            > 0 ) &amp;&amp; (policyScheme.equals("fail"))))
       </Source>
    </Script>
</Transition>

Conditions in the when attribute can be specified using the following types of conditions:

Most steps involve much more than a name and a transition. Steps also include an action attribute that executes the workflow processing. The action of a step can be a script or can a rule, subprocess, or a call to a workflow library method.

Any variables to be passed to a script, rule, subprocess, or library method must be declared as step arguments through <Arg> elements. Similar to other variables, the values for arguments can be specified by string, script, rule, call, or reference. The default specification type is string. Therefore, the "string:" qualifier can be omitted. However, arguments are also commonly passed by referencing workflow variables.

Step icon="Task" name="Initialize" posX="320" posY="126">
    <Arg name="w" vaflolue="ref:flow"/>
    <Arg name="formTemplate" value="string:Identity Update"/>
    <Arg name="identityName" value="ref:identityName"/>
     ...
    <Description>Call the standard subprocess to initialize the request, 
       this includes auditing, building the approvalset, compiling the plan into 
       project and checking policy violations.</Description>
    ...    
    <WorkflowRef>
        <Reference class="sailpoint.object.Workflow" name="Identity Request 
           Initialize"/>
    </WorkflowRef>
    <Transition to="end">
</Step>

When an argument is specified as a script, rule, or call, for example, <Arg name="myVar" value="rule:myWFRule"/>, any needed arguments to the script, rule, or library method cannot be explicitly specified.

Because these scripts, rules, and library methods automatically have access to the workflow context object, the scripts can access workflow variables directly through the workflow context get methods. These scripts/rules/methods can also access any step arguments that were defined before them in the step declaration. For example, the method that identifies the value for the Manager argument can use the value in the identityName argument in its processing, if needed. See the following example.

<Step icon="Task" name="Processing Step" posX="320" posY="126">
    <Arg name="identityName" value="ref:identityName"/>
    <Arg name="Manager" value="call:getManager"/>
    ...
</Step>

The following table lists the available Arg attributes

To return more than one value from a subprocess, you can declare <Return> elements for the step. At a minimum, a return element contains: a name attribute and a to attribute. The name attribute is the name of the variable in the subprocess workflow and the to attribute is the variable name in the calling (current) workflow. If these names are the same in both workflows, a to attribute is not required. However, specifying a to attribute is a best practice for clarity.

Use the merge attribute when the variable is a List and the returned values should be appended to the current workflow's list instead of replacing it. Similar to Args, value attribute for return elements can be specified as a string, script, rule, call, or reference. String is the default. If the value argument is omitted, the value of the name variable is copied as-is into the to variable, However, a script/rule/method can be used to transform or modify the value as it is passed.

• name attribute – name of the variable in the subprocess workflow

• to attribute – variable name in the calling (current) workflow

Note: If these names are the same in both workflows, a to attribute is not required. However, specifying the to attribute is best practice.

<Step icon="Task" name="Initialize" posX="320" posY="126">
    <Arg name="flow" value="ref:flow"/>
    <Arg name="formTemplate" value="string:Identity Update"/>
    <Arg name="identityName" value="ref:identityName"/>
     ...
    <Return name="project" to="project"/>
    <Return merge="true" name="workItemComments" to="workItemComments"/>
    <WorkflowRef>
        <Reference class="sailpoint.object.Workflow" name="Identity Request 
           Initialize"/>
    </WorkflowRef>
    <Transition to="end">
</Step>

The following table lists the available Return attributes.

Note: Installations can create custom libraries for commonly used and required business methods. However, custom library methods must be named with unique names that do not conflict with standard library method names. Conflicts resolve as a reference to the standard library method. It is possible to extend a standard library and overload its method names. Extending a standard library is not consider a best practice. Therefore, the best practice is to create new names for nonstandard methods. Creating new names makes it clear that the method is not a standard method.

Use calls to workflow library methods to do step processing. Similar to subprocesses, they sometimes require arguments to be passed to them. You declare method arguments the same way as subprocesses. You use Library methods with a call action. See the following example.

<Step action="call:refreshIdentity" icon="Task" name="Refresh Identity" posX="618" posY="242">
    <Arg name="identityName" value="ref:identityName"/>
    <Arg name="correlateEntitlements" value="string:true"/>
    <Description>Add arguments as necessary to enable refresh features. Typically you 
      only want this to correlate roles. Don't ask for provisioning since that
      can result in provisioning policies that need to be presented and it's
      too late for that. This is only to get role detection and exception
      entitlements in the cube.</Description>
    <Transition to="Notify"/>
  </Step>

The methods available for the call action are those included in the libraries attribute for the workflow element, if specified. If no libraries attribute is specified, the workflow automatically has access to the methods in the Identity, Role, PolicyViolation, and Lifecycle Manager libraries. If other libraries, including custom libraries, are explicitly listed in the libraries attribute, any of the default libraries whose methods are needed by the workflow must also be explicitly included in the list to be available. See Workflow Library Methods for details about the methods available in each library.

The step wait attribute causes the workflow to pause in its execution for the duration specified. The wait value can be specified as a string, script, rule, call, or reference. String is the default.

<Step name="Wait for next check" wait="ref:provisioningCheckStatusInterval">
    <Description>
       Pause and wait for things to happen on the PE side.  
       Use the configurable interval to determine how long
       we wait in between checks.
    </Description>
    <Transition to="CheckStatus"/>
  </Step>

This attribute creates a special type of step with the sole purpose of creating a pause in the action. Wait steps are commonly used in retry logic to enable behind-the-scenes processing to occur before the workflow attempts to repeat an action.

These steps are not caused through a transition from a previous step. These steps are caused by a thrown message that the steps intercepts or catches. Currently, only a complete message is thrown and can be caught. This process occurs when one of the following items occurs:

• All sequential steps in a workflow are executed to completion.
  OR

• Failure condition results in the termination of the workflow.

<Step catches="complete" icon="Task" name="Finalize">
    <Arg name="project" value="ref:project"/>
    <Arg name="approvalSet" value="ref:approvalSet"/>
    <Arg name="trace" value="ref:trace"/>
    <Description>
       Call the standard subprocess that can audit/finalize the request.
    </Description>
    <WorkflowRef>
       <Reference class="sailpoint.object.Workflow" name="Identity Request Finalize"/>
    </WorkflowRef>
    <Transition to="end"/>

The primary purpose of these steps is to update the IdentityRequest object, which tracks and reports the status of a LifecycleManager request, making the history of LCM request processing available even after the TaskResult for the workflow was purged.

Each installation can drive custom logic based on catching this complete message.