Custom workflows
Quick answer
Building custom SailPoint IdentityIQ workflows the right way: subprocesses, rules, libraries and upgrade-safe patterns.
Key takeaways
- Build custom only when shipped workflows do not fit
- Thin parents, logic in subprocesses, rules and libraries
- Do not edit shipped workflows in place
- Test with trace, version the XML, keep rollback ready
When to build custom
Build a custom workflow when no shipped process fits: bespoke onboarding, integrations, scheduled remediation or approval logic beyond the standard schemes.
Structure for reuse
Keep parent workflows thin and push logic into subprocesses and rules. Use workflow libraries for shared methods so you do not repeat script.
Upgrade-safe patterns
Avoid editing shipped workflows in place. Copy or wrap them, and keep custom logic in clearly named objects so upgrades do not overwrite your work.
Testing and rollback
Test in a sandbox with trace enabled, keep the XML in source control, and be able to re-import a known-good version.
Want to learn this properly?
Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.
Check your understanding
What keeps custom workflows upgrade-safe?
- A. Editing shipped workflows in place
- B. Keeping custom logic in separate, clearly named objects
- C. Disabling refresh
- D. Avoiding rules
Show answer
B. Keeping custom logic in separate, clearly named objects
Keeping custom logic separate from shipped objects prevents upgrades overwriting it.