ExamFinch.com My Study

Study guide

10.3 The Different Workflow Step Usages

Practice this exam

SailPoint Certified IdentityIQ Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: The IdentityIQ Engineer Exam

1.1 Exam Format, Official Blueprint, and Study Strategy

2 Chapter 2: Infrastructure, Installation, and Extended Attributes

2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them

3 Chapter 3: Build, Deployment, Patching, Access, and Email

3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection

4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows

4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows

5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup

5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations

6 Chapter 6: Certification Campaigns and Certification Rules

6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules

7 Chapter 7: Policies and Policy Violations

7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations

8 Chapter 8: Reporting, Advanced Analytics, and Auditing

8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing

9 Chapter 9: Rules, Rule Libraries, and the SailPoint API

9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods

10 Chapter 10: Workflow Development

10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows

11 Chapter 11: Email Templates, Branding, and Localization

11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI

12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation

12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings

13 Chapter 13: Data-Loading Tasks and Application and Connector Rules

13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types

14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console

14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging

15 Chapter 15: Debug Pages and the Administrator Console

15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging

16 Chapter 16: Role Model and Identity Attribute Mappings

16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings

17 Chapter 17: Data Objects, Relationships, and Group Types

17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types

10.3 The Different Workflow Step Usages

Key Takeaways Explain This Topic AI

A step's action can be script:, rule:, call:, or a subprocess (WorkflowRef); call is the default action type.

Step arguments (Arg) pass values to the action and can themselves be string, script, rule, call, or ref values; later arguments can use earlier ones.

A wait step pauses the workflow for a set time, which is commonly used in retry loops.

A step with catches="complete" runs when the workflow completes or fails, and is used to finalize and audit requests.

Standard Workflow Handler methods such as addMessage, log, audit, sendEmail, and scheduleWorkflowEvent are available to every workflow.

Last updated: September 2026

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

  • Usage XML When to use it
  • Script action="script:..." or a nested <Script><Source> Short, workflow-specific logic

Rule action="rule:WFRule_verifyIdentity" Reusable BeanShell logic shared by workflows. Rules created from the step editor get type Workflow .

Call (the default action type) action="call:refreshIdentity" Run a compiled workflow library method, such as Identity or LCM library methods or the Standard Workflow Handler

  • Subprocess Nested <WorkflowRef> to another workflow Reuse a whole workflow (section 10.4)
  • Approval / Form Nested <Approval> Ask a person to decide or supply data (section 10.2)

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:

  • Method Purpose
  • getProperty / isProperty Read system properties
  • addMessage / getMessage Add or localize messages on the workflow case or task result
  • addLaunchMessage / setLaunchMessage Show a UI message such as "Request was submitted"
  • log Write to log4j with a level
  • print Print to the console
  • audit Create a custom audit event with source, action, and target
  • sendEmail Send an email using a template
  • scheduleWorkflowEvent Launch a separate workflow , now or later ( scheduleDate or scheduleDelaySeconds )

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).