Rule
The Rule object: BeanShell code that customizes SailPoint behavior at defined hooks.
A Rule is a snippet of BeanShell/Java that runs at a defined hook, correlation, build map, provisioning, to customize behavior.
- What the Rule object represents
- Key attributes and relationships
- How it is created and maintained
- Where it appears in governance
The Rule object holds a snippet of scripted logic, written in BeanShell (a Java-like scripting language), that IdentityIQ executes at a defined extension point. Rules are the primary way to customise IdentityIQ to your data and processes, and they run in the system’s hottest paths, so writing them well matters enormously.
Where rules run
- Correlation rules, match accounts to the right identity.
- Build-map / attribute rules, shape incoming data and populate identity attributes.
- Provisioning rules, customise how changes are applied.
- Refresh, workflow and many other hooks.
How rules receive context
Each rule type is passed a documented context, the relevant objects (an account, an identity) and a SailPointContext handle for querying and committing, and returns a result the engine uses. Knowing the inputs and expected output for the rule type you are writing is the starting point for any customisation.
Writing rules that last
- Keep them small and focused on one job.
- Be null-safe, missing attributes are common and cause runtime failures.
- Avoid heavy work, never load large object graphs or query per-identity in a loop; that destroys performance.
- Version-control and test every rule.
Bundle versus Rule and other confusions
Rules are logic; they are distinct from the objects they act on. Keep business logic documented and consolidated rather than scattered across dozens of undocumented rules, which is how deployments become unmaintainable.
Common pitfalls
- Performance-killing rules that query the database per identity.
- Null-pointer failures from unguarded attribute access.
- Undocumented logic spread across many rules.