I’m troubleshooting an issue where AD provisioning is no longer being triggered for few identities, even though:
The identities satisfy the role membership criteria and the expected roles are assigned under roles tab of the identities.
Access request fulfilment continues to work normally.
Initially, provisioning was being triggered but was failing during execution. This was fixed by some tweaks in AD create profile and was validated for one user through manual access request. However, after processing the identities multiple times and even applying role changes, provisioning is not being triggered at all.
This sounds like a case where all the connector retries were exhausted and now it will not attempt to retry since the connector thinks it’s already attempted.
Try and run a single account aggregation then process identity/apply changes for this account to see if it retriggers the provisioning. Single Account Aggregations are ran unoptimized, so this should reset the retry count for this specific account. If that does fix your issue, then doing an unoptimized aggregation for the full source would be the fix for the rest of the users.
I did have tried several single account aggregations and unoptimized aggregations of both the source and target applications and then processing/applying. This didn’t help for now. Have raised a SailPoint ticket to check for any stale processing state or caching within SailPoint for the affected users.
Good to know that you raised the SailPoint ticket. Please remove the account from the identity cube and request the provisioning again and see whether it triggers the process.
For one affected identity, you could try temporarily making the user fall outside the role criteria, process the identity and confirm the role is removed. Then restore the criteria and process again. This should create a fresh role assignment and trigger provisioning using the corrected Create Profile.
If no Account Activity is generated after that, I think waiting for SailPoint Support is the right approach.
Thanks for the inputs, looks like there were multiple queues of pending provisioning transaction items already scheduled via access requests for those affected users.
After they were cleared at a certain point of time, the roles were then processed to initiate provisioning.