The modify operation sourced from identity refresh task creating duplicate tickets for a particular application when the create provisioning request is not committed. This getting stopped when the provisioning status became committed. This creates many duplicate tickets whenever the identity refresh is running. In this case, since the identity refresh ran 4 times, 4 duplicate requests are created apart from the original ticket that sourced from LCM create operation.
As a solution to this issue, I would suggest running the aggregation task from this application, which should prevent SailPoint from attempting to create the account again. It is likely that, at this moment, IIQ is trying to create a new account each time until it receives confirmation from the connector that such an account has indeed been created.
what is the Modify/create operation provisioning request initial trigger point? is it from a user request or some role assignment, some other point? please share end to end flow configured.
FYI, IdentityIQ does not, by default, test whether this trigger has fired before or what the outcome was for the previous trigger. if it is create and there is not account exists for that identity on the application there will be a create plan processed (if it sees a account already in place which will go to modify rather than create) and if the particular access/account provisioning request is already present on identity that particular request is filtered out.( i see couple of the requests in the screen shots are filtered out)
@Sriindugula the modify operation is triggered when identity refresh task is executed. Do you think that we can restrict this by updating the identity refresh task properties?
It is standard IIQ behavior.
You could alternatively try setting the flag for the Plan object:
plan.setOptimisticProvisioning(true);
this will likely result in the absence of repeated provisioning attempts, even if the account aggregation has not been triggered. However, setting this flag may lead to a lack of transparency in the actual data that has reached the application because with this flag, we always assume that everything went correctly, even in the event of an error.
In your case I would set scheduled task for aggregation of this Applikation two times a day.
But I do not know how exactly is your Environment configuración.
Yes the aggregation task is being called by the identity refresh task which is scheduled to run four times a day. If you see the screenshot uploaded, the source says Identity refresh.
I mean the Aggregation Task for the Dow Jones Riskcenter Application. Do you have a scheduled task for this application that performs aggregation at least once daily?
I am getting this issue again only for a particular application. We have separate aggregation task for the application and that aggre task is also part of the full refresh task. I have created a separate refresh task as mentioned few days not faced the issue but again it raised.
