SailPoint Development overview
Where and how developers extend IdentityIQ: rules, workflows, custom connectors, plugins and the object model.
Developing on IdentityIQ means extending it at defined points: BeanShell rules for logic, workflows for multi-step processes, custom connectors for unusual systems, and plugins for UI and REST extensions. Most work is configuration first; code is the last resort, kept small and reusable.
- Configuration first, code only where needed
- Rules (BeanShell) add logic at extension points
- Workflows orchestrate multi-step processes
- Custom connectors and plugins extend integration and UI
- Everything lives as versionable deployment objects
The development module covers everything a SailPoint developer needs to extend the platform beyond configuration, rules, workflows, the object model, APIs and the engineering discipline that keeps customisations maintainable. Development is where SailPoint becomes truly fitted to an organisation.
What SailPoint development involves
Development means writing the logic and integrations that configuration alone cannot express: correlation and provisioning rules in BeanShell, custom workflows, API-driven automation, and occasionally custom connectors in Java. It sits on top of a solid understanding of the object model.
The developer toolkit
- BeanShell rules at defined hook points.
- Workflows for multi-step processes.
- The object model and XML for configuration-as-code.
- REST APIs and SDKs for automation and integration.
Engineering discipline
The difference between a maintainable deployment and an unmanageable one is discipline: keep rules small, null-safe, tested and documented; keep configuration in source control; test every change in a lower environment; and avoid the performance traps (per-identity database queries, huge object graphs) that customisation makes easy to fall into.
Common pitfalls
- Scattering business logic across many undocumented rules.
- Performance-killing customisations.
- Untested code deployed to production.