9.2 Rule Input and Output Arguments

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.2 Rule Input and Output Arguments

Key Takeaways Explain This Topic AI

Every rule receives context (the SailPointContext) and log, plus type-specific inputs listed in its Signature.

A Correlation rule returns a Map with identityName, identity, or identityAttributeName plus identityAttributeValue.

An IdentityCreation rule receives the new identity object and changes it in place; it does not return a new Identity.

BuildMap returns a Map of attributes, and ResourceObjectCustomization returns the (possibly changed) ResourceObject.

Workflow rules and scripts see wfcontext, all workflow variables, and step arguments, and their return value can fill the step's resultVariable.

Last updated: September 2026

Rule Input and Output Arguments

Objective 4.2 asks you to understand and leverage rule input and output arguments . Writing correct logic in the wrong shape, such as returning a String where a Map is expected, is the most common rule bug. It is also a favorite exam distractor.

The Signature

A rule's XML can declare a <Signature> listing its inputs and outputs: <Rule name="Correlation - HR" type="Correlation">

• <Signature returnType="Map">
• <Inputs>
• <Argument name="environment"/>
• <Argument name="application"/>
• <Argument name="account"/>
• <Argument name="link"/>
• </Inputs>
• <Returns>
• <Argument name="identityAttributeName"/>
• <Argument name="identityAttributeValue"/>
• </Returns>
• </Signature>
• <Source>...</Source>
• </Rule>

The Rule Editor shows these as Arguments and Returns , and you cannot change them there. Inputs arrive as named BeanShell variables , so you use account , not a parameter list. The signature documents the contract, and the rule type decides what IdentityIQ actually passes.

Variables Every Rule Gets

context – the SailPointContext , your gateway to the database and API (section 9.3).

log – a logger for debug and error output (section 14.1).

Contracts for the Most-Tested Rule Types

Rule type Key inputs Expected output

BuildMap (Delimited File, JDBC) cols (column names), record (one row's values), application , schema , state A Map of attribute name to value for one object

PreIterate / PostIterate (Delimited File) application , schema , stats Nothing. Used for setup (such as unzipping a file) and cleanup (such as archiving it).

ResourceObjectCustomization (Customization rule) object (the ResourceObject), application , connector , state The ResourceObject , possibly changed

Correlation environment , application , account (ResourceObject), link A Map containing identityName , or identity , or identityAttributeName + identityAttributeValue

ManagerCorrelation environment , application , instance , connector , link , managerAttributeValue A Map with the same keys, identifying the manager

IdentityCreation (Creation rule) environment , application , account , identity (the new identity) Nothing. Change the identity passed in.

BeforeProvisioning / AfterProvisioning plan , application (AfterProvisioning also gets result ) Nothing. Before changes the plan in place, and after reacts to the outcome.

FieldValue / AllowedValues / Validation (forms) The form and field, plus other field values by name A value / a list of allowed values / error message(s), or null when valid

IdentityTrigger (lifecycle event of type Rule) previousIdentity , newIdentity Boolean : fire the event or not

CertificationExclusion entity , items , itemsToExclude An explanation String . Move items between the lists.

CertificationSignOffApprover certification , certifier A Map with identity or identityName for the next approver

SSOValidation The incoming HTTP request null if the session is valid, or an error string (runs on every request)

• Correlation Example: Returning the Right Shape import java.util.HashMap;
• import java.util.Map;
• 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; // empty map = no match; the account stays uncorrelated
• IdentityCreation Example: Modify, Do Not Replace String first = (String) account.getAttribute("FIRST_NAME");
• String last = (String) account.getAttribute("LAST_NAME");
• identity.setFirstname(first);
• identity.setLastname(last);
• identity.setAttribute("type", "Employee");
• // no return value: IdentityIQ saves the identity object it passed in

A rule that builds a brand-new Identity and returns it breaks the contract. IdentityIQ keeps using the object it passed in.

BuildMap Example: Shaping One Row

A delimited HR file has a single FULL_NAME column, but IdentityIQ needs first and last names. The BuildMap rule receives the column list ( cols ) and one row ( record ) and returns the attribute map for that account: import java.util.HashMap;

• import java.util.Map;
• Map map = new HashMap();
• for (int i = 0; i < cols.size(); i++) {
• map.put(cols.get(i), record.get(i));
• }
• String full = (String) map.get("FULL_NAME");
• if (full != null && full.contains(" ")) {
• map.put("FIRST_NAME", full.substring(0, full.indexOf(" ")));
• map.put("LAST_NAME", full.substring(full.lastIndexOf(" ") + 1));
• }
• return map;

The returned keys must match the account schema attribute names. Otherwise the values are ignored when the ResourceObject is built.

Workflow Rules and Scripts

Rules of type Workflow , and scripts inside steps, transitions, and initializers, receive:

wfcontext – the WorkflowContext, holding variables, step arguments, the current step, the workflow, and the WorkflowCase.

Every workflow variable by name , plus any step arguments declared before the current one.

The return value can be captured in the step's resultVariable , used as a transition condition (it must be Boolean ), or used as an argument or initializer value.

• Calling a Rule From Code
• You can run a rule and pass it inputs from another rule or script: import sailpoint.object.Rule;
• import java.util.HashMap;
• import java.util.Map;
• Rule r = context.getObjectByName(Rule.class, "ACME - Compute Username");
• Map args = new HashMap();
• args.put("firstname", "Ana");
• args.put("lastname", "Silva");
• Object username = context.runRule(r, args); // map keys become variables
• Common Mistakes

Returning a String identity name from a Correlation rule instead of a Map .

Returning a new Identity from an IdentityCreation rule instead of changing identity .

Returning null from a Customization rule when you meant to keep the object. Always return the object you changed.

Transition scripts that return a non-Boolean value.

Relying on a variable that is not in that rule type's inputs. Check the Arguments list in the Rule Editor or the sample in examplerules.xml .