10.3 The Different Workflow Step Usages

The Different Workflow Step Usages

Objective 4.5 asks you to know the different workflow step usages. Every step needs a name, an icon, and posX/posY positions. What it does depends on its action or its special attributes.

Action Types

Examples from the documentation:

<Step action="script:approvalSet.setAllProvisioned();" icon="Task" name="Post Provision">
  <Transition to="Stop"/>
</Step>

<Step action="call:refreshIdentity" icon="Task" name="Refresh Identity">
  <Arg name="identityName" value="ref:identityName"/>
  <Arg name="correlateEntitlements" value="string:true"/>
  <Transition to="Notify"/>
</Step>

Arguments and Results

• <Arg name value> passes data to the step's script, rule, method, or subprocess. Values can be string (the default), script, rule, call, or ref, and $() references work too.
• When an argument is computed by a script, rule, or call, that code can read workflow variables and any argument declared above it in the same step. For example, a Manager argument computed from the identityName argument declared just before it.
• resultVariable stores the step's single return value in a workflow variable. Returning several values requires a subprocess with <Return> elements, which you declare in XML because the UI has no editor for them.
• The Basic View of a step's Arguments tab comes from a step configForm, usually defined in a step library. The Advanced View lists every argument.

Choosing Between Script, Rule, and Call

All three can do the same work, so the exam tests judgment:

• Use a script when the logic is short and used only in this workflow, such as setting a flag or building a description.
• Use a rule (type Workflow) when the same logic is needed by several workflows, or when it is long enough to deserve its own object, change history, and testing. Remember that editing a shared rule changes every workflow that uses it.
• Use a call when a SailPoint library method already does the job, such as refreshing an identity, building an approval set, or provisioning a project. Library methods are maintained by SailPoint and are usually safer than a hand-written copy.
• Use a subprocess when the reusable unit includes its own steps, approvals, or waits.

Special Step Types

Wait Steps

wait pauses the workflow for a time from a string, script, rule, call, or ref value:

<Step name="Wait for next check" wait="ref:provisioningCheckStatusInterval">
  <Transition to="CheckStatus"/>
</Step>

Waits appear in retry loops: check status, wait, loop back. Like approvals and background="true" steps, a wait makes the workflow case persist. This matters for "transient" workflows, which normally are not saved.

Catches Steps

A step with catches="complete" is not reached by a transition. It runs when the workflow completes, either normally or after a failure ends it. LCM uses it to call Identity Request Finalize, so the IdentityRequest record is updated even after the workflow's TaskResult is pruned. Installations can hang their own finalization logic on it.

Start and Stop Steps

By convention, every workflow has an empty Start and Stop, and every path should end by transitioning to Stop. They can print debug messages during development.

Icons

The designer starts with Start, Stop, and Generic. You can change icons to make diagrams readable: Approval, Audit, Catches, Email, Message, Provision, Task, Analysis, and others. Icons are cosmetic. They do not change behavior.

Standard Workflow Handler Methods

Every workflow can call these, even without listing libraries:

scheduleWorkflowEvent starts an independent workflow, and the caller moves on immediately. A subprocess makes the caller wait (section 10.4).

Monitoring and Debugging

• Task Results (Setup > Tasks > Task Results) shows a running workflow's current step and status. The TaskResult may be pruned after completion.
• WorkflowCase XML shows the live state, including variables and step status. In the console, run list workflowcase and then get workflowcase "<name>", or open it in the Debug pages.
• trace set to true prints step-by-step execution. Turn it off afterwards.
• Process Metrics. Enable Monitoring on steps collects timing data you can search in Advanced Analytics > Process Metrics.
• Console. workflow "<name>" <file> runs a workflow with input variables from a file, and validate checks a workflow definition (section 14.3).