ExamFinch.com My Study

Study guide

10.4 Leveraging Sub-Workflows

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.4 Leveraging Sub-Workflows

Key Takeaways Explain This Topic AI

A subprocess is a complete workflow with its own Start and Stop, called from a step through a WorkflowRef; the calling workflow waits until it finishes.

Subprocess workflows are conventionally given the Subprocess type, which marks them as parts of larger workflows.

Arg elements pass values in, and Return elements copy subprocess variables back; merge="true" appends to list variables instead of replacing them.

Step replication launches one subprocess per item in a list so the items can finish independently.

LCM Provisioning is built from subprocesses such as Identity Request Initialize, Provisioning Approval Subprocess, Identity Request Provision, and Identity Request Finalize.

Last updated: September 2026

Leveraging Sub-Workflows

Objective 4.6 asks you to understand how sub-workflows can be leveraged . A subprocess is simply another workflow that a step launches. Control passes to it until it completes , and then the calling (master) workflow continues. SailPoint gives three benefits of splitting complex workflows into subprocesses:

A simpler master workflow , which reads as a list of high-level stages.

Easier management , because each stage is small enough to understand and test.

Reuse , because many master workflows can call the same subprocess.

Declaring and Calling a Subprocess

A subprocess is a complete workflow , with Start, Stop, and its own steps and variables. By convention its type is Subprocess , which ties it to no system trigger but marks it as part of a larger workflow. In the Process Designer, set a step's action to Subprocess and choose from workflows of that type.

  • In XML, the calling step contains a WorkflowRef , arguments, and returns: <Step icon="Task" name="Initialize">
  • <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 name="workItemComments" to="workItemComments" merge="true"/>
  • <WorkflowRef>
  • <Reference class="sailpoint.object.Workflow" name="Identity Request Initialize"/>
  • </WorkflowRef>
  • <Transition to="Approve"/>
  • </Step>
  • Passing Data In: Arg

Each Arg sets a variable in the subprocess . The subprocess should declare matching input="true" variables. As in other arguments, the value can be string, script, rule, call, ref, or $() .

Passing Data Back: Return

  • Return attribute Meaning
  • name The variable in the subprocess

to The variable in the calling workflow . It can be omitted when the names match, but including it is best practice.

  • value Optional transformation of the returned value (string, script, rule, call, or ref)
  • merge="true" For lists : append to the caller's list instead of replacing it
  • local Approvals only: keep the value in the parent approval's local storage instead of a workflow variable

A normal step returns one value through resultVariable . A subprocess step can return many values through several Return elements. That is one reason to use subprocesses. Return elements must be written in XML, because the UI has no editor for them.

Step Replication

When you choose a subprocess in the designer, you can enable step replication . You pick a list from the master workflow and the argument that receives each item. IdentityIQ launches one subprocess per item , all passed through the same argument, so the items run to completion independently instead of one after another . For example, one approval subprocess per approver can take each approved item all the way to provisioning without waiting for every other approver.

Subprocesses in the Product

The most important example is LCM Provisioning (section 4.3). Its steps call:

  • Identity Request Initialize – builds the request, compiles the plan, and checks policies
  • Identity Request Violation Review – interactive policy handling
  • Identity Request Approve and Provisioning Approval Subprocess – builds approvals
  • Do Provisioning Forms – collects missing data
  • Identity Request Provision (with Provision with Retries ) – provisions
  • Identity Request Notify – sends notifications
  • Identity Request Finalize – called from a catches="complete" step

Lifecycle event workflows reuse some or all of the same subprocesses. When you customize a stage, such as notifications, copy just that subprocess , point your copy of the master workflow at it, and leave the rest alone.

Worked Example: Extracting a Notification Stage

A team has three custom lifecycle workflows (joiner, mover, and leaver) that each end with 40 lines of nearly identical email logic. Refactoring it:

Create ACME Notify Manager with type Subprocess . Give it input variables identityName , templateName , and extraRecipients , and an output variable notified .

Move the email steps into it, ending at Stop .

In each lifecycle workflow, replace the old steps with one step whose WorkflowRef names the subprocess. Pass the three Arg values and add <Return name="notified" to="notified"/> .

Test each master workflow with trace on and Redirect to File (section 3.4).

A later change to the notification wording is now made once, in one object, and every lifecycle workflow picks it up.

Choosing the Right Reuse Mechanism

  • Need Best choice Why
  • Reuse a few lines of logic Rule or rule library method (section 9.1) Lightweight; no workflow state

Reuse a whole stage with approvals, forms, and waits Subprocess Has its own steps, approvals, and many return values; the caller waits

Kick off unrelated work and keep going scheduleWorkflowEvent Launches a separate workflow, optionally delayed; the caller does not wait

  • Same stage for many items independently Subprocess with step replication One subprocess per item
  • Pitfalls

Missing inputs. If the subprocess expects identityName and the caller does not pass it, the subprocess runs with null. Mark critical variables required="true" .

Forgetting Return. Changes made inside the subprocess are not visible to the caller unless they are returned.

Overwriting lists. Use merge="true" when both workflows add to a list, such as comments.

Type confusion. A subprocess of type Subprocess will not appear in trigger drop-downs such as the LCM Business Processes tab. That is intended, because it is meant to be called, not triggered.