What Are Lifecycle Events in SailPoint IIQ?
Lifecycle events in SailPoint IIQ are automated triggers that detect changes in an employee's status and launch provisioning or de-provisioning workflows in response. When someone joins, leaves, moves within, or returns to an organisation, the corresponding lifecycle event fires — adjusting that person's access across every connected application and system, automatically and in real time.
They are configured in Module 12 of the SailPoint IdentityIQ curriculum under the Lifecycle Manager component, and they are one of the most important and interview-tested capabilities in the entire IIQ platform. SailPoint IIQ ships with four pre-built lifecycle events: Joiner, Leaver, Mover, and Rehire. By default, all four are disabled — they must be explicitly enabled and configured before they can fire.
Why this matters in practice: Without lifecycle events, access provisioning and de-provisioning in an enterprise must be done manually — a process that is slow, error-prone, and non-compliant with regulations like India's DPDP Act 2023, RBI IT Governance Guidelines, and global SOX requirements. Lifecycle events are the mechanism that makes identity governance auditable and automated.
How Are Lifecycle Events Triggered in SailPoint IIQ?
Lifecycle events are not triggered by a button click — they are triggered automatically through a specific sequence involving aggregation, identity refresh, and event processing. Understanding this sequence is essential because it is what interviewers test when they ask "how does a lifecycle event fire?"
1. HR Source Update
Employee status changes in Workday, SAP SF, or HR DB
2. Aggregation Job
IIQ pulls updated records from the authoritative source
3. Identity Refresh
IIQ compares new vs stored attributes on each identity
4. Event Detection
Trigger condition matches — lifecycle event fires
5. Workflow Runs
Business process executes the provisioning plan
The critical configuration point in this sequence is the Identity Refresh task. The "Process Events" option on the Identity Refresh task must be enabled. If it is not checked, aggregation will update the identity cube attributes — but the lifecycle event will never fire, even if the trigger condition is met. This is a common misconfiguration in IIQ implementations and a frequent interview gotcha question.
The most common lifecycle event misconfiguration
Aggregation runs, identity attributes update, but the Joiner event never fires. The cause: "Process Events" is not enabled on the Identity Refresh task. Always verify this setting first when debugging lifecycle event failures — it is missed more often than any other configuration step.
The Four Lifecycle Events at a Glance
Each of the four lifecycle events addresses a distinct employee status change. Here is a side-by-side overview before we go deeper into each one:
| Event | Trigger | Primary Action | Priority |
|---|---|---|---|
| Joiner | New identity appears in HR source | Provision birthright access | High |
| Leaver | Employment status → Terminated | Disable / remove all accounts | High |
| Mover | Role, dept, manager, or location change | Adjust entitlements for new role | Lower |
| Rehire | Previously terminated identity returns | Re-enable disabled accounts | High |
One rule governs event priority: Joiner and Leaver always take precedence over Mover. If IIQ detects that an identity qualifies for both a Leaver and a Mover event in the same Identity Refresh cycle, only the Leaver runs. This prevents partial de-provisioning from conflicting with a simultaneous mover workflow.
The Joiner Event — Provisioning Birthright Access for New Hires
The Joiner lifecycle event fires when a brand-new identity appears in the authoritative HR source during aggregation — an employee who had no prior identity cube in IIQ. Its purpose is to provision birthright access: the baseline set of accounts and entitlements every new employee in a given role should automatically receive on Day 1.
What Gets Provisioned
Birthright provisioning through the Joiner workflow typically covers the following for a standard enterprise employee:
- Active Directory account creation
- Corporate email account (Exchange / M365)
- VPN access based on location
- Role-based entitlements from assigned Business Role
- Application access by department and job code
- Badge / physical access systems (where integrated)
Joiner Configuration Logic
In SailPoint IIQ, the Joiner event is linked to a business process (workflow). The default Joiner workflow writes the identity name to sysout — it must be customised to provision actual access. The key configuration decisions are:
- Which attributes define a "new" identity (typically employee ID)
- Which roles map to which job codes or departments
- Approval chain: auto-provisioned or manager-approved
- Provisioning plan targets (which apps to onboard)
The Leaver Event — Termination De-provisioning
The Leaver lifecycle event fires when an employee's status in the HR source changes to terminated, resigned, or inactive. Its purpose is to immediately disable or revoke all access that identity holds — across every application IIQ manages — so that a departed employee cannot retain access to enterprise systems.
What Gets De-provisioned
The default IIQ Leaver workflow creates and executes a provisioning plan to disable all accounts the departing identity holds. In a typical enterprise deployment this means:
- Active Directory account disabled immediately
- Email account disabled or forwarded to manager
- All SaaS and enterprise app access revoked
- VPN certificates and tokens deactivated
- Privileged access (PAM) accounts disabled
- Audit trail generated for compliance evidence
Compliance and Security Context
The Leaver event is often the most compliance-critical lifecycle event. Regulations explicitly require timely access revocation on termination:
- RBI IT Governance: mandates same-day access revocation for financial institutions
- SOX: requires evidence that terminated employees cannot access financial systems
- DPDP Act 2023: requires data access revocation on termination
- SOC 2: auditors check leaver workflows for evidence of controls
Attend a free 60-minute live demo before you decide.
See exactly how Module 12 — Lifecycle Events — is taught in SailPoint Academy's live IIQ program. No payment, no commitment.
The Mover Event — Role and Department Transfers
The Mover lifecycle event fires when an existing employee changes role, department, manager, reporting location, or any other attribute that constitutes a "move" as defined in IIQ's Global Settings. Its purpose is to adjust the employee's access to reflect their new position — removing entitlements that belong to their old role and provisioning entitlements for their new one.
What Triggers a Mover Event
A Mover event is triggered when IIQ detects an attribute change on an existing identity during Identity Refresh. Common triggers in enterprise deployments:
- Department or business unit change
- Job title or job code change
- Manager change (direct manager attribute)
- Location change (city, office, country)
- Cost centre change
- Employment type change (full-time → contractor)
Access Adjustment Logic
The Mover workflow typically performs a two-phase access adjustment. The exact logic depends on how role management and provisioning plans are configured:
- Revoke: Remove Business Role entitlements tied to old dept/job code
- Assign: Provision Business Role entitlements for new dept/job code
- Preserve: Retain explicitly approved individual entitlements
- Notify: Send email to new manager / HR for approval if configured
Mover and SoD (Segregation of Duties)
The Mover event is where SoD violations most commonly occur in enterprise environments. When an employee moves from Finance to Procurement, they may briefly hold entitlements in both domains — creating a SoD conflict. IIQ's Policy Management module (Module 8) works in conjunction with Mover events to detect and flag these violations during the transition. This intersection of Mover + Policy Management is a common advanced interview question at BFSI GCCs.
The Rehire Event — Reinstating Returning Employees
The Rehire lifecycle event handles the scenario of a previously terminated employee who rejoins the organisation. Without a dedicated Rehire event, IIQ would treat the returning person as a brand-new Joiner — creating a duplicate identity, provisioning fresh accounts, and leaving the old disabled accounts as orphans.
How Rehire Works
IIQ uses identity matching rules to recognise a returning employee. Instead of creating a new identity cube, IIQ matches on unique identifiers (employee ID, email, national ID) and HR attributes to detect the returning person's existing record. The Rehire workflow then:
- Re-enables previously disabled accounts
- Restores access based on new role (not old role)
- Removes the Leaver lifecycle state flag
- Runs a fresh Joiner-equivalent provisioning plan
What Goes Wrong Without It
Without a properly configured Rehire event, returning employees create serious IAM problems that are common in enterprise implementations:
- Duplicate identity cubes — two records for one person
- Old entitlements re-enabled without review
- New access layered on top of old — access accumulation
- Audit trails break — two identity histories for one person
- SoD violations from merged entitlement sets
How Lifecycle Events Connect to Enterprise HR Systems
Lifecycle events depend entirely on the quality and timeliness of data from the authoritative HR source. In most Indian enterprise SailPoint deployments, the authoritative source is one of three systems: Workday, SAP SuccessFactors, or a custom HR database. The quality of the lifecycle event implementation is only as good as the HR data feeding it.
Workday Integration
Workday is the most common authoritative HR source in BFSI GCCs. IIQ connects to Workday via the Workday connector or a Datafile export. Employee status, job code, department, manager, and location attributes flow directly into lifecycle event triggers.
SAP SuccessFactors
SAP SF is common in IT services majors and manufacturing GCCs. IIQ aggregates identity data from SuccessFactors via a direct connector or HR data extract, using employment status and position change attributes to fire Joiner, Mover, and Leaver events.
Custom HR Database
Many mid-size Indian enterprises use a custom HR database as the authoritative source. IIQ connects via JDBC or a Datafile connector. The aggregation schema must map HR fields to IIQ identity attributes for lifecycle events to trigger correctly.
Aggregation Frequency
How often the aggregation job runs determines how fast lifecycle events fire after an HR change. Most enterprise deployments run aggregation every 4–8 hours. BFSI GCCs with strict termination SLAs often run real-time or near-real-time feeds for the Leaver event specifically.
Why Lifecycle Events Is the Most Tested Module in SailPoint IIQ Interviews
Of the 14 modules in the SailPoint IIQ curriculum, Module 12 — Lifecycle Events — is the single most consistent topic in technical interviews across all experience levels. Here is why, and what interviewers actually test at each career stage:
At IAM Analyst level: "What are the four lifecycle events?"
Interviewers expect you to name all four, define each one, and correctly state the priority rule (Joiner/Leaver over Mover). Candidates who say "Joiner, Leaver, Mover" and omit Rehire, or who cannot explain event prioritisation, fail this round.
At Consultant level: "How does a lifecycle event get triggered?"
Interviewers test the full trigger sequence — aggregation → identity refresh → Process Events checkbox → workflow. Candidates who cannot explain why a Joiner event did not fire (Process Events was disabled) demonstrate a gap that fails mid-level interviews.
At Senior level: "What happens when a Mover and Leaver fire simultaneously?"
This tests event priority knowledge. The correct answer: only the Leaver runs. Interviewers at BFSI GCCs also ask how SoD policy violations are handled during a Mover event — requiring knowledge of Policy Management (Module 8) alongside Module 12.
At all levels: "What is a Rehire event and why do you need it?"
Most candidates describe Rehire as "just another Joiner for someone who comes back." The correct answer includes identity matching rules, why duplicate identities are a problem, and how IIQ avoids creating a new identity cube for a returning employee.
"What does birthright access mean in the context of a Joiner?"
Birthright access is the baseline set of entitlements every new employee in a given role receives automatically — without individual approval. Interviewers test whether you can map the Joiner event to the Business Role framework (Module 7) that defines what birthright means per job code.
"Walk me through configuring a Joiner event from scratch."
At Consultant and Senior level, interviewers ask you to walk through configuration steps end-to-end. The answer must cover enabling Lifecycle Manager, identifying the authoritative source, enabling the event, mapping the workflow, and enabling Process Events — in the right order.
For a broader set of IIQ interview questions across all 14 modules, read our SailPoint IIQ interview questions guide. For context on where lifecycle events fit in the overall SailPoint career path, see our SailPoint career path in India guide.
How to Configure Lifecycle Events in SailPoint IIQ — Key Steps
Lifecycle event configuration in IIQ follows a defined sequence. The steps below reflect how this is taught in SailPoint Academy's live program — focused on what you need to know for both real enterprise implementation and technical interviews. For full platform documentation, refer to the official SailPoint IdentityIQ documentation.
- Enable Lifecycle Manager in System Configuration. Navigate to Admin → System Configuration and enable the Lifecycle Manager module. Without this, lifecycle events cannot be created or triggered.
- Identify and verify the authoritative HR source. Confirm which application is the authoritative source (Workday, SAP SF, HR DB). Aggregation from this source is what drives all lifecycle event detection.
- Enable each lifecycle event in Global Settings. Go to Admin → Global Settings → Lifecycle Events. Enable Joiner, Leaver, Mover, and Rehire individually. Configure the trigger attribute or condition for each event type.
- Associate a business process (workflow) to each event. Each lifecycle event must point to a workflow that defines what provisioning actions to take. Customise the default IIQ workflow or build a new one — the default Joiner workflow only prints to syslog and provisions nothing until modified.
- Enable "Process Events" on the Identity Refresh task. This is the most frequently missed step. Open the Identity Refresh task definition and ensure the Process Events checkbox is selected. Without this, no lifecycle event ever fires.
- Run aggregation and test with a controlled identity change. Change a test employee's status in the HR source, run aggregation, then run Identity Refresh. Verify the lifecycle event fired, the correct workflow launched, and the provisioning plan executed as expected.
In SailPoint Academy's live training, students configure all four lifecycle events hands-on using a lab environment that simulates a real enterprise HR source. This is covered in Module 12 of the SailPoint IIQ course and is directly mapped to the kind of configuration walkthrough interviewers ask candidates to describe.
Frequently Asked Questions
Explore More from SailPoint Academy
Attend a Free 60-Minute IIQ Demo
See how lifecycle events — Joiner, Leaver, Mover, and Rehire — are taught hands-on in our live SailPoint IIQ program. No payment, no commitment.