SailPoint Rules & BeanShell
Rules are the BeanShell scripts that add custom logic to IdentityIQ: mapping, correlation, provisioning and more.
A rule is a snippet of BeanShell, which is Java syntax, that IdentityIQ runs at a defined extension point, for example to build an account attribute, correlate an account to an identity, or transform a value during provisioning. A rule receives context objects the platform passes in and returns a value the platform then uses.
- Rules are BeanShell (Java-syntax) scripts at extension points
- Common types: BuildMap, Correlation, IdentityAttribute, Provisioning
- Rules receive context objects and return a value
- Keep rules small; push heavy logic into libraries
- Test rules carefully, they run inside core processes
Rules are how you customise IdentityIQ. A rule is a snippet of BeanShell (a Java-like scripting language) that runs at a defined extension point, correlation, build-map, provisioning, refresh and many others, letting you tailor the platform to your data and processes. Rules run in the system’s hottest paths, so writing them well matters enormously.
Where rules run
- Correlation rules, match incoming accounts to the right identity.
- Build-map rules, shape and normalise data read from a source.
- Provisioning rules, customise how changes are applied to targets.
- Refresh, workflow and many other hooks across the platform.
How rules receive context
Each rule type is passed a documented context, the relevant objects (an account, an identity) plus a SailPointContext handle for querying and committing, and returns a result the engine uses. Knowing the exact inputs and expected output for the rule type you are writing is the starting point for any customisation; copying a rule of the wrong type is a common error.
BeanShell in practice
BeanShell is forgiving and Java-like, which makes it quick to write and easy to get wrong. Missing attributes are the norm, so every dereference must be null-safe, and because rules often run per identity, expensive work (loading large object graphs, querying the database in a loop) can cripple refresh performance.
Writing rules that last
- Keep each rule small and single-purpose.
- Null-check everything, missing values are normal.
- Never query the database per identity in a loop.
- Log at debug with a named logger so failures are diagnosable.
- Version-control every rule and test it in a lower environment.
When not to use a rule
Prefer configuration over code where it exists, roles, assignment criteria and standard workflows solve many problems without a rule. Reserve rules for genuine logic that configuration cannot express, and keep business logic consolidated and documented rather than scattered across dozens of undocumented rules.
Common pitfalls
- Performance-killing rules that query the database per identity.
- Null-pointer failures from unguarded attribute access.
- Undocumented logic spread across many rules, making the system unmaintainable.