SailPoint IIQ Rules & BeanShell Explained — Aggregation, Provisioning, Connector and Schema Rules

What Is BeanShell in SailPoint IIQ?

BeanShell in SailPoint IdentityIQ (IIQ) is a lightweight scripting language based on Java that is used to write rules and custom logic. Because IdentityIQ is built in Java, BeanShell uses familiar Java-like syntax and can call the IdentityIQ API directly, letting developers customise aggregation, provisioning, correlation, and other behaviour at defined points in the product.

Think of BeanShell as "Java without the compile step." You write code that looks like Java, IIQ interprets it at runtime, and it has access to the same SailPoint objects a Java developer would use. This is why Java developers transition into SailPoint development so naturally — the syntax is already familiar, and the learning curve is about the IIQ object model, not a new language.

What Is a Rule in SailPoint IIQ?

A rule in SailPoint IdentityIQ is a reusable block of BeanShell (Java) code that adds custom business logic at specific points in the product, such as during aggregation or provisioning. IIQ ships with more than 70 rule types. Unlike scripts, which are embedded inside objects, rules are standalone objects that many other objects can reference and reuse.

This reusability is the key idea. A single Build Map rule, for example, can be shared by two different applications that read similar files. When IdentityIQ reaches a defined point in its execution flow — reading an account, correlating it, provisioning a change — it checks whether a rule is configured there and, if so, runs your BeanShell code. Every rule is also passed two common objects: a logging handle and the IdentityIQ context, which gives your code access to the SailPoint API to query identities, applications, and more.

What Is the Difference Between a Rule and a Workflow?

In SailPoint IIQ, a rule is a reusable block of BeanShell code that runs focused custom logic at one point in execution, while a workflow is a step-by-step automated business process such as an access-approval or provisioning flow. Workflows orchestrate multiple steps and can call rules; rules handle a single piece of logic like attribute transformation or correlation.

A useful way to hold the distinction: a workflow is the process (what happens, in what order, with which approvals), while a rule is a decision or transformation plugged into that process. There is also a storage difference — scripts are embedded directly inside the object that uses them (like a policy or a workflow step), whereas rules are saved as separate, named objects that can be reused across the system. Workflows are Module 13 of the curriculum; rules sit in Module 6.

What Are the Main Rule Types in SailPoint IIQ?

Key SailPoint IIQ rule types include Connector and Build Map rules that run while reading data, Correlation and Creation rules that link or create identities, Aggregation rules that transform data on read, and Provisioning rules that control writes back. IdentityIQ has 70+ rule types overall, each invoked at a defined execution point.

You do not memorise all 70+ — you learn the handful used on almost every project (Build Map, Correlation, Aggregation, Provisioning, Connector) and understand the pattern well enough to read the IIQ documentation for the rest.

What Is the Difference Between a Connector Rule and an Aggregation Rule?

In SailPoint IIQ, a connector rule runs during data read from specific connectors such as Delimited File, JDBC, and SAP, and generally executes before aggregation rules, while an aggregation rule transforms the resource object as it is aggregated. Connector rules handle connector-level data; aggregation rules handle account-level transformation.

Order matters here, and interviewers test it. The sequence during a read is roughly: the connector pulls raw data, the connector rule (if present) processes it first, then the aggregation rule transforms the resulting object before it becomes an account or identity link in IIQ. This is exactly where the connectors module and the rules module meet — a "special connector" is simply a connector that relies on a connector rule.

How Do Provisioning and Schema Rules Work?

In SailPoint IIQ, a provisioning rule controls how changes are written back to a target system during provisioning, while a schema rule lets you separate the business logic for account objects from group (non-account) objects. Provisioning rules can run before or after the provisioning action, enabling custom handling such as calling a stored procedure.

Provisioning is the write path, so these rules are higher-stakes than read-side rules — a mistake can grant or revoke real access. Common patterns include BeforeProvisioning and AfterProvisioning rules that adjust the request or perform follow-up actions, and JDBC provisioning rules that execute SQL against a database. Schema rules reduce repetitive checks by letting your code treat accounts and groups separately. These connect directly to application onboarding, where provisioning is configured.

What Does a SailPoint Rule Actually Look Like?

A SailPoint IIQ rule is an XML object with a type attribute that wraps a block of BeanShell code, and every rule receives common input objects — a logging handle and the IdentityIQ context for calling the SailPoint API. SailPoint ships an exampler­ules.xml file with one example of each rule type in the IdentityIQ installation.

Conceptually, a correlation rule reads the incoming account's identifier, queries IIQ for a matching identity using the context API, and returns the match. You do not need to write production code on day one — the goal in training is to read an existing rule, understand where it fires, and modify it safely. SailPoint's own example rules file is the best starting reference, and it is exactly how rules are taught hands-on in SailPoint Academy's live IIQ course.

What Do Interviewers Ask About Rules and BeanShell?

SailPoint rule and BeanShell questions are common in IIQ developer interviews, focusing on rule types, the rule-vs-workflow distinction, the difference between connector and aggregation rules, and when to use a correlation or provisioning rule. These appear in technical rounds at GCCs, Big 4 consulting firms, and IT services companies hiring SailPoint developers.

• What is BeanShell and why does SailPoint use it?
• What is the difference between a rule and a workflow?
• Name the rule types you have worked with and where each one fires.
• What is the difference between a connector rule and an aggregation rule, and which runs first?
• When would you write a correlation rule instead of using attribute-based correlation?
• What are the common parameters passed to every rule, and what is the context object?

If you can answer these with examples, you are interview-ready on this module. For a wider set, see our SailPoint IIQ interview questions guide, and the SailPoint career paths page shows where developer roles sit.