10.4 Leveraging Sub-Workflows

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:

1. A simpler master workflow, which reads as a list of high-level stages.
2. Easier management, because each stage is small enough to understand and test.
3. 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

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:

1. Create ACME Notify Manager with type Subprocess. Give it input variables identityName, templateName, and extraRecipients, and an output variable notified.
2. Move the email steps into it, ending at Stop.
3. 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"/>.
4. 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

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.