ISC Service Catalog Integration with ServiceNow - Approval Reassigned to Service Account and Denied

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello everyone,

We are integrating SailPoint ISC with ServiceNow Service Catalog (Manage Access and Record Producer). The integration works in lower environments, but we are seeing an issue in Production.

Configuration:

  • Approval Scheme: ISC Workflow
  • Configurable Approvals: Enabled
  • Generic Approvals: Enabled
  • Authorization Code authentication
  • Application Registry using PAT authentication
  • Identity correlation is done using servicenow sys_id

Issue:
Requests are submitted successfully from ServiceNow to ISC, and the correct manager is initially assigned as the approver within SailPoint. However, the approval is later reassigned to a ServiceNow service account and the request is denied by that account.
In ServiceNow, no approval records are generated, and we see the following error:
“Approver is skipped from the approval execution plan. Possible reason: Inactive Users.”
We have verified that the approver is active in both ISC and ServiceNow, and that the servicenowId to sys_id correlation is working as expected. The issue is reproducible across multiple users and approvers.

Has anyone encountered similar behavior with ISC Workflow approvals? Any insights on what could cause the approval to be reassigned to a service account and subsequently denied would be appreciated.

2

Hi Himaghna. This matches a documented ServiceNow Service Catalog condition with Configurable Approvals + ISC Workflow. If an approver in an ISC governance group is missing or inactive in ServiceNow, ServiceNow skips the approvals and cancels the requested item with that “Inactive Users” message (troubleshooting doc).

I would start by checking every member of any ISC governance group in the approval plan, not just the manager, and confirm each one resolves to an active ServiceNow user. It would also help to verify the Prod correlation. If servicenowId is a custom ISC identity attribute, it should be configured as attributes.servicenowId and matched to the ServiceNow sys_id you are using (config doc).

If you would prefer the request to proceed when only one governance-group member is valid, SailPoint documents this customization for app v3.2.0+:

sys_extension_instance.LIST → x_sap_intidn.IDNWorkFlowGroupBehaviour

  • ProceedForAll → Active = false
  • ProceedForAnyone → Active = true

The service account appearing for the approve/reject action is also expected, since ISC Workflow approvals run under client credentials rather than the individual user (connection parameters doc).

3

We are still getting the same error after the change.