Entitlement provisioning retries to AD connector – limit or infinite?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hi everyone,

I’ve noticed that when entitlement provisioning to the AD connector fails, SailPoint retries the operation a number of times. However, it seems like it keeps retrying on every identity refresh, seemingly indefinitely.

Does anyone know if there’s an actual limit to the number of retry attempts, or does it retry forever until the issue is resolved?

Also, does anyone know of a way to trigger a notification/email when provisioning to a AD source fails and Sailpoint doesn’t retry to provision? Any built-in feature, workflow, or best practice for this would be really helpful.

Thanks in advance!

2

You can trigger a notification on provisioning failure using the Provisioning Completed trigger and a filter on @.provisioningResult == ‘failed’

On the retry subject, if the entitlement is based on a role then any time there is an identity refresh it will try again to provision it.

3

I noticed that it tries to reprovision it also if it is an entitlement, but I want to send the notification of the failure ONLY when there are no more Sailpoint retries on the last fail.

4

Hello Salvatore. @MattUribe is right on using the Provisioning Completed trigger, that’s the right approach for this.

For a retryable error, SailPoint retries the provisioning action once per hour, up to 3 times. The trigger is sent after the action completes, so filtering for a failed result should notify you when that action reaches its final failure, after its retry cycle has ended. (Errors and Retries, Provisioning Completed)

The filter needs to check provisioningResult inside accountRequests:

$.accountRequests[?(@.source.name == "Your AD Source" && @.provisioningResult =~ /failed/i)]

If a later identity refresh still sees the entitlement as assigned but missing from AD, it can create a new provisioning action. That is not a fourth retry. It is a separate action with its own retry cycle, so it may generate another notification if it also reaches a final failure. You can compare the trackingNumber to confirm they are separate actions.