ExamFinch.com My Study

Study guide

10.1 Workflow Variables, Transitions, and Step Conditions

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.1 Workflow Variables, Transitions, and Step Conditions

Key Takeaways Explain This Topic AI

Variables have name, initializer, input, output, required, and editable attributes; an initializer is used only when no value is passed in.

Initializers, arguments, and conditions can be string, script, rule, call, or ref values.

Transitions are evaluated in order and the first true (or unconditional) transition wins; the last transition should be unconditional.

With explicitTransitions true, a step whose conditions are all false does not fall through to the next step in the XML; the workflow ends.

A step condition decides whether a step's action runs, so a step can be skipped without complex transition logic.

Last updated: September 2026

Workflow Variables, Transitions, and Step Conditions

Objective 4.3 is use workflow variables, transitions, and step conditions . These three features control what data a workflow holds and which path it takes .

  • The Workflow Element <Workflow name="ACME Contractor Extension" type="IdentityUpdate"
  • explicitTransitions="true" libraries="Identity,Role,LCM">
  • Attribute Meaning
  • name Shown in selection lists
  • type Filters where the workflow can be selected, such as LCM Provisioning, Identity Lifecycle, or Subprocess

explicitTransitions If true, no implicit fall-through to the next step when all transition conditions are false. The Business Process Editor sets it to true when you edit there.

libraries Compiled workflow libraries for call: actions. The default is Identity, Role, PolicyViolation, and LCM.

stepLibraries Step libraries shown in the editor. The default is the Generic Step Library (Start, Stop, Generic).

handler Defaults to sailpoint.api.StandardWorkflowHandler . A custom handler must extend it.

configForm A form providing the Basic View of process variables

Four runtime objects matter. Workflow is the definition. WorkflowCase is a running instance, tracking one target such as one identity or one plan. WorkflowContext ( wfcontext ) holds the live state: variables, arguments, current step, and libraries. TaskResult records the outcome and appears under Task Results.

Variables

The documentation recommends declaring all variables at the top of the workflow: <Variable name="identityName" input="true" required="true"/>

  • <Variable name="daysToExtend" initializer="string:30" editable="true"/>
  • <Variable name="managerName" initializer="script:getManagerName(identityName)"/>
  • <Variable name="approved" output="true"/>
  • <Variable name="trace" initializer="string:false"/>

input – a value can be passed in when the workflow is launched.

output – the variable is returned, for example to a parent workflow.

required – it must be non-null at start.

editable – it can be edited in the Basic View.

type – documentation only. It is not enforced .

Order matters. A variable whose initializer uses another variable must be declared after it. Variables created in the UI are listed in the opposite order from the XML.

Initializer Types (the Same Choices Apply to Arguments and Conditions)

  • Type Example
  • string (default; prefix optional) initializer="string:true" or initializer="spadmin"
  • script initializer="script:resolveDisplayName(launcher)" or a nested <Script><Source>
  • rule initializer="rule:wfrule_GetIdentityName"
  • call initializer="call:getObjectName" (a workflow library method)
  • ref initializer="ref:otherVar"

An initializer runs only when no value was passed in. That is why LCM defaults can be overridden at launch. SailPoint recommends initializers over extra "set variable" steps, because trace output reports initializations as they happen.

Dollar-Sign References

$(identityName) resolves a variable inside a string, for example <Arg name="Title" value="Role Update for $(identityName)"/> . Used alone, it behaves like ref:identityName .

Transitions

Each step has one or more <Transition to="..." when="..."> elements:

Transitions are evaluated in the order listed .

The first transition whose condition is true , or that has no condition , is taken.

Best practice: make the last transition unconditional , as the default path.

If every transition has a condition and none is true , then with explicitTransitions="true" the workflow ends . Without it, the workflow falls through to the next step in the XML.

Condition types are script (the default, which must return a Boolean), rule , call , and ref (a Boolean variable). A string literal "true" or "false" is technically allowed but does no evaluation. Long conditions go in a nested <Script> : <Transition to="Exit On Policy Violation"

  • when="script:(size(policyViolations) &gt; 0) &amp;&amp; &quot;fail&quot;.equals(policyScheme)"/>
  • <Transition to="Approve"/>

Remember that XML special characters must be escaped in attributes ( &amp;&amp; for && ).

Loops

A loop is a transition back to an earlier step. That step's state is reinitialized and it runs again. A loop transition should almost always have a condition , or the workflow can loop forever. Retry patterns combine a loop with a wait step (section 10.3).

Worked Example: Tracing a Path

Suppose a step named Check Violations has these transitions, in order:

  • to="Fail" when size(policyViolations) > 0 && "fail".equals(policyScheme)
  • to="Violation Review" when size(policyViolations) > 0
  • to="Approve" (no condition)

If there are two violations and policyScheme is continue , transition 1 is false and transition 2 is true, so the workflow goes to Violation Review . If there are no violations, both conditions are false and the unconditional transition 3 sends it to Approve . If someone deletes transition 3 and the workflow has explicitTransitions="true" , a request with no violations would simply end . That silent failure is exactly why the last transition should be unconditional.

Step Conditions

A step condition (right-click a step and choose Add Step Condition ) decides whether the step's action runs once the workflow arrives at the step. Use it to skip optional work, such as sending a notification only if notifyManager is true, without drawing extra transitions around the step. Condition types are Reference (a Boolean variable), Script , Rule , and Call Method . Negate inverts the result.

  • Need Use
  • Choose between different next steps Transitions with conditions
  • Run or skip one step's action on the same path Step condition
  • Repeat a step until something is true Loop transition with a condition, often with a wait