2 weeks back we have done a change and implemented rehire lifecycle feature in our production environment. but it somehow triggering the leaver lifecycle event and sending multiple leaver notification to the already terminated users and their managers. could you please help us what could be the issue in this case?
Hi @ayadav_12 , Please check the trigger logics for both the lifecycle events, Is there anything common or not and make sure on you trigger logic for both it should be different.
Hi @ayadav_12 ,
This is definitely due to the trigger condition. Kindly revaluate the trigger condition.
If you want to do a quick fix then use a additional identity attribute “isTerminated” flag and set it to true on all terminated users. Next check this condition in your termination trigger condition to avoid the event retrigger. Though this is not a best practice but this can be work as a quick fix until you find the root cause.
we are using the attribute change as event where we are using employee status from previous to new value also in our leaver lifecycle rule we are calling out the employee status value to store. is this somehow correlating? and how can we fix this issue?
Nothing wrong with your Trigger logic and it is OOTB. You need to check your Identity attribute, employee status. If there is a change then only it will trigger the Lifecycle event. So monitor that attribute.
just want to know this is mentioned in leaver lifecycle rule and it’s taking the value from employee status. can it be the cause of the issue?
Also wanted to know how it’s possible that user’s which are already terminated through leaver lifecycle can get multiple leaver lifecycle event initiated once we have enabled rehire. At least it should not consider for already terminated user.
this is how we have implemented rehire event. the previous screenshot i sent to you was from leaver event. Now I am unable to get why multiple leaver events were tiggered for already terminated users. As the leaver event should not be processed for the user who is already terminated. kindly help
Rehire is good, it is just attribute change, nothing can go wrong here. You just need to monitor the attribute and check the attribute config. Once the employeeStatus is set to Active once, see if it is going back to Terminated for any reason.
the initial issue is for muliple leaver lifecycle events were triggered for already terminated users more than 3000 notifications were tiggered on the same day while refresh task was ongoing.
I went over the Orbia-leaver-identitytigger-rule and it looks good. I have a doubt about the contractor part.
If Contractor
if newIdentity.getAttribute(“ctrexpDt”) != null
if data-compare and newIdentity is Active
Looks like a rehire-trigger when ctrexpDt is set and Identity/Contractor becomes Active, this might return true when ctrexpDt is not filled a wrong date.
Are the leaver notifications for Contractors only? If not can you find out what for which group of identities the Leaver is triggered?
It might also be something with the Identity Attributes not being refreshed as expected.
– Remold
PS: There are a few small changes which can make it better, like making it more NPE proof (change previousStatus.equals("Terminated") to "Terminated".equals(previousStatus).
This will not change the logic of the rule, but make it more fail safe.
the inactive status for employee is always true. and usually this doesn’t trigger event for already terminated users. but when rehire joiner event was active after the refresh task this triggered multiple leaver event for single employee was triggered. how is this happen?. can you please help on this.
Did you check if the identity is by any chance satisfying this causing this?
else if(newIdentity.getAttribute("ctrexpDt") != null){
Date ctrexpDt = new SimpleDateFormat("yyyy-MM-dd").parse(newIdentity.getAttribute("ctrexpDt"));
Date currentDt = new Date();
// Check if expiration date is today AND Identity is NOT disabled yet
if((ctrexpDt.compareTo(currentDt) < 0) && !newIdentity.isInactive()){
// ctrexpDt is AFTER currentDt
if((currentDt.getTime() - ctrexpDt.getTime()) / (24*60*60*1000) <= 2){
return true;
}
}
Thank you for replying. This attribute is for contractors only. the issues which we are having is for employees and they don’t have this attribute mentioned.
If this case is only for employees, from rule standpoint, your conditions looks good , there can be a chance where identity is not actually refreshed as expected as mentioned by @Remold
Also please have a look at below thread and validate your leaver workflow if any refresh related subtasks are present.