ServiceNow governance connector – role and group provisioning suddenly failing (isGroupUpdateFailed / isRoleUpdateFailed true), aggregation still works

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

Hi all,

I’m facing a provisioning failure on the ServiceNow Identity Governance connector that started recently, after a period where everything worked correctly. I’d appreciate any pointers, especially on how to get the underlying error detail.

Environment

  • Identity Security Cloud (ISC)
  • ServiceNow Identity Governance connector
  • Authentication: OAuth 2.0, Client Credentials grant
  • Development environment

Symptom

When assigning a group through a role in ISC:

[ConnectorError] Account update failed. Update operation to the account [<sys_id>] is failed.
isAttrUpdateFailed: false, isGroupUpdateFailed: true, isRoleUpdateFailed: false

When assigning a role:

[ConnectorError] Account update failed. Update operation to the account [<sys_id>] is failed.
isAttrUpdateFailed: false, isGroupUpdateFailed: false, isRoleUpdateFailed: true

So both role and group provisioning fail independently, while attribute updates report no failure.

What still works

  • Account aggregation runs successfully.
  • Entitlement aggregation (roles and groups) runs successfully.
  • Test connection succeeds.

So the connector authenticates and reads without issue – only write operations against role and group membership fail.

What has been verified on the ServiceNow side

The ServiceNow administrator has confirmed:

  • The four tables listed in the SailPoint documentation (sys_user, sys_user_group, sys_user_grmember, sys_user_has_role) have read, create and update access, plus “Allow access to this table via web services” enabled.
  • No changes have been made to the service account: no roles removed, no group memberships altered.

The service account does not have the user_admin or admin roles. It does have a broad set of module roles (itil, sn_incident_write, sn_request_write, sn_change_write, cmdb roles, etc.), but nothing specific to user administration.

Relevant timeline

The only significant change in the environment is that we recently configured the ServiceNow Service Desk Integration (SDIM) on the same instance, using the same service account, and added two roles to that account for it: x_sap_sdim.admin and a customer-specific role for incident creation. Group and role provisioning through the governance connector was working before that work started.

I want to be clear that I have no evidence linking the two – it’s simply the only change I’m aware of.

Questions

  1. How can I obtain the underlying HTTP response behind this error? The ConnectorError only reports the boolean flags and does not expose what ServiceNow actually returned. Is this visible in the ccg logs, or does it require a support case to retrieve?

  2. Does the governance connector require the user_admin role in addition to the table-level ACLs documented? My understanding is that ServiceNow enforces a privilege-escalation protection over sys_user_has_role and sys_user_grmember that operates above table ACLs, but I’d like to confirm whether this connector is subject to it or whether table permissions alone are sufficient.

  3. Can configuring the SDIM on the same instance and service account affect the governance connector? I’m aware of reported behaviour in this community where credentials get cleared after modifying a Service Desk integration. I’d like to know whether anything similar can affect a source connection sharing the same account.

  4. Is there any additional permission requirement for provisioning that is not listed in the connector documentation – for example when the target group grants roles by inheritance, which would imply the service account needs to hold those roles itself?

Any guidance on where to look next would be very welcome, particularly on question 1 – without the underlying response I’m working blind.

Thanks,
Juan

2

Ask your servicenow admin to show you the import set tables that the application uses and see if your updates are making it there first.

If they aren’t, you may have to check the servicenow user transaction log to see if it’s making posts to those import set tables.

Also make sure the account has the roles required to post to import set tables

The reason your aggregations are working is they read directly from the target tables the import set tables are mapped to. For account updates, the calls go to the import set tables and not directly to the target tables. The only time direct write calls are made to the target tables is for group/role removal which calls a DELETE http request against the record in sys_user_grmember or sys_user_has_role