Leave of Absence Workflow Task Firing off Multiple Times

[chrisk (Christopher Knapp)]

Hello,

In IIQ 8.3 I am trying to setup a workflow to disable an Identities AD Account if they are found to be on Leave of Absence.

At first, it was kind of working but every time the Identity was refreshed it would fire off the workflow again.

I found in the Identity XML that there was a new key under TriggerSnapshots called ‘AttributeChange’ that still had the old value in it. I’m assuming that when I am comparing previousIdentity status to newIdentity status, it is grabbing that old value from the AttributeChange key.

Here is an example –

<Attributes>
    <Map>
      <entry key="businessUnit" value="Corporate"/>
      <entry key="department" value="IT Security"/>
      <entry key="displayName" value="Lynn Duncan"/>
      <entry key="email" [email protected]/>
      <entry key="employeeId" value="98816"/>
      <entry key="employeeType" value="Employee"/>
      <entry key="firstname" value="Lynn"/>
      <entry key="forwardingEnabled" value="False"/>
      <entry key="lastname" value="Duncan"/>
      <entry key="location" value="Santa Barbara"/>
      <entry key="recordStatus" value="Hired"/>
      <entry key="startDate" value="9/21/2021 12:00:00 AM"/>
      <entry key="status" value="LOA"/>
      <entry key="team" value="Cloud Security"/>
      <entry key="title" value="Security Analyst"/>
      <entry key="triggerSnapshots">
        <value>
          <Map>
            <entry key="AttributeChange">
              <value>
                <Attributes>
                  <Map>
                    <entry key="businessUnit" value="Corporate"/>
                    <entry key="department" value="IT Security"/>
                    <entry key="displayName" value="Lynn Duncan"/>
                    <entry key="email" [email protected]/>
                    <entry key="employeeId" value="98816"/>
                    <entry key="employeeType" value="Employee"/>
                    <entry key="firstname" value="Lynn"/>
                    <entry key="forwardingEnabled" value="False"/>
                    <entry key="lastname" value="Duncan"/>
                    <entry key="location" value="Santa Barbara"/>
                    <entry key="recordStatus" value="Hired"/>
                    <entry key="startDate" value="9/21/2021 12:00:00 AM"/>
                    <entry key="status" value="LOA"/>
                    <entry key="team" value="Cloud Security"/>
                    <entry key="title" value="Security Analyst"/>
                    <entry key="userName" value="LD98816"/>
                  </Map>
                </Attributes>
              </value>
            </entry>
            <entry key="Rule" value="0aab098888d512758188d72cf6ae0368"/>
          </Map>
        </value>
      </entry>
      <entry key="userName" value="LD98816"/>
    </Map>
  </Attributes>
 

SailPoint Support said this was because I did not have the Argument ‘processTriggers’ set to ‘True’ on the Workflows Refresh step.

I then added that Argument/value to the workflow and now when the Identity is refreshed it starts the workflow over and over again until I have to cancel everything manually. Once I cancel all the tasks that it caused to run, everything seems OK. The AD Account is disabled and upon another refresh it does not fire off the workflow again.

I am not a Developer, but I’m really trying here. I’ve attached the Trigger Rule and the Workflow. I was hoping someone here would have some input as to where I’m going wrong?

Thank you.

Workflow.txt (13.6 KB)
WorkflowTrigger.txt (719 Bytes)

[brian_weigel]

Try adding promoteAttributes and checkHistory to the workflow’s refresh step options and see if that solves your issue.

You might need to play with the refresh step refresh options to find the combination that you need to get the workflow to fire only once. Here’s a reference that lists the UI version of the options and their XML name counterparts: https://community.sailpoint.com/t5/IdentityIQ-Articles/Task-Definition-Attribute-Cross-Reference-UI-XML-Message-Key/ta-p/71566

[chrisk (Christopher Knapp)]

Finally got it to stop triggering in a loop! Changed foregroundProvisioning from ‘True’ to ‘False’ and it started behaving as expected. Also found multiple Variables in the WF that were duplicated, removed all the duplicates.

Thanks for your help and input, it is much appreciated as I learn all of this!

Chris

[drosenbauer (Devin Rosenbauer)]

There’s another more Java-y option here, which I’ll leave for future readers:

1. Store a ThreadLocal object in IIQ’s sailpoint.object.CustomGlobal Map. You can do this if it’s missing in step 2. CustomGlobal is shared across the entire application. Alternatively, if you deploy any custom Java classes, just create one that has a static ThreadLocal. It’s important that the same ThreadLocal object be used everywhere.
2. In your Workflow, set the ThreadLocal value to the current Identity ID.
3. In your Event Trigger rule, read the ThreadLocal value. If it’s equal to the Identity ID in the trigger, automatically return false and don’t check further.

You may want to add a post-refresh step or a catches=“complete” step to your Workflow to null out the current thread’s “currently being processed” ID, though the next workflow to run should just replace it with the next value.

This will prevent recursive event triggers, even if you or a future developer in five years gets the Refresh options wrong.