SailPoint IIQ Custom Workflows Explained — How Enterprise Approval Chains Are Built

What Is a Workflow in SailPoint IIQ?

A workflow in SailPoint IdentityIQ (IIQ) — also called a business process — is a step-by-step automated process that handles tasks like access approvals and provisioning. Workflows are built from steps, variables, and transitions, and are edited visually in the Business Process Editor. Custom workflows are Module 13 of the SailPoint Academy 14-module curriculum.

When someone requests access, when a new hire joins, or when an employee leaves, a workflow decides what happens next: who approves it, what gets provisioned, what notifications go out, and in what order. Workflows are the automation engine of IdentityIQ — they turn governance policy into repeatable, auditable action. Because they orchestrate the highest-value processes in an enterprise, workflow skills are among the most sought-after on SailPoint projects.

What Are the Components of a SailPoint Workflow?

A SailPoint IIQ workflow is built from four core components: steps that perform actions, variables that carry data such as the provisioning plan, transitions that decide the path between steps, and approvals that route decisions to people. Complex workflows are split into reusable sub-process workflows called by a master workflow.

The same modular thinking from software engineering applies: a large process is broken into sub-process workflows that a master workflow calls. This keeps complex enterprise logic manageable and reusable, exactly as the LCM Provisioning workflow does.

How Do Steps, Variables and Transitions Fit Together?

In a SailPoint IIQ workflow, execution starts at the start step, moves through processing steps via transitions, and ends at the stop step, while variables carry state across the whole flow. Each step's action does the work; each transition evaluates a boolean variable or workflow rule to choose the next step, with a default path as fallback.

A simple way to picture it: steps are what happens, transitions are what happens next, and variables are the memory the workflow carries along the way. Inside steps you can call BeanShell or a workflow rule for any logic that needs transformation — which is where this module connects directly to rules and BeanShell (Module 6). A step might build a provisioning plan, a transition might check whether approval is required, and a variable holds that plan from start to finish.

How Do Approval Chains Work in SailPoint Workflows?

SailPoint IIQ approval chains use approval sets: the workflow creates a master approvalSet for all requested items, then separate approvalSets for each approver capturing their decisions, which are assimilated back into the master set. Conflict logic — such as any-rejection-wins or majority rule — decides the outcome when approvers disagree.

This is the part interviewers love, because real enterprises rarely have a single approver. A typical multi-level chain might route an access request to the manager, then the role owner, then a security reviewer. Each produces their own approvalSet; the workflow merges those decisions into the master set and applies the configured conflict policy. From IIQ version 7 onward, the provisioning plan can even be split so that approved items proceed without waiting for items still pending approval.

What Is the LCM Provisioning Workflow?

The LCM Provisioning workflow in SailPoint IIQ is the default business process that handles Lifecycle Manager access requests, running sub-workflows such as Identity Request Initialize, Provisioning Approval Subprocess, Approve and Provision, and Identity Request Finalize. It is the workflow most often customised for enterprise approval requirements.

When a user submits an access request through the Lifecycle Manager interface, the LCM Provisioning workflow drives the whole journey: it initialises the request, checks for policy violations, presents any provisioning forms, gathers approvals, executes provisioning, and finalises the request. Because it is modular, teams customise specific sub-processes — most commonly the approval subprocess — without rewriting the entire flow. Understanding this default workflow is the foundation for nearly all real customisation work, and it ties directly to how provisioning is configured during onboarding.

How Do Lifecycle Events Trigger Workflows?

In SailPoint IIQ, lifecycle events such as Joiner, Leaver, Mover and Rehire detect identity changes and trigger workflows that run provisioning plans automatically. A Leaver event, for example, builds and runs a provisioning plan to disable all accounts the departing identity holds, while a Joiner event provisions birthright access.

Lifecycle events are the bridge between "something changed about a person" and "a workflow does something about it." When an authoritative source aggregation shows a new hire, the Joiner event fires its workflow; when it shows a termination, the Leaver workflow disables access. Importantly, lifecycle events can trigger workflows of any type — including custom ones — which is what makes them the main entry point for bespoke automation. For the full treatment, see our dedicated guide on SailPoint IIQ lifecycle events.

What Is the Difference Between a Workflow and a Rule?

In SailPoint IIQ, a workflow is a multi-step automated business process such as an access-approval or provisioning flow, while a rule is a reusable block of BeanShell code that runs focused logic at one point. Workflows orchestrate the overall process and can call rules; rules handle individual decisions or transformations within steps.

If you have read our rules and BeanShell guide, this is the other half of the picture. The workflow is the conductor; rules are individual instruments it cues. A workflow step might call a rule to transform an attribute or decide a transition, but the workflow owns the sequence, the approvals, and the provisioning plan. Knowing when logic belongs in a workflow step versus a standalone reusable rule is a judgement that distinguishes senior IIQ developers.

What Do Interviewers Ask About SailPoint Workflows?

SailPoint workflow questions are common in senior IIQ interviews, focusing on workflow components, how approval chains and approval sets work, the LCM Provisioning sub-workflows, and the difference between workflows and rules. These appear in technical rounds at GCCs, Big 4 consulting firms, and IT services companies hiring experienced SailPoint developers.

• What are the components of a SailPoint workflow, and what is the minimum a step needs?
• How do transitions decide the next step?
• Explain how multi-level approvals work using approval sets and conflict logic.
• Walk me through the LCM Provisioning workflow and its sub-processes.
• How do lifecycle events relate to workflows?
• When would you put logic in a workflow step versus a standalone rule?

If you can answer these with examples, you are interview-ready on this module. For a wider set, see our SailPoint IIQ interview questions guide, and the SailPoint career paths page shows where workflow-heavy developer and architect roles sit.