Updated recently
Last updated:
Quick Answer: SailPoint IIQ workflows coordinate business processes such as joiner onboarding, mover approval, leaver revocation, access requests and certification remediation. A good workflow has a clear trigger, explicit approval states, an idempotent provisioning step and an auditable end state. A workflow that works once in test but cannot be retried safely is not production-ready.
SailPoint IIQ Workflow Examples: What They Are For
Workflows are for orchestration. They route a request, collect an approval, call a rule, invoke a provisioning plan and record the outcome. They are not a replacement for a scheduled aggregation, a role model or a connector. If the underlying data is wrong, a workflow will simply move the wrong data faster.
| Workflow | Trigger | Key control |
|---|---|---|
| Joiner | HR new-hire event | Start date and authoritative-source correlation |
| Mover | Department or manager change | Remove old access before granting new access |
| Leaver | Termination event | Disable accounts and revoke entitlements with evidence |
| Access request | User or manager request | Policy check, approval and provisioning plan |
| Certification remediation | Reviewer revokes access | Provisioning result and audit trail |
The Anatomy of an IIQ Workflow
Most workflows follow the same skeleton: a start step, one or more business steps, approval steps, a provisioning or rule step, and an end step. The workflow context carries variables between steps. If a step can be retried, it must be safe to run twice.
- Start: validate the trigger and required inputs.
- Enrich: look up the identity, manager, application or approver.
- Approve: route to the correct owner with a deadline and delegation.
- Provision: build and execute the plan.
- Verify: confirm the target state and record the result.
- End: close the request with an audit-friendly status.
Example 1: Joiner Workflow
A joiner workflow starts from an authoritative HR event, not from a ticket. The HR record should provide the employee ID, start date, department, manager and location. The workflow should create a pre-hire identity, wait for the start date, then provision birthright access.
Two controls matter. First, do not provision before the start date unless the business has approved early access. Second, if the HR feed is late, queue the event and alert; do not create a partial identity that someone has to clean up later.
Example 2: Mover Approval
A mover is harder than a joiner because access must be removed as well as added. The workflow should compare the old and new role sets, route the removal to the current manager and the addition to the new manager, and execute the revocation before the new grant where separation of duties requires it.
If the workflow only adds the new role, the employee accumulates access over time. That is how role explosion and audit findings start. A mover workflow should produce a before/after access diff that a reviewer can sign off.
Example 3: Leaver Revocation
A leaver workflow is a race against the clock. Disable the account first, then revoke entitlements and collect evidence. For sensitive systems, do not rely on the connector alone; reconcile the target state after the workflow completes.
Handle the edge cases: contractor end dates, shared mailboxes, service accounts and rehires. A leaver workflow that disables a shared account can take down a business process. The trigger must identify the person, not just the mailbox.
Example 4: Access Request with Manager Approval
The standard request workflow should evaluate policy, identify the approver, collect a decision and build a provisioning plan. The common failure is an approval that routes to a manager who has left the company. Add a fallback approver, a delegation rule and an expiry. An approval that waits forever is not a control; it is a backlog.
For privileged or sensitive access, add a second approval and a time-bound entitlement. The workflow should record why the access was granted, not just who clicked approve.
Example 5: Certification Remediation
When a reviewer revokes access during a certification, the workflow must turn that decision into a provisioning action and close the loop. The audit evidence is the final target state plus the reviewer decision, not the certification item alone.
If the provisioning fails, reopen the remediation task and notify the application owner. Do not mark the certification item complete because the reviewer clicked “revoke”; complete it when the access is actually gone.
Approval Patterns That Scale
Manager approval with a fallback. Route to the manager, then to the manager’s manager or a configured delegate if the first approver is inactive. Set an expiry. A request that waits forever is not a control.
Application owner approval. Use this for sensitive or privileged access where the business owner, not the manager, understands the risk. Pair it with a time-bound entitlement and a recertification date.
Two-person approval. For high-risk access, require two distinct approvers. Do not implement this by adding the same person twice; the workflow must check that the approvers are different identities.
Auto-approval with guardrails. Low-risk birthright access can be auto-approved if the role is tied to a verified job code and the user is active. Auto-approval without a policy check is just an unlogged grant.
Workflow XML Skeleton
The exact schema depends on your IIQ version, but the shape is consistent: steps, transitions and script or approval actions. Treat this as a structural example, not a copy-paste production workflow.
<Workflow name="Joiner Approval" type="IdentityLifecycle">
<Step name="start">
<Transition to="lookupIdentity"/>
</Step>
<Step name="lookupIdentity">
<Script>
<Source>
// Resolve the identity and manager from the HR event.
</Source>
</Script>
<Transition to="managerApproval"/>
</Step>
<Step name="managerApproval">
<Approval owner="manager">
<Transition to="provision"/>
</Approval>
</Step>
<Step name="provision">
<Script>
<Source>
// Build and execute the provisioning plan.
</Source>
</Script>
<Transition to="end"/>
</Step>
<Step name="end">
<Stop/>
</Step>
</Workflow>The important design choices are the approval owner, the timeout, the retry behavior and the failure path. A workflow without those is a demo.
Testing Without Breaking Production
| Test | What to prove | Failure to simulate |
|---|---|---|
| Happy path | Request reaches the right approver and provisions | None |
| Approver missing | Fallback or delegation works | Manager terminated |
| Duplicate request | No duplicate account or entitlement | Retry the same request |
| Provisioning failure | Task reopens and alerts | Connector timeout |
| Policy violation | Request is blocked with a clear message | SoD conflict |
| Leaver race | Access is removed before the end date | Late termination feed |
Test with real messy data: duplicate names, contractors, rehires and shared mailboxes. A workflow that only works for full-time employees with unique email addresses will fail in production.
Workflow Design Checklist
| Area | Question | Failure if skipped |
|---|---|---|
| Trigger | What starts the workflow, and is it idempotent? | Duplicate requests or missed events |
| Approver | Who approves, and who approves if they are unavailable? | Requests stuck indefinitely |
| Deadline | What happens when the approval expires? | Silent backlog and audit exposure |
| Policy | Is SoD checked before or after approval? | Approved request blocked at provisioning |
| Provisioning | Can the plan be previewed and rolled back? | Irreversible access change |
| Failure | Who is notified when provisioning fails? | Requester assumes access was granted |
| Audit | Can you prove the final target state? | Reviewer decision without evidence |
Common Workflow Mistakes
The first mistake is treating the workflow as the source of truth. The identity warehouse and the target system hold the access state; the workflow holds the process. If the target state is wrong, fix the provisioning and correlation, not the approval screen.
The second is a missing failure path. A workflow that ends in “completed” even when provisioning failed gives the business false confidence. Add a verification step and a visible exception queue.
The third is an approval model that only works for full-time employees. Contractors, rehires, shared mailboxes and managers on leave are normal, not edge cases. Test them before go-live, and write down who owns the exception when the standard path does not fit.
How to Measure Whether a Workflow Works
A workflow is not successful because it completed. Measure the outcome: how many requests reached a decision, how many were auto-approved, how many expired, how many provisioning actions failed and how long the median request took. A workflow that completes 100% of requests but leaves 30% of provisioning failures unresolved is a reporting failure, not a success.
Track the exception queue separately from the happy path. The business needs to see the requests that are stuck, not just the ones that closed. A weekly review of expired approvals, failed provisions and orphan accounts will surface design problems before an auditor does.
A useful dashboard shows four numbers every week: requests completed, requests expired, unresolved provisioning failures and median cycle time. Review them with the business owner, not just the IAM team. If the median cycle time is rising while completion looks healthy, the workflow is probably routing to an approver who is no longer active. That review is more useful than a completion percentage.
War Story: The Approval That Never Fired
A manager approval workflow went live on a Friday. By Monday, 200 requests were stuck. The workflow had routed to a custom attribute called “lineManager”, but the HR feed populated “managerId”. In test, the attribute was manually set on five accounts. In production, it was empty for most users.
The fix was a fallback to the manager relationship, plus a validation step that fails fast if no approver can be resolved. The larger lesson: a workflow must have an explicit “no approver” path. Silence is not an approval state.
Training Resources
If you want to build and test these workflows in a lab, SkilBrill’s SailPoint IdentityIQ training covers workflow design, approvals, provisioning and troubleshooting. For the identity model behind the workflow, the IAM training track fills in the gaps.
Read next: IIQ tutorial, BeanShell examples, and IIQ developer roles.
FAQ
What is the difference between a workflow and a task in IIQ?
A task is a scheduled or on-demand job, such as an aggregation or report. A workflow coordinates a business process with approvals, steps and provisioning. Use a task for batch work and a workflow for a decision path.
Can a workflow call a BeanShell rule?
Yes. Workflow steps can run scripts or call rules. Keep the script small, validate inputs and make the step idempotent so a retry does not duplicate the action.
How do I handle an approver who has left the company?
Configure a fallback approver or delegation, and fail fast if no approver can be resolved. Do not let the request wait indefinitely; an expired approval is an audit and service-level problem.
How do I test a workflow without affecting production?
Use a copy of production configuration and test identities, simulate missing approvers and provisioning failures, and verify the audit trail. Never run a new workflow against live users without a rollback plan.
What is the most common workflow failure?
A missing or incorrect approver, followed by a provisioning failure that is not surfaced to the requester. Both are design problems: the workflow needs an explicit fallback and a visible failure state.
