Most engineers think…
Most people picture identity provisioning as raising a helpdesk ticket and waiting for IT to manually create accounts. In a modern IGA deployment, that model is a liability — too slow, inconsistent, and impossible to audit at scale.
SailPoint IGA automates provisioning through lifecycle states: HR fires an event (new hire, transfer, termination), SailPoint moves the identity to the matching state, and provisioning policies automatically grant or revoke the correct entitlements across every connected system — AD, cloud apps, SaaS — in a single, auditable transaction. Understanding how joiner/mover/leaver maps to lifecycle states and policies is what separates analysts who just run campaigns from engineers who design the identity fabric.
① The three lifecycle events — joiner, mover, leaver
SailPoint IGA organises every identity change into three events. A joiner event fires when a new employee or contractor record appears in the authoritative source (typically the HR system). A mover event fires when an existing identity changes role, department, location or employment type. A leaver event fires when an identity is marked inactive, terminated or transferred out.
Each event is detected by SailPoint's identity refresh or aggregation job and passed to the provisioning engine. The engine maps the event to a lifecycle state, which then determines what policies run. Without this three-event model, organisations end up with stale access accumulating across role changes — the classic access creep that certifications alone cannot cure.
Which SailPoint lifecycle event fires when an employee changes department?
② Lifecycle states — what they are and how transitions work
A lifecycle state in SailPoint is a named condition attached to an identity — for example Active, On Leave, Pre-hire, Terminated. States are configured in the Identity Security Cloud (or IdentityIQ) and can be driven by any attribute from the HR feed, such as employment status, start date, or department code.
When the provisioning engine detects a state change, it evaluates all provisioning policies attached to the new state and calculates the delta — what must be added, removed, or left unchanged across every managed application. This delta is submitted as a provisioning plan and executed through the relevant connectors. The key interview point: a lifecycle state is not just a label — it is a trigger that runs real provisioning logic.
Why state transitions matter for security
When a mover event shifts an identity from Active (Finance) to Active (Engineering), SailPoint can simultaneously revoke Finance-specific entitlements and grant Engineering birthright access — in one atomic operation. Without managed state transitions, the old access simply accumulates alongside the new, creating toxic combinations that fail segregation-of-duties checks.
Fires when a new identity appears in the HR feed. SailPoint moves it to an Active lifecycle state and grants all birthright entitlements automatically on day one.
Fires on a role, department or employment-type change. SailPoint computes the delta — revokes old entitlements, grants new birthright access — in one atomic provisioning plan.
Fires on termination or inactive status. Deprovisioning policy disables all accounts immediately, then deletes after a configurable retention window.
The SailPoint object that maps a lifecycle state (or role) to a set of entitlements. When a state changes, the policy calculates what to grant or revoke across every connected system.
Interviewers expect you to distinguish the event (joiner/mover/leaver) from the lifecycle state (Active, Terminated, On Leave). Events are inputs; states are configuration objects in SailPoint that hold provisioning policies. A single event can transition through multiple states — for example, a joiner can move Pre-hire → Active in two steps with different policies at each stage.
What does a SailPoint lifecycle state transition actually trigger?
③ Birthright access and provisioning policies
Birthright access is the set of entitlements every identity in a given role or department automatically receives — Active Directory group memberships, email, collaboration tools, VPN group — without any manual approval. In SailPoint, birthright access is defined in provisioning policies (in IdentityIQ) or via access profiles and roles (in Identity Security Cloud) attached to the relevant lifecycle state.
On a joiner event the provisioning engine looks up the new identity's attributes (department, role, location), maps them to the matching role or policy, and issues accounts and entitlements to every connected system in a single provisioning plan. This is what makes day-one access possible without a helpdesk ticket.
Birthright vs discretionary access
Entitlements outside birthright — elevated admin roles, project-specific access, shared accounts — require a separate access request and approval workflow. Keeping birthright and discretionary access separate is a governance best practice: birthright is audited automatically at every lifecycle event, while discretionary access is reviewed in certification campaigns. Mixing them makes both harder to certify.
The most common IGA design mistake is stuffing elevated permissions into provisioning policies alongside true birthright entitlements. This means every certification campaign must review admin roles that should never have been automatic in the first place. Keep birthright lean — email, basic AD groups, standard SaaS licences — and route everything else through access request with approval.
▶ Watch a new joiner get provisioned automatically
Follow a day-one hire from HR record to live accounts in every system. Press Play for the healthy path, then Break it to see the most common failure.
A new analyst joins the finance team. Which SailPoint mechanism grants their AD account and email without a helpdesk ticket?
④ Deprovisioning — leaver controls and orphan prevention
The leaver event is where most audit findings originate. When an HR termination record arrives, SailPoint must move the identity to a Terminated (or equivalent) lifecycle state and trigger deprovisioning policies that revoke all accounts and entitlements. Depending on policy, this can be immediate (disable AD account, revoke all SaaS licences) or staged (disable on day 1, delete after a retention window).
The most common gap is orphaned accounts — accounts in managed systems with no correlated SailPoint identity, usually left behind from incomplete leaver processing or pre-IGA on-boarding. SailPoint's aggregation and correlation jobs surface these; most teams add an orphan remediation workflow that flags or auto-disables uncorrelated accounts on a schedule.
What a clean leaver process looks like
A clean leaver flow: HR marks the employee inactive → aggregation picks up the change → SailPoint sets lifecycle state to Terminated → deprovisioning policy disables all accounts → a review task confirms no active entitlements remain → the identity is archived with full history for audit. The audit trail in SailPoint shows every entitlement revoked, by which policy, at what time — critical evidence for compliance reviews.
Priya at a Mumbai NBFC faces this
A terminated analyst still has active Salesforce and SharePoint access two weeks after their last working day, flagged by the external auditor.
The leaver event was captured in HR but the SailPoint aggregation job runs nightly and the deprovisioning policy only triggered for AD — Salesforce and SharePoint connectors were not mapped to the Terminated lifecycle state.
Check SailPoint IGA: open the identity, inspect the lifecycle state (should be Terminated), then check the provisioning policy for Terminated — Salesforce and SharePoint are missing from the policy's managed application list.
SailPoint IGA ▸ Identity ▸ Lifecycle State ▸ Provisioning Policy ▸ Managed ApplicationsAdd Salesforce and SharePoint to the Terminated state deprovisioning policy. Re-run the provisioning plan for the affected identity. Enable real-time SCIM provisioning for SaaS apps to cut the aggregation delay to minutes.
Confirm the Salesforce and SharePoint accounts are disabled in both systems, and that the SailPoint identity audit trail shows the deprovisioning action with timestamp — ready to hand to the auditor.
Never close a leaver ticket on 'should be done'. Open SailPoint, pull the identity's provisioning history, and confirm every managed application shows a disable or delete action with a timestamp. That single page is your evidence for a compliance audit — screenshot it and attach it to the ITSM ticket before marking resolved.
A SOC audit finds active accounts in Salesforce with no matching SailPoint identity. What is the most likely root cause?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
In one line: what is the difference between a lifecycle event and a lifecycle state in SailPoint? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Joiner event
- A SailPoint lifecycle event fired when a new identity appears in the authoritative HR source, triggering an Active lifecycle state and birthright access provisioning.
- Mover event
- A lifecycle event fired when an existing identity changes role, department or employment type, causing SailPoint to compute an access delta and re-provision accordingly.
- Leaver event
- A lifecycle event fired on termination or inactive status, triggering a Terminated lifecycle state and deprovisioning of all accounts.
- Lifecycle state
- A named condition in SailPoint IGA (e.g. Active, On Leave, Terminated) that holds provisioning policies; transitioning states fires the provisioning engine.
- Provisioning policy
- A SailPoint object mapping a lifecycle state or role to a set of entitlements on managed applications; evaluated at every lifecycle state transition.
- Birthright access
- Entitlements automatically granted to every identity in a given role or department at joiner or mover time, without an approval workflow.
- Orphaned account
- An account in a managed application with no correlated SailPoint identity — typically left by incomplete leaver processing or pre-IGA account creation.
- Provisioning plan
- The atomic set of grant and revoke operations SailPoint submits to connectors after evaluating a provisioning policy delta.
📚 Sources
- SailPoint — SailPoint Identity Security Cloud: lifecycle management documentation. documentation.sailpoint.com
- SailPoint Help — Provisioning policies and lifecycle states (IdentityIQ). documentation.sailpoint.com/identityiq
- SailPoint Help — Joiner, mover, leaver workflows and birthright access configuration. documentation.sailpoint.com
- SailPoint Community — Best practices for deprovisioning and orphan account management. community.sailpoint.com
- SailPoint — Identity Security Cloud: roles, access profiles and automated provisioning. documentation.sailpoint.com/saas
- Gartner — Market Guide for Identity Governance and Administration (IGA), 2025. gartner.com
What's next?
Got the lifecycle flow? Next, go deep on SailPoint access certifications — how campaigns, reviewers and auto-revoke decisions keep ongoing access clean between lifecycle events.