I’ve been testing out the ServiceNow Identity Governance Connector in our sandbox environment recently, with the intention of getting to the point of being able to support certification campaigns for this source. I’ve noticed that when I use the {hostURL}/cc/api/source/reset/{sourceId} endpoint in the Private (cc) API collection for a given ServiceNow Gov Connector source configuration, that the next time I run an Entitlement Aggregation, I get a different (generally, much smaller and with fewer successful mappings of display names/description data from sys_ids) result set than if I run an Entitlement Aggregation with a “fresh” configuration of this connector (fresh meaning I had not run the /reset endpoint on that source config at any point). My guess is that something is happening so that ONLY groups/roles that are associated with Users in ServiceNow are coming back after a /reset, just based on observing what Groups are missing in the post-reset source vs fresh source.
In our case, it’d be much preferable to a) be able to reliably use the /reset endpoint for the sake of ease when needing to update account schema/correlation configs and b) to expect a result set matching what happens with the “fresh” source’s entitlement aggregation (which appears to be ALL Groups/Roles)
This is all with the same OAuth2.0 credentials, and with no deviation from OOB configuration (in particular, no usage of the filters options when aggregating)
Could anyone help me determine why this could be happening, and if there’s a workaround other than “don’t use /reset endpoint with this source”?
First screenshot is the “resetted source” Entitlement Aggregation info modal, second screenshot is the “fresh source” Entitlement Aggregation info modal
With regards to the behaviour witness. Indeed this is the behaviour:
On Account Aggregation this will aggregate both the users as well as any associated entitlements, this will populate therefore the entitlements (ServiceNow groups) that have been aggregated from the user accounts, which not alone be from the standard groups user table the entitlements aggregation would pull from.
On Entitlement Aggregation this will aggregate all entitlements(ServiceNow groups) specifically from the Groups user table (sys_user_groups)) in ServiceNow.
I am not sure I understand the need for the entitlements reset being used here, is there one? unless its just testing the theory out, then your observations are correct.
Please also keep in mind( note: I’m just the messenger here ) that the connector does not support removing groups directly from the connector (if that’s what is intended), such as when using this for the certification campaign use case (revoke entitlement): Supported Features ( this is due to a limitation in place with ServiceNow, which may be possible to overturn by reaching out to both your SailPoint CSM and ServiceNow CSM).
Resetting the source isn’t for a particularly special reason, just that in the future we may want to be able to reset a source’s data without wiping its configuration (as described in this section of the docs Managing Sources - SailPoint Identity Services). If we can’t rely on consistent aggregation behavior post-reset though, then we won’t be able to do that and will instead have to re-map our source definition configuration over to a new source every time we want to update account schema or try out new correlation logic.
So, we’re not necessarily trying to remove Groups from users by resetting, though we are interested in that functionality anyways. I will reach out to our CSMs.
In case anyone else stumbles on this: we spoke to a SNOW engineering resource from SailPoint and found that writing from Sailpoint → SNOW → AD (if SNOW is configured to read its users/groups from AD) is NOT currently supported by the SNOW Identity Governance Connector. Workarounds would be to manage entitlements directly with AD, or to write custom integrations in SNOW to write to AD after group membership revocations are pushed to SNOW from SP.
) that the connector does not support removing groups directly from the connector (if that’s what is intended), such as when using this for the certification campaign use case (revoke entitlement):