Most SailPoint IdentityIQ teams automate certification campaigns the wrong way first: they go looking for an iiq console command or a script to launch a campaign programmatically, the way you might script an aggregation task. That path doesn’t exist — the console explicitly has no certification-scheduling functionality, and its default 128 MB heap can’t hold the objects a real campaign generates even if it did. IdentityIQ automates certifications through two mechanisms built for the purpose instead: recurring schedules baked into the certification definition, and event-driven campaigns that fire off an identity change rather than a clock. This guide covers both, plus the BeanShell rules that keep an automated campaign from burying reviewers in noise.
If you haven’t built a BeanShell rule for IdentityIQ before, start with our BeanShell Rules, Workflows, and Tasks guide and the Certification Exclusion Rule walkthrough in our rule cookbook — this article builds directly on the exclusion rule pattern covered there.
Recurring Certifications: Automation Through the Schedule, Not a Script
The Schedule Certification wizard’s Basic page is where most certification automation actually lives, and it’s easy to underuse. Every non-targeted certification type — Manager, Application Owner, Entitlement Owner, Advanced, Account Group Membership, Account Group Permissions, Role Membership, Role Composition, and Identity — supports a recurrence frequency (daily, weekly, monthly, quarterly, or annual) directly on that page. Once configured, IdentityIQ launches the next campaign in the series on schedule with no further action, using the same certifier assignment logic, rules, and notification templates as the campaign before it.
Two settings on that same page matter more for automation than they get credit for:
- Staged activation. Setting Activation Method to Staged means the certification generates its
CertificationEntityandCertificationItemobjects but does not notify certifiers or start the clock on any phase. This is the safe way to let a recurring campaign generate automatically while still reviewing what it produced before reviewers see it — useful in the first few cycles after standing up a new recurring campaign, or any time you’ve changed an exclusion or pre-delegation rule attached to it. - “Use Certification as a Template.” Right-clicking an existing certification and selecting this option copies its full configuration — rules, notification settings, recurrence — into a new definition. For teams standardizing a recurring campaign across multiple business units, this is faster and less error-prone than rebuilding the Advanced Settings rule attachments from scratch each time.
Certification Events: Automation Triggered by Identity Changes
Recurring schedules cover the calendar-driven case — quarterly access reviews, annual recertification. They don’t cover the case where access needs review because something changed, and waiting for the next scheduled cycle leaves a window where stale access sits unreviewed. Certification Events close that gap by launching a certification automatically when a specific condition is detected during an identity refresh cycle, rather than on a schedule:
| Event Type | Fires When |
|---|---|
| Create | A new identity is discovered in IdentityIQ |
| Manager Transfer | An identity’s manager attribute changes |
| Attribute Change | A configured identity attribute is modified |
| Native Change | A change is detected directly on a native application account |
| Alert | An enterprise alert condition is triggered |
| Rule | Custom BeanShell logic determines when the event fires |
Manager Transfer is the one most deployments configure first, and for a specific reason: when a manager reassignment happens outside a scheduled campaign window, the identity’s access can go unreviewed by anyone with real context on it until the next periodic certification runs — which might be months away. A Manager Transfer event instead generates a targeted access review for the new manager as soon as the transfer is detected on the next refresh, so the person who actually knows the role reviews the access close to when the change happened, not on a quarterly delay.
The Rule event type is the escape hatch for anything the five built-in triggers don’t cover — a custom BeanShell rule evaluates during the refresh cycle and returns whether the event should fire for a given identity, giving you the same flexibility as a scheduled campaign’s Advanced Settings rules, but on an event-driven cadence instead of a fixed one.
Tuning an Automated Campaign With Exclusion and Pre-Delegation Rules
An automated campaign that runs unattended needs tighter guardrails than one a human schedules manually, because there’s no one glancing at the certifier list or entity count before it goes out. Two rule types, both configured under Certifications → Certification Schedule → Advanced Settings, do most of that work:
Exclusion rules remove specific certifiable items before the reviewer ever sees them — disabled accounts, or entitlements already justified through an assigned role. The full working example, including the instanceof guard you need because certifiableEntities mixes EntitlementCertifiable, BundleCertifiable, and PolicyViolationCertifiable objects, is in the rule cookbook’s Exclusion Rule section. For an automated, recurring or event-driven campaign, this rule matters more than it does for a one-off manual certification — a manager who gets the same noisy 40-item review every quarter without it starts rubber-stamping the whole thing, which defeats the point of certifying at all.
Pre-delegation rules route specific access reviews to someone other than the identity’s default certifier — for example, sending every entitlement on a high-risk financial application to a dedicated application-security reviewer instead of the identity’s line manager, regardless of who that manager happens to be this quarter. This is the rule type that makes automated campaigns viable for sensitive applications: without it, an unattended Manager Transfer event could route a privileged entitlement review to a brand-new manager who has no basis to evaluate it.
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="Delegate Financial App Entitlements to AppSec" type="CertificationPreDelegation">
<Description>
Routes certifiable entitlements on the "GL-Finance" application to a dedicated
application-security reviewer instead of the identity's manager, regardless
of certification type or trigger (scheduled or event-driven).
</Description>
<Signature returnType="java.lang.String">
<Inputs>
<Argument name="context" type="sailpoint.api.SailPointContext"/>
<Argument name="identity" type="sailpoint.object.Identity"/>
<Argument name="certifiable" type="sailpoint.object.Certifiable"/>
</Inputs>
</Signature>
<Source><![CDATA[
import sailpoint.object.EntitlementCertifiable;
import sailpoint.object.EntitlementSnapshot;
if (!(certifiable instanceof EntitlementCertifiable)) {
return null;
}
EntitlementCertifiable ec = (EntitlementCertifiable) certifiable;
EntitlementSnapshot snap = ec.getEntitlements();
if (snap != null && "GL-Finance".equals(snap.getApplicationName())) {
return "appsec.reviewer";
}
return null;
]]></Source>
</Rule>
Returning null leaves the certifier assignment untouched — the rule only overrides the specific items it matches, which is what lets it run safely across every certification type and trigger without needing a separate rule per campaign.
Validating Before an Automated Campaign Goes Live
The failure mode that matters most for automated campaigns is the quiet one: an exclusion rule that over-excludes, or a pre-delegation rule with a typo in the target identity name, produces a certification that looks complete in the UI with no error and no warning. Nobody scheduled it manually, so nobody is watching for it to look wrong.
Before attaching a new or changed rule to a recurring schedule or a Certification Event:
- Run once as Staged. Generate the campaign without activating it, and inspect the
CertificationEntityandCertificationItemcounts. - Diff against a version without the rule. Generate the same campaign scope with the rule detached and compare counts — a large, unexplained drop is the signature of an over-broad exclusion.
- Log every match inside the rule, not just a final count. A rule that excludes or delegates zero items is frequently the same underlying bug as one that excludes everything: a null check or comparison that always short-circuits. The log is what tells you which failure mode you’re looking at, because the campaign output alone can’t.
Once a staged run confirms the rule behaves as expected, flip Activation Method back to whatever the live campaign needs (Automatic or Manual) and let the recurrence or event trigger take over from there.
Clone the companion repo: Working exclusion and pre-delegation rule templates, plus the staged-certification diff script referenced above, are in IAMDevBox/sailpoint-iiq-rule-cookbook — the same repo backing our BeanShell Rule Cookbook article. Note the diff script counts certification items, which confirms a pre-delegation rule didn’t change what’s certified — it doesn’t confirm who the reviewer changed to, so still spot-check a few reassigned entities in the UI before activating.
Related Reading
- SailPoint IdentityIQ BeanShell Rule Cookbook: Provisioning and Certification Rules — the Exclusion Rule pattern this article builds on
- SailPoint IdentityIQ BeanShell Rules, Workflows, and Tasks Developer Guide — foundational rule types and the workflow engine that certification generation runs on
- SailPoint IdentityIQ Aggregation Troubleshooting: Complete Error Guide — diagnosing the identity refresh cycle that Certification Events depend on
