Rehire joiner lifecycle event Issue

Hi,

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.

1 Like

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.

1 Like

Hi @Vb_Bellamkonda

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.

1 Like

What version of IIQ is this?

Hi @Devin,

the version which we are using is 8.2p1.
image
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.

You mentioned that you are using Attribute Change, now the Rule. Can you get us screenshot of your Leaver lifecycle event

Hi @MVKR7T ,

image
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

image
leaver ss is also attached for reference

Can you also share the rule Orbis-Leaver-ldentityTrigger-Rule ?

It is this rule which is returns true when Employee Status is changing.

You can remove sensitive data from the rule if needed.

– Remold

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.

Leaver, we need to check the Rule.

1 Like

Hi @Remold ,

Pleave validate the below Orbia-leaver-identitytigger-rule and let us know if there’s any issue with this

import sailpoint.tools.Util;
  import java.util.Date;
  import java.text.SimpleDateFormat;
  import sailpoint.object.Identity; 

  try {
    if(Util.isNotNullOrEmpty(newIdentity.getAttribute("type"))){
      if(newIdentity.getAttribute("type").equals("employee")){
        List<String> activeStatus = Arrays.asList("Active", "Paid Leave", "Unpaid Leave");
        List<String> disabledStatus = Arrays.asList("Terminated", "Retired");

        String previousStatus = previousIdentity.getAttribute("employeeStatus");
        String currentStatus = newIdentity.getAttribute("employeeStatus");
        String previousITAccount = previousIdentity.getAttribute("IT Account Continuity");
        String currentITAccount = newIdentity.getAttribute("IT Account Continuity");  


        if(disabledStatus.contains(currentStatus)
           && activeStatus.contains(previousStatus)){
          if(currentStatus.equals("Retired") || Util.isNullOrEmpty(currentITAccount)){
            return true;
          }else if(currentStatus.equals("Terminated")
                   && currentITAccount.equals("Maintain")){
            // Litigation Hold in Place
            // 1. If contains "disabledStatus" and "IT Account Continuity" equals "Maintain", DON'T RUN LEAVER process
            return false; 
          }else if(currentStatus.equals("Terminated")
                   && currentITAccount.equals("Deactivate")){
            // No Litigation Hold
            // 	2. If contains "disabledStatus" and "IT Account Continuity" equals "Deactivate",  RUN LEAVER process
            return true; 
          }
        }else if(previousStatus.equals("Terminated")
                 && currentStatus.equals("Terminated")){
          if(previousITAccount.equals("Maintain")
             && currentITAccount.equals("Deactivate")){
            // Litigation Hold Removed
            // 3. If is already "Terminated" and "IT Account Continuity" changes from "Maintain" to "Deactivate",  RUN LEAVER process
            return true;
          }
        }   
      } else if(newIdentity.getAttribute("type").equals("contractor")){
        if(!previousIdentity.isInactive() && newIdentity.isInactive()){
          return true;
        } 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; 
            }
          }  
          
          //return "ctrexpDt: "+ctrexpDt.getTime()+ " currentDt: "+currentDt.getTime()+ " == ? "+ (ctrexpDt.getTime() == currentDt.getTime());
          //return ((currentDt.getTime() - ctrexpDt.getTime()) / (24*60*60*1000));
        }
      }
    }  

    return false;
  } catch (Exception ex) {  

    return false;
  }

Hi @MVKR7T ,

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.

Hi @ayadav_12,

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.

1 Like

Hi @Remold ,

Thank you for your reply.

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.

@ayadav_12

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; 
            }
          }

Hi @iamksatish ,

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.

Trigger rule runs multiple times - Compass (sailpoint.com)

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.