I have a question regarding Provisioning Plan execution behavior in SailPoint IdentityIQ, specifically around multiple AccountRequest for the same account.
Scenario
In a Leaver use case, we are building a provisioning plan like below:
Plan:
AccountRequest (Modify – Remove entitlements) → Application A
AccountRequest (Delete – Account) → Application A
So for the same application + nativeIdentity, we have:
1st → Modify (Remove entitlements)
2nd → Delete (Account)
Concern
In production environments with large volumes of data:
How does SailPoint ensure execution order?
Is there a possibility that:
Delete executes first
Then Modify executes (which would fail because account is already deleted)
Specific Questions
Does SailPoint execute AccountRequests sequentially as defined in the plan, OR does it internally merge/optimize them?
How does the provisioning engine handle multiple AccountRequests for the same:
Application
NativeIdentity
Is execution order guaranteed, or is it abstracted through Provisioning Project compilation?
Are there any documented best practices when combining:
Modify (Remove entitlements)
Delete (Account)
in the same plan?
Observed Behavior
We noticed that REMOVE operations (from Modify) are not reflected in Provisioning Engine in Access Requests → Details i could see only Delete Operation
Only DELETE is executed
This suggests that SailPoint might be optimizing or collapsing operations internally.
Expectation
We want to confirm:
Whether this behavior is by design
Whether there is any risk of execution order issues in production
Recommended approach to handle this use case safely
Thanks
Appreciate any insights or official references on this behavior.
1. what you are seeing is correct, if there are multiple account request for the same account, you will see them getting merged in the plan.
2. I don’t think you can control or order it unless you remove the entitlements first and then in the after-provisioning rule, you create another request to delete the account or schedule a workflow to execute later, like after 30min to delete the account.
3. Deleting an account will take care of purging the account access.
I have couple of questions. When you are deleting account, why are you removing entitlement separately? If accoung is deleted, automatically entitlement should get remove. But still if you want to perform both operations, try to put removal of entitlement in same accountrequest of delete. Dont create two separate account request.
@yedurureddy We also did the same implementation: Remove Roles, Remove Entitlements, Disable Account.. we created 3 separate requests one after the other to have better control on execution and to validate the transactions after each operation to make sure we are not missing.
It is always better to split to make sure we are not leaving with orphan assignments.
Hi rijubh,
Good Question simple answer if we didn’t follow the above approach we couldn’t see what are the Roles/Entitlemnts present in the account before deletion.
This we can see Under Track Requests and we will have list of transactions there in UI we can see the two different Entries/rows one with Entitlements Removed and one with delete operation
Hope you got the answer.
Thanks.
Yes for disable it is acceptable that you have separate plans for each operation, but for delete it does not make much sense. What will happen in case of delete is that if the delete operation gets executed first and then remove entitlement gets hit, then there are chances of error. Such things can not happen in case of disable, unless you are sending a disabled account to different container.
Hi Guys,
We Got the solution here by testing it in Lower Environments and we did this on JDBC connector applications
Approach
1.We implemented the Leaver workflow with above scenario.
2.We printed the final plan
3.In provisioning Rule we have added the log.trace(“The Plan From Provisioning Rule”+plan.toXml()); before return statement.
The logs show that The Plan From Provisioning Rule"+plan.toXml() is printed only once in entire process i.e., for Delete Operation.
This proves that if two Operations (Delete, Modify) are present in plan with same Application with same NativeIdentity then the most priority one (Delete) will be Executed.
Thanks.
@rijubh We have observed cases of orphan assignments. That’s why it is advisable to clear the associations first before deleting it. so we followed order of removing access first before deleting account.
