Lifecycle Event not triggerring for some users. The event type is "Attribute change"

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Hi Team

IIQ version 8.4 P2

We have a lifecycleevent whose eventtype is “Attribute change” and the new value filter is “true”.

We have a sequential task which executes a rule runner task and Refresh task with process Events option enabled.

The rule updates the attribute in identity to true and the expectation is that the following refresh should trigger event. But for some of the users event is not getting triggered. Anything I can do to resolve the issue?

Thanks

Divya M

2

The lifecycle event will only fire when IIQ sees an actual delta during Identity Refresh with Process Events enabled. So if it is not triggering for some users, first thing I would check is whether that attribute really changed from some other value to true. For an Attribute Change event, IIQ must detect a real change.

A few things I would watch here:

  1. Make sure those users are actually part of the refresh scope, especially if the task is running only for changed identities.
  2. Check whether your rule is really saving the identity attribute before the refresh runs.
  3. If the old value was already true, then there is no delta, so the lifecycle event will not fire.
  4. Also check if those identities are stuck in processing queue or not fully picked up by refresh.

For troubleshooting, I would test with one affected user first. Run a dedicated Identity Refresh for that identity with Process Events enabled and compare the old and new value of the attribute before and after the rule runs. If it works for a single identity but not in the full task, then the problem is likely with task scope or timing, not the lifecycle event config itself.

3

@DivyaSubha We had a similar setup in the past for one of the client. What we observed as multiple rules and refresh were running and modifying the same identity object, and IIQ automatically updates the IdentityArchive object. If there are series of changes, then the old value gets overridden with the new value and in life cycle events, you’ll see that it’ll not trigger the event as old and new value are same.

To fix this, we started relying on the current values and achieved it using a supportive attribute. What we did is:

  • Let’s say your requirement is if value change for attribute1 to true, then you should assign entitlement1.
  • You have attribute1 → whose value will change from true to false
  • Added an attribute2
  • Added a Global Rule in attribute2 to check if attribute1 is true and entitlement1 is assigned, then set LCEState to NA, else assign it to LaunchAttributeChange
  • In our LCE, we set the condition as attribute1 = LaunchAttributeChange.
  • At the end of workflow, add a refresh step to refresh the attributes.
  • You can use the attribute2 for all the events that you have which you can use to set different values like LaunchJoiner, LaunchMover, etc if needed.

This worked well for us and we removed dependency on historical objects or comparison.

Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(:heart:,:+1:, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

4

@iamkiran @neel193 The users are in the scope of refresh object. One query I have is, is there a possibility that triggersnapshot is not getting added to some identities while setting an attribute via rule?

5

@DivyaSubha In our case, we were using the rule and doing the comparision between previousIdentity and newIdentity values, which was not working. So we had to use the above workaround.

6

Hi @neel193 @iamkiran I am able to replicate the same in our lower environment.

Steps:

  1. Created new user in sailpoint
  2. Set the attribute “dormantUser” to true using a rule.
  3. Identity i = context.getObjectByName(Identity.class, o);
    i.setAttribute("dormantUser", "true");
    context.saveObject(i);
  4. While checking in Debug, triggersnapshot is not created for this identity.

Any inputs why the “triggersnapshot” has not been created?

Thanks

Divya M

7

Hi @DivyaSubha ,

Can you log the before and after values of the attribute in the run rule task to check if the attribute is changing or not in run rule task, to trigger lifecycle event

8

@DivyaSubha When you use setAttribute method, snapshot won’t be created. You should use provisioner with few arguments mentioned below to change the identity attribute and create triggerSnapshots at the same time. Then if you run the refresh task, event will be triggered.


  Identity identity = context.getObjectByName(Identity.class, "0001");

  ProvisioningPlan plan = new ProvisioningPlan();
  plan.setIdentity(identity);

  AccountRequest acctReq = new AccountRequest();
  acctReq.setApplication(ProvisioningPlan.APP_IIQ); 
  acctReq.setOperation(AccountRequest.Operation.Modify);

  AttributeRequest attrReq = new AttributeRequest();
  attrReq.setName("email");
  attrReq.setValue("test@email.com");
  attrReq.setOperation(Operation.Set);

  acctReq.add(attrReq);
  plan.add(acctReq);

  Provisioner provisioner = new Provisioner(context);
  provisioner.setTriggerSnapshots(true);  
  provisioner.setNoLinkUpdate( true);
  provisioner.execute(plan);
9

@DivyaSubha In normal cases, how are you determining dormantUser value? Must be reading it from some application link. Please update the link details directly in debug and save it.. → then run refresh attribute with Refresh Identity Attributes option. This should populate the triggerSnapshots entry.

Note: Found a fix?Help the community by marking the comment as solution. Feel free to react(:heart:,:+1:, etc.)with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.

10

Hi @SivaprakashRNTBCI For some of the users the Attribute change event is processed successfully. This affects few users.

11

Hi @neel193 The attribute is set to true for the users through the rule and then the identities are disabled.

In case, the identities are getting enabled in SailPoint, the attribute is cleared using the Reinstate workflow.

In case, the user’s AD account got enabled in AD end, then through source mapping the dormantuser attribute is cleared up.

12

@DivyaSubha

I beleive any other attribute change during aggregation or refresh created a triggerSnapshot that captured the old dormantUser value along with other identity attributes. When the identity refresh ran, it detected a change against that snapshot and triggered the event.

To verify this, test your rule on one or two users who do not have existing triggerSnapshots in their Identity XML.

13

Hi @SivaprakashRNTBCI Thank you for your inputs. If the user is having trigger snapshot already, will it overwrite the previous value? How to handle this?

Thanks

Divya M

14

@DivyaSubha If a triggerSnapshot already exists in identity, the provisioner skips creation - no action is taken.

15

@DivyaSubha Please LCM Workflow to set the attribute instead of using setAttribute. Using setter skips the some of the steps, which provisioning APIs does.

16

one way would be - instead of triggering the LCE via Attribute Change you can try with Rule and in the Rule you can check for a custom object.
In this custom object you can store list of users whose value has to be changed to “true” from the Rule which is running and setting true value in identity.
during every run you can clear the list and add new users.

flow:

  1. Rule runs - > sets value to true for identity and add user in the custom object list.
  2. LCE event is Rule based now and it will check custom object whether user is present in list or not. if present trigger LCE
17

This will only work when you run the rule + refresh task together in a sequential manner and need to maintain the same frequency. If refresh is running more frequently than the rule, it’ll continue trigger events on the users part of the custom object.

18

no that will not happen. everytime refresh runs the rule will clear custom object. it will only take the new objects which are not processed yet, if they are processed we can set custom object back to empty. this can be easily coded in rule

19

Could you please specify which rule you are referring here? and what will be the task sequence?

20
  1. the initial Rule which is setting value to true in identity object (as given in problem description), that rule will store indentity in custom object.
  2. next when refresh runs, it will be rule based and it will check the custom object list and check if identity in action is present in custom, if it is, then process the LCE and remove the identity from custom.

Here it will not matter which task gets executed first, because the trigger Rule is going to check custom and custom will always be updated.