SailPoint IIQ Lifecycle Events Guide 2026: JML Automation

Quick Answer: SailPoint lifecycle events are triggers that fire when an identity is created, updated or deleted, or when specific identity attributes change — the automation hooks behind joiner, mover and leaver (JML) processes. A lifecycle event couples a trigger condition to an event handler (a BeanShell rule or workflow). Used well, they deliver hire-to-provisioned in minutes; used carelessly, they turn an HR feed hiccup into 400 unwanted provisioning actions. The sections below cover the firing sequence, a minimal handler, and the design rules that separate the two outcomes.

How Lifecycle Events Actually Fire

The sequence: an identity aggregation or refresh detects an identity is new or changed. IIQ evaluates the event registry — each event has a trigger type (identity created, attribute changed, identity deleted) and optional filtering logic. When the condition matches, the attached handler executes: usually launching a workflow such as the standard “Identity Request Joiner” style flows or a custom one. Handlers run synchronously by default — which is why a slow handler can throttle the very refresh that triggered it. Design rule one: handlers hand off to workflows and return quickly.

A Minimal Event Handler in BeanShell

A handler that decides whether a joiner event should provision at all — guard clauses first:

import sailpoint.object.Identity;
import org.apache.log4j.Logger;

Logger log = Logger.getLogger("custom.onboarding");

if (event == null || identity == null) {
    log.warn("Lifecycle event: missing context, skipping");
    return;
}

String empStatus = identity.getStringAttribute("empStatus");
if (!"HIRE".equals(empStatus)) {
    log.info("Ignoring event for identity " + identity.getName()
        + " status=" + empStatus);
    return;
}

String manager = identity.getStringAttribute("manager");
if (manager == null || manager.isEmpty()) {
    log.error("Joiner " + identity.getName() + " has no manager; "
        + "holding birthright provisioning");
    return;
}

// Hand off to the provisioning workflow - do not provision inline
Map args = new HashMap();
args.put("flow", "Provisioning Initialization");
args.put("identityName", identity.getName());
workflow.launch("Lifecycle Provisioning", args);

Three habits in that snippet keep productions sane: guard on nulls, decide explicitly what not to act on, and delegate heavy work to a workflow. More rule patterns live in the BeanShell examples guide.

Movers: The Event Everyone Underestimates

Joiners and leavers get the design attention; movers generate the tickets. A department transfer changes the identity’s attributes, which should recalculate roles — but cascading events (attribute change fires handler A, which modifies another attribute, which fires handler B) can provision twice or fight each other. Defenses: idempotent handlers (running twice changes nothing), event filtering so only meaningful changes trigger, and a mover test case that covers two transfers in sequence — because the second transfer is where stale state bites.

A Production Story Worth Retelling

An insurance client’s leaver handler disabled accounts immediately on the “termination date” attribute — but HR populated that field with a future date for notice periods, while a separate “last working day” field carried the real one. Result: the moment the feed included a future-dated termination, hundreds of still-employed contractors lost access at 8 a.m. The fix was semantic, not technical: one attribute renamed in the mapping, one handler condition updated, one runbook line added. Lifecycle design fails on data meaning far more often than on code.

Design Rules That Survive Audits

• Idempotent or dead: any handler that cannot run twice safely will eventually run twice.
• Guard every attribute: feeds change shape; null checks are the cheapest insurance in the codebase.
• Delegate, do not inline: handlers decide; workflows act.
• Log with identity names: your future self debugging at 2 a.m. is the audience.
• Test all three letters of JML: most shops test joiner, skip mover, and regret leaver.
• Name events by what triggers them: “Identity.Created.JoinerIN” beats “event1” in every audit and every 2 a.m. page.
• Name events by what triggers them: “Identity.Created.JoinerIN” beats “event1” in every audit and every 2 a.m. page.

Event Registry Hygiene

Every IIQ environment has an event registry — the configuration mapping event types to handlers — and almost every environment has entries nobody can explain. Registry hygiene is a small discipline with outsized payoff. Document every active event: what triggers it, which handler it runs, which workflow it launches, and who asked for it originally. Disable rather than delete the entries that lost their owners, with a comment saying when and why. Review the registry after every upgrade, because event-type behaviour is exactly the kind of platform default that shifts between versions. And keep the naming convention consistent with the design rules above — a registry anyone can read is a handover asset; a registry only one consultant understands is a hostage situation. The IIQ glossary defines the event vocabulary, and the connectors guide covers the feed side that fires most events in the first place.

Training Resources

Lifecycle event labs — including a deliberately broken feed exercise — are part of the SailPoint IdentityIQ Certification Training. The identity request lifecycle guide covers what happens after the event hands off, and the IIQ roadmap places this skill in the developer track. If you are mapping skills across the identity domain rather than IIQ alone, the IAM training track is the wider map — JML patterns repeat across every IGA platform.

Lifecycle event labs — including a deliberately broken feed exercise — are part of the SailPoint IdentityIQ Certification Training. The identity request lifecycle guide covers what happens after the event hands off, and the IIQ roadmap places this skill in the developer track. If you are mapping skills across the identity domain rather than IIQ alone, the IAM training track is the wider map — JML patterns repeat across every IGA platform.

FAQ

What are lifecycle events in SailPoint IIQ?

Triggers attached to identity changes — created, modified (attribute-level), deleted — that execute handler logic, usually launching provisioning or deprovisioning workflows. They are the automation layer for joiner, mover and leaver processes.

How do lifecycle events differ from workflows?

The event is the trigger; the workflow is the worker. A lifecycle event detects a change and launches a workflow which performs approvals and provisioning steps. Handlers should stay small; complex logic belongs in workflow XML — a handler that grows past a screen is a workflow waiting to be refactored.

Can lifecycle events cause duplicate provisioning?

Yes, when handlers are not idempotent or when cascading attribute changes fire multiple events. Design handlers to be safely re-runnable, filter on meaningful changes only, and test mover scenarios with repeated transfers — the transfer-in-place bug is the most common mover defect in the field.

What is the most common lifecycle event mistake?

Trusting attribute semantics: firing on a termination date that HR populates with a future date, or provisioning before required attributes (manager, department) arrive in the feed. Validate data meaning, not just data presence, because both look identical in a feed file.

Do lifecycle events run for account changes too?

There are separate event types for identity changes and account-level changes. Identity events drive JML automation; account events support correlation and cleanup logic. Check the event registry configuration to see which are active in your environment.

Written by SkilBrill Training Institute

October 25, 2026 · 7 min read