We observed an issue in our QA ServiceNow catalog integration setup with ISC. Specifically, when an access request is submitted through the ServiceNow catalog, all ISC-configured approvals are being skipped within ServiceNow. As a result, the request transitions directly to Work in Progress instead of remaining in a Pending Approval state. When we submit the request via ISC native Request Center the issue is not observed.
Despite this behavior in ServiceNow, the access request is correctly awaiting approval on the ISC side and is visible to the appropriate approvers in the ISC. (validated at the Approval Management page)
Our SNOW catalog integration leverages a custom widget instead of the OOTB widget, we were able to replicate the issue with both the custom widget and the OOTB widget.
Our ServiceNow catalog integration uses a custom widget; however, we were able to reproduce the same issue using the out-of-the-box (OOTB) widget as well. This indicates that the issue is not specific to the custom widget implementation.
I have also observed similar behaviour & my understanding is ServiceNow request flow only tracks the ServiceNow native approvals. Since the approvals are configured in ISC, ServiceNow request directly goes into Work in Progress or Fulfilment though request is awaiting for approvals in ISC. If you switch your approvals to ServiceNow native, you will not face this challenge.
Welcome to the SailPoint Developer Community, thank you for your response.
This is a recently observed issue. Our catalog integration was functioning as expected prior to December 11, leveraging ServiceNow-configured L1 approvals and ISC-configured L2/L3 approvals.
We currently use the SailPoint workflow in ServiceNow, which polls the ISC access item approval configuration and creates an approval record under the Approvals tab of the RITM for the appropriate ISC approver to take action within ServiceNow.
Our initial assessment indicates a potential delay in the ISC API response. When the SailPoint workflow in ServiceNow polls ISC, this delay may result in the approval configuration not being returned in time. Consequently, ServiceNow may interpret this as no approvals being required and automatically transition the request to Work in Progress, effectively skipping the approval step.
To mitigate this behavior, we are planning to enhance the existing workflow by increasing the wait timer. The current wait time is limited to 2 minutes, and we are considering extending it to up to 15 minutes to better accommodate potential API response delays.
edit: The impacted RITM is being automatically canceled after the maximum checkStatus attempts are exhausted.
Following request submission, the system automatically adds the following comment to the request each time it checks the fulfillment status:
“The request is currently being processed. Please await further updates.”
This comment is logged repeatedly until the maximum checkStatus threshold is reached, after which the RITM is canceled.
We raised a support case with SailPoint, and the support engineer confirmed that delays in the ISC API responses are the root cause of the issue. SailPoint is actively working on a fix, with a tentative resolution target of March 31.
In parallel, we implemented a 35-minute wait period in the ServiceNow SailPoint catalog integration workflow before polling ISC for the configured approval information. After introducing this change, the L2 and L3 approvals were successfully synchronized from ISC to ServiceNow.
The 35-minute wait period was explicitly recommended by SailPoint and was not an arbitrary configuration change.