Share all details about your problem, including any error messages you may have received.
I have an issue where for example if there is a new joiner X , when i check the task results I see " Joiner X - 1 , Joiner X -2 … , Joiner X - 50 "
for same users , and after some time , one provisioning request to AD is completed while others got error : object already exists , which makes since
I am suspecting the issue is because of some provisioning timeout is less than the needed value so SailPoint keep trying but I am not able to adjust this value
Hello Alaa, this looks more like the Joiner event firing repeatedly than only an AD timeout. A timeout can explain a provisioning retry, but it would not normally create 50 separate Joiner workflow cases. The object already exists errors are most likely the result of duplicate Create requests reaching AD after the first request already succeeded.
The first place I would check is the Joiner event configuration under Setup > Lifecycle Events.
If the event type is Rule, review the IdentityTrigger rule. It should detect an actual transition by comparing previousIdentity with newIdentity. If it only checks the current value, such as status being Active, it may return true again whenever Identity Refresh runs with Process Events enabled.
Also compare the start times of those workflow cases with the Identity Refresh task results. That should show whether they came from one refresh run, overlapping refresh tasks, or something inside the Joiner workflow starting another refresh.
Could you share the Joiner event type, the trigger rule if it is rule-based, and the Identity Refresh task options? That should help narrow down exactly where the duplicate launches are coming from.
the joiner event type is rule that triggers if the user do not have AD account and its start date is equal to today.
i will try to get and share this rule
the refresh task is scheduled every one hour , however the workflow trigger every less than one minute
Thanks Alaa. Since the scheduled refresh runs only once per hour but the workflows are starting less than a minute apart, something inside the Joiner workflow or one of its subprocesses may be refreshing the identity and causing the rule to be evaluated again.
The rule condition can remain true while the first provisioning request is still running or before IIQ reflects the newly created AD account. During that window, another event-processing refresh would still see that the start date is today and no AD account exists, so it can launch another Joiner case.
Could you also share the Joiner workflow XML? I would check for an Identity Refresh step, doRefresh=true, a custom refreshIdentity() call, or a task/subprocess being launched. Then confirm whether that refresh is processing lifecycle events.
For the permanent fix, you could add a marker such as joinerProcessedDate, save it when the first Joiner process starts, and have the trigger rule return false when that same start date was already processed. Using the date instead of only a true or false flag would also allow the identity to be processed correctly during a future rehire.
Thanks @punna0001@naveenkumar3
I just want to know how frequently the rule is evaluated ? I mean why it is evaluated multiple times while the refresh ran once ? is there any way to control the rules run?
regarding the workflow xml , yes there is one step to refresh the identity after AD attribute update but this exists only one time.
The rule does not have its own schedule. It is evaluated whenever that identity is refreshed with Process Events enabled. Since the hourly refresh runs only once, it may be worth checking the refresh step inside the Joiner workflow. Even though the step exists only once in the XML, every new workflow instance would execute it again, which could create a loop like this:
Could you check whether that refresh step contains:
<Arg name="processTriggers" value="true"/>
If it is enabled, you could try setting it to false for the internal refresh:
<Arg name="processTriggers" value="false"/>
Then keep Process Events enabled only on the scheduled refresh that is meant to start the Joiner. It may also help to save a processed date or status before the internal refresh and check it in the trigger rule, so the same start date does not start another workflow while the first one is still running.
Could you share the trigger rule and that refresh step from the workflow XML? That should help confirm whether this is where the loop is coming from.
the trigger itself doesn’t have any awareness that a Joiner is already in progress for that identity, so every time the scheduled refresh/aggregation task runs and re-evaluates the identity, it sees the same “new joiner” condition as true and fires the workflow again. This repeats on each refresh cycle until the AD provisioning step finally succeeds and the underlying condition changes.
There’s no native IIQ setting to throttle or limit how many times a trigger fires per identity — trigger frequency is entirely a function of how often the refresh/aggregation task is scheduled. The correct control is the joinerProcessingStatus attribute: it gives the trigger/workflow something to check so it recognizes an in-flight Joiner and skips relaunching until that status is cleared.
@AlaaKhaled I believe you are passing the plan to LCM workflow to provisioning. Could you please check your Provisioning Approval Subprocess and see if “noTriggers” variable is defined and set to true. ? IF no, please add this variable and set it to true.
<Variable input="true" name="noTriggers">
<Description>
If true, then do no attempt to trigger lifecycle events.
</Description>
</Variable>