ExamFinch.com My Study

Study guide

13.2 Common Application Rule Types

Practice this exam

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

13.2 Common Application Rule Types

Key Takeaways Explain This Topic AI

Aggregation rules run after the connector builds valid ResourceObjects and after any connector rules.

A Correlation rule handles account matching that a correlation configuration cannot express, such as matching on several attributes together.

A Creation rule runs only when aggregation creates a new identity; a Manager Correlation rule links identities to managers when simple attribute mapping is not enough.

The Customization rule changes aggregated accounts or groups before they are saved, and it is the main account-manipulation rule for connectors without connector rules.

BeforeProvisioning runs just before the connector's provisioning call; AfterProvisioning runs just after it, and only if the result is committed or queued.

Last updated: September 2026

Common Application Rule Types

Objective 5.5 asks you to understand common application rule types . These are selected on an application's Rules tab. Unlike connector rules (section 13.3), they apply to all application types . examplerules.xml in WEB-INF/config contains an example of each.

Where Application Rules Fit in Aggregation

Loading diagram... Aggregation rule order

The documentation's key ordering fact: aggregation rules run after the connector has created valid ResourceObjects , which in turn happens after the connector rules have run .

Aggregation Rules

Rule Runs when Typical uses

Correlation An account needs matching to an identity and the correlation configuration is not enough Matching on several attributes together , fuzzy or normalized keys, or special service-account ownership. It returns a Map (section 9.2).

Creation (IdentityCreation) Only when a new identity is being created during aggregation, usually for authoritative applications Set the identity's password, change the identity name format, uppercase an attribute, set a type, or assign capabilities

Manager Correlation Linking an identity to its manager, when the Correlation tab's attribute mapping is not enough For example, the manager value is a DN that needs parsing, or several possible keys

Customization (ResourceObjectCustomization) Before the account or group is saved Normalize values, derive attributes, and mark accounts disabled, locked, service, or privileged. It is the main manipulation rule for applications without connector rules . It returns the ResourceObject.

Managed Entitlement Customization When a ManagedAttribute is created by aggregation, refresh, or the Missing Managed Entitlements Scan Set owner , requestable , description , or display name before the catalog entry is saved

Customization rules on some objects may run more than once for the same ResourceObject, for example for the provisioning result, the plan, and the account request. Write them so that running twice gives the same result.

Provisioning Rules

Rule Runs Notes

BeforeProvisioning Immediately before the connector's provisioning method Change or react to the ProvisioningPlan, such as adding a default attribute, blocking an operation, or logging. Runs for all connector types .

AfterProvisioning Immediately after the connector's provisioning method, only if the result is committed or queued React to what was sent, such as notifying another system or recording a ticket number. Runs for all connector types.

Schema Rules

Some connectors support schema-level rules, separate rules for account objects and group objects. They let you keep account logic and group logic apart, instead of checking inside one rule whether a ResourceObject is an account or a group.

Related Rules Set Elsewhere

Account Aggregation task: an optional rule to assign capabilities or perform other processing on new identities .

Account Group Aggregation task: a Group Aggregation Refresh rule to set owners or change groups when they are created or refreshed.

Identity Mappings: application or global rules as attribute sources (section 16.3).

Provisioning policies: FieldValue, AllowedValues, Validation, and Owner rules (section 4.2).

Worked Example: One Application, Four Rules

An ERP application has messy data, and four rules solve four different problems:

Customization rule: the ERP reports locked accounts as STATUS=L . The rule sets the IdentityIQ locked flag on the ResourceObject, trims whitespace from user IDs, and returns the object.

Correlation rule: ERP user IDs are not stored on identities, but the ERP holds an employee number and a company code. The rule returns identityAttributeName = employeeId and identityAttributeValue = the company code plus the employee number.

Managed Entitlement Customization rule: new ERP roles discovered by aggregation are set to non-requestable, with the ERP owner workgroup as owner, until someone reviews them in the catalog.

BeforeProvisioning rule: the ERP requires a cost-center attribute on every Create request. The rule adds it from the identity when a provisioning policy cannot, for example because the value depends on the requested role.

Each rule does one job at the right point in the pipeline, and none of them duplicates work that configuration could do. That is the design the exam rewards.

Debugging Application Rules

Turn on a logger for the rule and write log.debug statements that show the key inputs and the decision (section 14.1).

Reproduce the problem with a single-account aggregation from the account's page, or by aggregating a small test file.

Check the aggregation task result . Selected detail actions, such as Correlate New Account or Create New Identity , show what the rules decided.

Watch for exceptions in Syslog (section 14.2). A rule that throws an exception can make the account fail or the task end with errors.

Choosing the Right Rule

  • Requirement Rule
  • "Match AD accounts to identities when employeeID is blank by using email plus last name" Correlation
  • "New HR identities get user names in the format first.last" Creation

"The HR manager column holds the manager's employee number with a prefix" Manager Correlation (or clean the value in Customization)

"Mark accounts whose description starts with SVC as service accounts" Customization

"New AD groups should be non-requestable, with the application owner as owner" Managed Entitlement Customization

"Always add a default home directory when creating Unix accounts" BeforeProvisioning, or better, a Create provisioning policy

  • "Open a ticket after an account is disabled" AfterProvisioning
  • Performance and Safety

The documentation warns that complex rules that act on every record can seriously slow aggregation . Keep per-record rules lean, cache lookups (for example, in a Custom object), avoid database queries for every account, and never commit transactions inside aggregation rules. Test in a sandbox first. A faulty correlation rule can attach accounts to the wrong identities , which is a governance incident.