Leaver trigger multiple times for an Identity

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

When i am running my refresh identity cube task with process event based on termination date my liver is triggering. But issue is that the same identity received multiple Disable requests. How can i handle this or how can i stop this via changes. Please suggest best way to debug or change in my trigger condition.
Also first time it triggered successfully and disable all the account but after that creating so many request as below in pending

  • 00012472
  • 00012473
  • 00012474

this is my trigger condition
System.out.println(“LCE leaver Trigger Rule Started”);
return isTriggerLeaverRule(context, previousIdentity, newIdentity);
System.out.println(“LCE leaver Trigger Rule Ended”);

2

Is Leaver triggered multiple times or just disable part of your Leaver workflow process is called multiple times.
Are you using Rule for your Leaver Identity Trigger. If conditions are not handled properly in the Rule being used for identity trigger this can happen for example you may be checking if today’s date is termination date and this may be true whenever identity refresh runs throughout the day. You have to make sure you handle it by checking for another attribute like LeaverLaunched that you would set as soon as your Leaver workflow is started.
Though you have mentioned you are using isTriggerLeaverRule its not clear what’s happening within this rule/method.

3

Only disable part is triggering multiple times.

  public boolean isTriggerLeaverRule(SailPointContext context, Identity previousIdentity, Identity newIdentity){
    llogger.trace("Enter isTriggerLeaverRule");
    boolean flag = false;

    String currStatus = "";

    if(newIdentity == null || newIdentity == void){
      llogger.warn("Identity objects are null");
      return flag;
    }

    String identityName = newIdentity.getName();

    Custom mappingObj = getLeaverMappingObject(context);

    llogger.trace("Have mapping object: " + mappingObj);
    if (mappingObj == null){
      llogger.warn("No mapping object");
      return flag;
    }

    llogger.trace("Mapping object not null: " + mappingObj.toXml());

    String triggerType = mappingObj.get("Trigger Type");
   String newAssignmentStatus=null;
    String oldAssignmentStatus=null;
          if(null != newIdentity && null!=previousIdentity){
    
    newAssignmentStatus = newIdentity.getStringAttribute("assignmentStatus");
	   	   oldAssignmentStatus = previousIdentity.getStringAttribute("assignmentStatus");
  
          }
    if(null != newAssignmentStatus && null!=oldAssignmentStatus){

    if(newAssignmentStatus.equalsIgnoreCase("Staff not joined") && oldAssignmentStatus.equalsIgnoreCase("Due to join")){
  
      return true;
    }
   else if ("Custom Rule".equalsIgnoreCase(triggerType)){
      llogger.trace("Call custom rule to trigger");

      flag = isLeaverCustomTriggerRule(context, previousIdentity, newIdentity);
    } else if("Selector".equalsIgnoreCase(triggerType)){
      llogger.trace("Determine if trigger using a selector");
      Matchmaker matchMaker = new Matchmaker(context);
      IdentitySelector idSelector = mappingObj.get("Trigger Field Selector");

      flag = matchMaker.isMatch(idSelector, newIdentity);
    } else {
      llogger.warn("Unknown trigger type: " + triggerType);

    }
}

    llogger.trace("Exit isTriggerLeaverRule: " + flag);
    return flag;
  }
4

Helo Aman. Since only the Disable part repeats, I would first check whether requests 00012472, 00012473, and 00012474 came from separate Leaver workflow launches or one execution. Task Results, WorkflowCase XML, or logs should help narrow this down.

Looking at your rule, the status condition compares old and new values, but the Selector checks only newIdentity. If the identity continues to match, it can trigger again. For an attribute-based selector, try:

boolean matchesNow = matchMaker.isMatch(idSelector, newIdentity);
boolean matchedBefore = previousIdentity != null &&
    matchMaker.isMatch(idSelector, previousIdentity);
flag = matchesNow && !matchedBefore;

If the condition is date-based, this comparison may not help, since the termination date itself does not change. Instead, consider a persisted leaverLaunched flag, checked before any branch returns true and set when the workflow starts, before disabling accounts. I would also review the Custom Rule conditions and confirm whether the assignmentStatus null checks are intentional. Finally, test a second identity refresh to confirm no additional disable request is generated.

5

Hi @AMANSINGH12 ,

would you please kindly confirm that solely a single instance of the Leaver workflow is triggered.

I have to admit that I’m not yet sure if you are facing multiple launches of the workflow (which is somehow expected behavior) or multiple executions of a step within a single workflow instance.

IIQ is evaluating trigger rules multiple times and you will be able to observe that behavior by adding some log outputs to your trigger rule.

Also you can find details about that behavior explained here:

As already mentioned you have to find ways to prevent multiple launches of the workflow either by populating some kind of “launch attributes” or checking if a workflow instance was already launched for this occurrence of the Lifecycle Event.

You may also find the following discussion helpful:

Best regards,
Daniel