Provisioning Invoke failure for identities

Hi All,

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.

Has anyone encountered a similar scenario?

Hi @varshini303

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.

Hi @trettkowski,

Thanks for your reply.

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.

Thank you for suggesting, no luck here too! Let me await response from the SailPoint ticket.

Hello Varshini. Since manual access requests work after the Create Profile fix, the AD connection and current profile setup should be okay.

SailPoint retries failed automated role provisioning for retryable errors once per hour, up to three times. Also, identity processing does not validate whether the access was successfully provisioned after provisioning was started. So if the role is still assigned, processing the identity again may not create another plan because there is no new role assignment change.

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.