6.2 The Purpose of Common Certification Rules

The Purpose of Common Certification Rules

Objective 3.2 asks you to understand the purpose of common certification rules. The exam usually gives a requirement and asks which rule type satisfies it, or where in the certification timeline it runs. The documentation lists the certification rules in the order they run.

The Rules in Execution Order

Other rule types appear on certification pages. Certifier rules pick the primary certifier in targeted certifications. EmailRecipient rules add reminder and escalation recipients. SailPoint ships starting-point examples in examplerules.xml.

Exclusion Rule

Use it to keep noise out of reviews, such as a birthright entitlement every employee has, or to skip whole identities, such as inactive users or executives. The rule receives the entity being certified (for identity-based certifications, an Identity), the list of items that would be certified, and an empty itemsToExclude list. It moves items from one list to the other and returns an optional explanation string that appears on the exclusions list.

import sailpoint.object.Identity;
String explanation = "";
Identity person = (Identity) entity;
if (person.isInactive()) {
    itemsToExclude.addAll(items);
    items.clear();
    explanation = "Not certifying inactive identities";
}
return explanation;

Select Save Exclusions on the certification to keep the excluded items for reporting.

Pre-Delegation Rule

A pre-delegation rule runs during generation and can send part or all of a review to someone else before the reviewer sees it. For example, every privileged account could go to the security team. In targeted certifications, the documentation notes that pre-delegation rules still support delegation and forwarding, but reassignment components are ignored. Use a Certifier rule in the Primary Certifier field to control reassignments instead. Pre-delegation and pre-reassignment rules are not meant to run together with the Fallback Forwarding User rule.

Sign-Off Approver Rule: Multi-Level Sign-Off

When a reviewer signs off, this rule decides whether someone else must approve the decisions. It receives the certification and the certifier who signed. It returns a Map with either identity or identityName for the next approver, or nothing to end the chain. The process repeats until the rule returns no approver:

import java.util.HashMap;
import java.util.Map;
Map result = new HashMap();
if (certifier.getManager() != null) {
    result.put("identity", certifier.getManager());
}
return result;

With a challenge period, the sign-off approver can override only approval decisions. Revocations the access holder has already seen in a challenge work item cannot be changed in the approver's view.

Phase-Change, Escalation, and Closing Rules

• CertificationPhaseChange rules are hooks for custom actions at the start of a phase, such as opening a ticket when the revocation period starts or emailing a summary when the End period starts.
• WorkItemEscalationRule rules run when an escalation is due and transfer ownership, not just send email.
• A CertificationAutomaticClosing rule runs at the start of automatic closing, after the Active phase (or Challenge phase, if enabled) and the configured delay. It can apply more complex logic than the simple "revoke/approve/exception" action on undecided items.

Building and Testing Certification Rules Safely

• Start from the samples. Import the examples in examplerules.xml and copy the one closest to your need, so the rule type and input variables are right.
• Keep generation rules fast. Exclusion, pre-delegation, entity-selector, and certifier rules run for every entity during generation. A slow database lookup inside them can make a large certification take hours. Load reference data once, for example from a Custom object, instead of querying repeatedly.
• Test on a staged certification. Enable staging (section 6.1) so the rule's effect (excluded items, delegations, certifier assignments) can be inspected before any reviewer is notified.
• Log what the rule decides. Use log.debug with a dedicated logger (section 14.1) and return a meaningful exclusion explanation so auditors can see why items were left out.

Choosing the Right Rule