O365 Access Removal Fails During Termination Lifecycle Event

Hi Community,

I am experiencing an issue when users are terminated through a Lifecycle State change in Identity Security Cloud (ISC).

When the user’s lifecycle state is changed to Terminated, the access removal process for Microsoft 365 sometimes fails. The failures are intermittent and occur with different error messages:

  • “sailpoint.connector.ConnectorException: java.lang.InterruptedException: Timeout waiting for response to message 0 from client”

  • “Error due to concurrent requests being made to the tenant. Please wait briefly and retry.”

The termination process generally completes, but the O365 deprovisioning step occasionally fails with one of the errors above.

Has anyone encountered similar behavior when deprovisioning Microsoft 365 accounts during a termination event?

A few questions:

  1. Is there a known Microsoft Graph or Entra ID throttling limitation that can cause this?

  2. Are there any recommended retry mechanisms or best practices for handling these concurrent request errors?

  3. Has anyone successfully mitigated this issue within ISC provisioning workflows?

Any guidance or recommendations would be appreciated.

Thank you.

Hi Ahmed,

What kind of connector are you using ?

  • If you are using the Entra connector, then you can increase the value for the timeout to trigger following this documentation : Timeout Errors and Settings

  • If you are using a webservice connector, you can setup the error messages for which a retry mechanism will trigger : Retry Configurations

    I’ve never had the “concurrent requests” error message though.

Regards,

I am Using Microsoft Entra ID connector, I will check

The intermittency is the tell-tale sign of Graph API throttling that occurs when multiple access removal calls hit Microsoft concurrently. The recommended path is: increase provisioningTimeout + configure retryableErrors with a longer retryWaitTime on the O365 source, and consider staggering your termination lifecycle states. If the issue persists at scale, engage SailPoint Support to review how the O365 connector specifically handles HTTP 429 responses from Graph.