Study guide

9.1 The Purpose and Use of Rule Libraries

SailPoint Certified IdentityIQ Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: The IdentityIQ Engineer Exam

1.1 Exam Format, Official Blueprint, and Study Strategy

2 Chapter 2: Infrastructure, Installation, and Extended Attributes

2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them

3 Chapter 3: Build, Deployment, Patching, Access, and Email

3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection

4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows

4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows

5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup

5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations

6 Chapter 6: Certification Campaigns and Certification Rules

6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules

7 Chapter 7: Policies and Policy Violations

7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations

8 Chapter 8: Reporting, Advanced Analytics, and Auditing

8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing

9 Chapter 9: Rules, Rule Libraries, and the SailPoint API

9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods

10 Chapter 10: Workflow Development

10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows

11 Chapter 11: Email Templates, Branding, and Localization

11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI

12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation

12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings

13 Chapter 13: Data-Loading Tasks and Application and Connector Rules

13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types

14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console

14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging

15 Chapter 15: Debug Pages and the Administrator Console

15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging

16 Chapter 16: Role Model and Identity Attribute Mappings

16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings

17 Chapter 17: Data Objects, Relationships, and Group Types

17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types

9.1 The Purpose and Use of Rule Libraries

Key Takeaways Explain This Topic AI

Rules are standalone Rule objects referenced by the objects that use them; scripts are embedded in the objects that use them, such as workflows and policies.

A rule library is a Rule object that contains a collection of related methods other rules and workflow scripts can call.

A rule references a library with a ReferencedRules element; a workflow uses a RuleLibraries element.

IdentityIQ ships rule libraries such as Workflow Library, Approval Library, and LCM Workflow Library, separate from the compiled workflow libraries (Identity, Role, PolicyViolation, LCM) called with call: actions.

A rule used in several places changes behavior everywhere at once, so create separate rules when behavior must differ.

Last updated: September 2026

The Purpose and Use of Rule Libraries

Objective 4.1 asks you to understand the purpose and use of rule libraries . First, the basics of rules.

Rules and Scripts

IdentityIQ lets integrators add custom business logic at defined points using BeanShell , a Java-based scripting language that can use any Java class available to IdentityIQ, including custom code. The documentation separates two forms:

Rules are standalone objects ( Rule ) that other objects refer to . For example, an application references a Correlation rule, and a certification references an Exclusion rule.

Scripts are BeanShell embedded inside the object that uses them, such as a workflow step, a policy, or a form field.

Most rules have a type , such as Correlation, BuildMap, CertificationExclusion, or PolicyOwner. The type decides which drop-down lists offer the rule and which inputs and outputs it gets (section 9.2). For example, the Policy Owner selector on the Edit Policy page shows only rules of type PolicyOwner .

Creating Rules

Rule Editor: click [...] beside a rule field. You can copy an existing rule, name it, and see its type-specific Arguments and Returns (read-only). Warning: the editor does not validate the code. A syntactically broken rule saves anyway and fails later at run time. Access to the Rule Editor can be restricted.

Import rule XML: use Global Settings > Import from File or the console import command. One file may contain several rules. This is how rules move between environments (section 3.1).

Samples: WEB-INF/config/examplerules.xml has an example of each rule type. Rapid Setup samples are in WEB-INF/config/rapidsetup/rsexamplerules.xml .

What a Rule Library Is

A rule library is a Rule object that contains a collection of related but unconnected methods , not one piece of logic that runs top to bottom. Other rules and workflow scripts call those methods. SailPoint keeps these methods in Rule objects, rather than compiled Java, so each installation can easily modify them . The product ships several, including Workflow Library , Approval Library , and LCM Workflow Library . You can view them in the Debug pages or the console.

  • Referencing a Library from a Rule <Rule name="Correlation - HR" type="Correlation">
  • <ReferencedRules>
  • <Reference class="sailpoint.object.Rule" name="ACME Common Library"/>
  • </ReferencedRules>
  • <Source>
  • return buildCorrelationMap(account); // method defined in the library
  • </Source>
  • </Rule>
  • Referencing a Library from a Workflow <RuleLibraries>
  • <Reference class="sailpoint.object.Rule" name="Workflow Library"/>
  • <Reference class="sailpoint.object.Rule" name="Approval Library"/>
  • <Reference class="sailpoint.object.Rule" name="LCM Workflow Library"/>
  • </RuleLibraries>

Each Reference names one library. Include only the libraries whose methods the workflow needs. Custom libraries use the same syntax.

  • A typical custom library looks like this: // Rule "ACME Common Library" (no type needed for a pure library)
  • import sailpoint.object.Identity;
  • import java.util.HashMap;
  • import java.util.Map;
  • public Map buildCorrelationMap(Object account) {
  • Map result = new HashMap();
  • String empId = (String) account.getAttribute("EMPLOYEE_ID");
  • if (empId != null) {
  • result.put("identityAttributeName", "employeeId");
  • result.put("identityAttributeValue", empId.trim());
  • }
  • return result;
  • }
  • public boolean isContractor(Identity id) {
  • return id != null && "Contractor".equals(id.getAttribute("type"));
  • }
  • Rule Libraries vs. Workflow Libraries vs. Step Libraries

Three "library" ideas appear in IdentityIQ, and the exam likes to mix them up:

Library kind What it is How it is used

Rule library A Rule object of BeanShell methods <ReferencedRules> in rules and <RuleLibraries> in workflows; methods are called inside scripts

Workflow library Compiled Java classes named sailpoint.workflow.<Name>Library , such as IdentityLibrary and RoleLibrary Listed in the workflow's libraries attribute; methods are called with a call: step action or initializer

Step library A template workflow (for example, of type StepLibrary) that holds reusable steps Listed in stepLibraries ; the steps appear in the Business Process Editor's Add a Step panel

If a workflow has no libraries attribute , it can use the Identity, Role, PolicyViolation, and LCM workflow libraries by default. If you list libraries, you must include every one you need, because the list replaces the default. There is one more wrinkle: methods from a Java workflow library called inside a script must be imported in that script. The documentation's example imports sailpoint.workflow.IdentityRequestLibrary before calling it.

Why and When to Use Rule Libraries

Don't repeat yourself. Put name-formatting, correlation-key, and lookup logic in one place and call it from Correlation, IdentityCreation, and FieldValue rules.

Keep specialized rules small. The typed rule becomes a thin wrapper that calls library methods, which makes review and testing easier.

Change without redeploying Java. Libraries are XML objects, so an import updates behavior without a restart.

Remember the reuse warning. The documentation notes that one rule can be reused in many places, such as two applications sharing a BuildMap rule. A change affects every place it is used. If behavior must differ, create separate rules.

Watch performance. Library methods called by aggregation-time rules run for every record . Expensive lookups multiply quickly.