We have a question about regenerating the password of an identity when they are rehired, meaning when their status changes. I’m not sure what the correct approach would be or if it’s possible to set a new password and send it via a workflow (we know how to do this part) through email. I’ve seen several alternatives, but I’m not sure if they would work. One option is using the API (set-password | SailPoint Developer Community), and another is using a rule, but I’m unsure about the procedure to achieve this within the rule.
Are you re-using the same identity for re-hire case or creating a new identity?
Depending on your solution, if you are re-using the same identity, when the LCS of the user to re-hire/active again,
The before provisioning rule can be used to generate and set the new password in the provisioning policy request. Within the rule, you can check two conditions - 1) if the operation is Enable and 2) if the LCS is for the re-hire then regenerate the new password and set it in the provisioning policy request for the update. You can refer to for BP rule semantics.
Yes, the idea is to reuse the existing identity. The only thing that will change is the status attribute of the identity from passive to active, and at that moment, the rule should be triggered. In fact, we’ve already launched a workflow to handle the entire process for re-hired users.
However, I’m unsure whether resetting the password can be done through the workflow via an HTTP call to the API, as you mentioned, or if it would be more efficient and straightforward to handle it via the rule, as you suggested.
I’d appreciate your guidance on which approach would be the most efficient for this use case.
Considering that workflows are external task triggered after provisioning, and also as they come with their own limitations (on looping, performance etc.), I would suggest using Before provisioning Rule to make this re-hire provisioning as one atomic operation.