Issue:
After a certification campaign revoked entitlements on a Web Services application, IdentityIQ started sending repeated HTTP PATCH calls to the configured endpoints. These retries continue across different webservice groups, causing HTTP 429 (rate limit) errors and blocking aggregation. Attempts to stop the retries (disabling request processors, enabling maintenance mode, restarting task servers, cleaning request objects) have not worked.
Current setup:
-
Request Definition uses
sailpoint.request.IntegrationRequestExecutorwithretryMax=20. -
Application-level provisioning retries set to 1 (but seems ignored during certification).
-
Logger in after-operation rule shows continuous PATCH payloads.
Questions:
-
Which process or task triggers these retries in certification-driven provisioning?
-
How can we immediately stop the retry loop?
-
What’s the best way to prevent this in future (e.g., retry/backoff settings, workflow changes)?
below 2 articles in sailpoint community were explaining the similar issue
https://community.sailpoint.com/t5/IdentityIQ-Forum/Provisioning-Retry-Behavior/m-p/206529
https://community.sailpoint.com/t5/IdentityIQ-Forum/Retry-doesn-t-appear-to-be-using-application-co…
Any guidance or best practices would be appreciated.