We are currently encountering the following issue:
A user does not initially have an account in application X.
The user submits a request for a role that includes an IT role with a group mapped to application X. This request enters the approval process.
While the first request is still pending, the user submits a second request for another role, which includes a different group mapped to the same application X. This second request also goes through approvals.
After the approval process:
The first request successfully provisions and creates the account in application X.
When the second request is approved, instead of modifying the existing account, the system attempts to create a new account in application X, resulting in a failure (as the account already exists).
I understand that this can be addressed by implementing logic to switch the account request operation from Create to Modify in the Before Provisioning Rule if a link already exists. However, I am interested in understanding whether there is an out-of-the-box (OOTB) solution for handling this scenario.
Otherwise, would the recommended approach be to implement a Before Provisioning Rule for each application to handle this logic?
you have to check whether account exists in application on before provision rule.
If account exist than change request operation to modify.
Another option check is there any access request is pending for requested user with same application , in workflow , you can reject the access request and provide message to requestor “other request is in progress” or something,
There is no OOTB solution in SailPoint IdentityIQ that handles this scenario automatically. This is a known race condition where two requests are raised concurrently before any account exists, so IIQ captures a Create operation for both at the time of request submission.
The recommended and most feasible solution is a Before Provisioning Rule.
In the rule, before provisioning is executed, check whether a Link already exists for the identity on the target application. If a Link is found, switch the ProvisioningPlan account request operation from Create to Modify. This ensures the second approved request correctly modifies the existing account rather than attempting to create a duplicate.
This rule only needs to be written once and can be applied generically across applications — it does not need to be a separate rule per application. A single rule that checks for an existing Link by application name is sufficient and is the standard approach used in most IIQ implementations for this scenario.
@bhalitoglu I never tried this, but seems you can handle this in your Approve and Provision Subprocess. Post approval, before recompiling, you can check if the approved role is already assigned and user has account, then change it to Modify. This should work globally and you don’t need to handle it via before provisioning rule for each app.
@bhalitoglu - I would recommend checking whether the account already exists within the workflow. If the account exists, set the ProvisioningPlan operation to Modify; otherwise, set it to Create.
This approach eliminates the need to update the Before Provisioning Rule for each individual application.
Hi Burak, welcome to the SailPoint Developer Community!
As far as I know, there isn’t an OOTB mechanism that automatically converts a pending Create operation into a Modify when multiple requests for the same application are approved independently.
A Before Provisioning Rule is a common approach to handle this by checking whether the account already exists and changing the operation from Create to Modify when appropriate.
If (operation == Create) and link already exists for application then Change operation to Modify. This is good approach for Before provisioning rule for such issues. But due to this you have to attach before prov rule for all application.
But if you modify workflow with same logic then this will be applicable for all applications.