What is a Rule in IdentityIQ?

Rules are one of the most important extension mechanisms in IdentityIQ. They allow you to inject custom logic into almost every major object without touching the core product code.

In IIQ, Rule is a configurable object that contains custom logic written in BeanShell (Java-like syntax) and executed by the IIQ engine at specific points.

Consider it like a plug-in logic block that IdentityIQ calls when it needs a decision, transformation, or calculation that configuration alone can’t handle.

• Rules are stored as a Rule object in the IdentityIQ database

• Is defined in XML

• Contains:

  • Metadata (name, type, description)

  • Input and output definitions

  • A script block with executable code

• Runs inside the IdentityIQ JVM, with access to the full IIQ API and context

You can create rules either through the IdentityIQ UI or through the Debug page.

Why Do Rules Exist?

IdentityIQ is highly configurable. but no IAM platform can predict every organization’s business logic. Rules exist to fill that gap. They allow you to:

• Adapt IdentityIQ to your data

• Implement custom decision logic

• Extend behavior at well-defined hook points

• Keep core product code untouched and upgrade-safe

In short, rules are how you make IdentityIQ yours.

Common Use Cases for Rules

1. Customizing Data During Aggregation

Raw data coming from HR systems or applications is rarely perfect. So, Rules are often used to:

• Normalize values

• Translate source system codes into business-friendly values

• Derive attributes like lifecycle state or employment status

This logic typically runs during account or identity aggregation.

2. Advanced Account Correlation

Out of the box, IdentityIQ can correlate accounts to identities using simple matching rules. But real environments are messy. Correlation rules allow you to:

• Match on multiple attributes

• Apply fallback logic

• Handle duplicates or exceptions

• Decides whether to link to an existing identity or create a new one

3. Provisioning Control and Overrides

Provisioning often needs more than “grant entitlement X.” Rules can:

• Modify provisioning plans before execution

• Block or veto requests based on conditions

• Compute dynamic values like:

  • Target DN

  • Group memberships

  • Attribute defaults

• Route requests differently depending on context

These rules run during request evaluation or provisioning execution.

4. Smarter Access Certifications

Certifications can become noisy if left unchecked. Rules help by:

• Filtering which identities or entitlements appear

• Auto-approving low-risk items

• Suppressing known exceptions

• Customizing remediation behavior

This keeps certifications focused and meaningful for reviewers.

5. Shared Utilities and Reusable Logic

As environments grow, so does the complexity of rules. IdentityIQ supports Rule Libraries, which allow you to:

• Centralize helper methods

• Share logic across multiple rules and workflows

• Avoid copy-paste scripting

• Enforce consistent business rules

This is a best practice in mature IIQ implementations.

What Does a Rule Look Like?

At a high level, every rule has the same structure:

• Name - how it’s referenced in configuration

• Type - determines where it can be used

• Signature - defines expected inputs and outputs

• Source - the actual script logic

The rule type is especially important, it determines:

• Where the rule appears in the UI

• When it gets executed

• What inputs and outputs are expected

What Makes Rules Powerful?

Rules have full access to:

• The IdentityIQ context

• Identities, accounts, applications, requests

• Search and query APIs

• Java libraries available in the JVM

This makes them extremely powerful but also easy to misuse.

Best Practices

• Keep rules small and focused

• Avoid heavy loops and large queries

• Be cautious with external calls

• Handle nulls and exceptions defensively

• Use rule libraries for shared logic

• Version-control rule XML like real code

• Test in lower environments

A poorly written rule can impact performance across the entire system.

Conclusion

Rules are what give SailPoint IdentityIQ its real flexibility. They allow you to inject custom logic exactly where configuration ends during aggregation, correlation, provisioning, certifications, and policy enforcement. When written carefully and used sparingly, rules make IdentityIQ adaptable to real business needs. Treated as production code and designed with clarity, they become a powerful foundation rather than a maintenance burden.