The assumption
A requirement like "when someone rejoins the business, provision them like a new starter" reads as a one-line ask in a workshop. It usually gets scoped as one. In IdentityIQ specifically, that line hides a real design decision, and getting it wrong doesn't fail loudly: it fails quietly, months later, in an access review nobody can explain.
What IdentityIQ actually does by default
IdentityIQ ships four pre-defined Lifecycle Events: Joiner (Identity Creation), Leaver (an Inactive attribute flipping false to true), Manager Transfer (a Manager Change), and Reinstate (Inactive flipping back from true to false). All four are disabled by default until a deployment turns them on.
There is no separate "Rehire" event. Reinstate is what fires when someone returns, and IdentityIQ's own default behaviour is to correlate the returning person back to their original, still-existing Identity Cube and reactivate it, not create a new one. History, prior entitlements, and the audit trail survive the gap, by design.
The platform's default answer to "what happens when someone comes back" is already an opinion. Most requirements gathering never asks the question, so nobody notices the opinion until it's the wrong one.
A genuine "treat every rehire as a brand-new identity" design is a legitimate choice some organisations do want: a different worker record, a clean slate, no inherited history. It's also a deliberate departure from IdentityIQ's default correlation model, and it costs real implementation effort: either a change to the correlation rule itself, or an explicit override in the Reinstate workflow. Scoped as "standard rehire handling," that cost goes undiscovered until someone's already built against the default and the access review evidence doesn't match what was actually asked for.
Where this bites again: SAP GRC and provisioning order
A related pattern shows up in SAP GRC-integrated provisioning, and it looks like a bug the first time anyone sees it: an application that was never even sent to SAP GRC for risk analysis still visibly waits on a GRC verdict before it provisions.
It isn't a bug, and it isn't a coordination layer someone built badly. A provisioning request stays one undivided plan, inside one workflow case, until MyAccess's Provisioning Broker compiles and partitions it into per-application pieces. GRC's risk-analysis step (send, poll, wait for result) runs earlier than that partitioning step. So every application in the request waits on GRC's answer, including the ones GRC was never actually going to see, simply because the request hasn't been split apart yet at the point GRC is checked.
The practical difference this makes: diagnosing this as "workflow ordering, working as designed" versus "GRC integration bug" changes what you'd even try to fix. One is a real defect to raise with SailPoint or your integrator. The other is a property of the architecture to design around, or simply to explain correctly to whoever's asking why the request is "stuck."
Why this is worth knowing before a migration, not after
Both of these are the kind of behaviour that only surfaces once you actually read the platform's real mechanics, not its marketing description, and not a generic "IAM lifecycle" reference model. That distinction matters most at exactly the moment an organisation is least likely to slow down for it: mid-migration, when years of custom rules and workflow logic built on top of these defaults need to be re-validated against wherever they're moving to, whether that's SailPoint's own Identity Security Cloud or a different platform entirely. A fixed migration date agreed before that inventory exists is a real risk to the programme (a mismanaged migration can silently misconfigure access certification or entitlement enforcement estate-wide), not just an inconvenience if it slips.
Key takeaways
- IdentityIQ has four pre-defined Lifecycle Events (Joiner, Leaver, Manager Transfer, and Reinstate), not three, and not a fourth "Rehire" event that doesn't exist under that name.
- The platform's default on a rehire is to reactivate the same dormant identity, not create a new one. Wanting a fresh identity per rehire is a real, costed design decision, not the out-of-the-box behaviour.
- An application waiting on a SAP GRC verdict it was never sent to is a workflow-ordering effect, not necessarily a defect: know the mechanism before you diagnose it as broken.
- Both are the kind of platform-specific detail that's cheap to get right before a migration or a rehire policy is scoped, and expensive to unwind once evidence has already been produced against the wrong assumption.