The requirement is to send a password notification to the new hire’s manager on their start date. The current setup works when the cube is created before the start date, but it’s not filtering records where the cube creation date and the start date fall on the same day, any thoughts on the search logic?
attributes.startDate:[now/d TO now/d+1d]
Hi,
Duplicate the workflow and use Identity Created trigger, and check if the identity start date is today then send the email. This new workflow will trigger only for new identities whose start date is on same day.
-Abhinov
Hi,
The simple approach will be have a Lifecycle State which will become active when the start date arrives. Once done you can have a workflow with Identity Attribute Change and then trigger the notification for Password.
Just Curious how are you sending the password in the workflow ?
Hi @ssel ,
Just curious on the requirement. Identity will get created on HR aggregation. So, creation date will always be in past than the start date, unless HR updates the record on the same day of the user start date. Also, are you trying to send AD account password over email? This is not possible as password will be encrypted and there is no way to decrypt it.
You can try below:
Create a variable to get the current data and time using below JSON. Change the date format as per the Identity attribute (start date) format.
Now use above variable to do a comparison using “Compare Timestamps“operator.
Before answering your question, did you think about Workflow execution history where all the details will be stored including user password. Don’t you think it is not a good practice to store all the employees initial passwords.
Hi @ssel
I do not recommend sending the password notifications from Workflow and sailpoint also does not recommend that practice, but if you have looked through options and this is the design you are following i would recommend that you create another startDate attribute for this purpose only.
You can refer this thread and create the attribute & transform in same way so you could do a schedule trigger.
Hope this helps…
Thanks, but we can’t proceed this way since the SOA is a standalone database, and IDN simply aggregates the data and assigns the state based on what’s populated in the database — in this case, ‘active’.
Hi @ThejaC , Thanks, the SOA is a standalone database. Yes, we’re sending a customized static password and the users will be prompted to reset it on their first sign in.
@Krishna, right, that’s why we send a custom static password generated with a custom logic pattern and the system will force a password reset the first time when they sign in.
