A contractor whose contract expired and accounts were disabled has a new contract with the company; the contractor needs all of their previous accounts enabled.
This is not a clean joiner lifecycle event. A joiner event normally represents a person newly entering the organization or being newly onboarded into managed access, usually requiring new identity setup, new accounts, baseline access, roles, approvals, and provisioning. The proposed scenario describes a contractor whose previous relationship ended, whose accounts were disabled, and who now has a new contract requiring previous accounts to be enabled. That is closer to a rehire/reactivation or account-enable lifecycle event than a first-time joiner. The distinction matters in IdentityIQ because a true joiner process may create accounts and assign initial access, while a rehire/reactivation process may restore, enable, or reassess previously existing accounts and access. Treating this as a joiner could create duplicate accounts or duplicate access instead of properly reactivating existing Links/accounts. References/topics: IdentityIQ Engineer — Lifecycle Manager, joiner event, rehire/reactivation, account enablement, identity lifecycle workflow design.
Contribute your Thoughts:
Chosen Answer:
This is a voting comment (?). You can switch to a simple comment. It is better to Upvote an existing comment if you don't have anything to add.
Submit