Web Services SaaS connector – How to handle ADD/REMOVE entitlements when API only supports UpdateUser (GraphQL)

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

Hi all,

I’m working with a Web Services SaaS connector in SailPoint IdentityNow / ISC, using GraphQL as the underlying API.

The target application does not support ADD or REMOVE operations for entitlements.
Instead, it only exposes a single mutation:

mutation UpdateUser

This mutation expects the full list of permission groups every time.

The problem

When SailPoint performs an Add Entitlement, it sends only the new value.
Because the API uses UpdateUser, the result is that:

  • Existing permission groups are overwritten

  • Instead of merging, the user ends up with only the new entitlement

Example:

  • Current groups: [1]

  • SailPoint adds group 7

  • API receives: [7]

  • Result: group 1 is lost
    While the desired outcome is: [1, 7]

Limitation

In a classic Web Services connector, I would solve this using a Before Provisioning Rule to:

  1. Read current entitlements

  2. Merge (ADD) or filter (REMOVE)

  3. Send the full updated list back

However, the SaaS Web Services connector does not support Before Provisioning Rules.

Question

What is the recommended / best-practice approach in IdentityNow to handle this pattern?

Specifically:

  • How do you implement ADD / REMOVE semantics when the API only supports a SET via UpdateUser?

  • Is this typically solved via:

    • A Workflow (Read → Merge/Filter → Update)?

    • Transforms / JSONPath logic?

    • A single provisioning workflow handling both ADD and REMOVE?

Any examples, patterns, or documentation references would be greatly appreciated.

Thanks in advance!

Example scenario

  • Jan needs role1 in NIS.
    SailPoint provisions role1 via GraphQL using the UpdateUser mutation.

  • Piet needs role1 in NIS.
    SailPoint provisions role1 via GraphQL in the same way.

  • Klaas needs both role1 and role2 in NIS.

SailPoint first provisions role1 for Klaas via GraphQL.
Later, when role2 is requested, SailPoint performs an Add Entitlement and sends only role2 via the UpdateUser mutation.

Because the API uses a set/replace mechanism, the result is:

  • role1 is overwritten by role2

  • Klaas now only has role2

At the next update from SailPoint, the same overwrite happens again, causing roles to be lost.

:right_arrow: This is not the desired behavior, as Klaas should end up with both role1 and role2.

2

@ashwink Did you try using the SaaS Connectivity Customizers - Connectivity Customizers | SailPoint Developer Community

3

did you try cloud before prov’ rule?

on modify operation for add/remove entitlement, your rule should get use idnutil to get all entitlements of the user for the account and update plan.

I have not tried it myself but I am interested in knowing how this goes.

4

IMO it is a failing on Sailpoint, that there is not a Source attribute or checkbox in the UI to allow for all entitlements to be sent in a request, not just the delta.

Seems a no-brainer that should have been part of Web Service Connector design

5

This is not possible in the web service saas connector.

6

Can you elaborate what’s not possible?

7

See: Before/After rule supported for WS SaaS Connector? - Identity Security Cloud (ISC) / ISC Discussion and Questions - SailPoint Developer Community & Configure Endpoint Customization Before Operations

8

I think you did not get me right. I am referring to :

Web Services Before Operation Rule

9

I’am using the SaaS version will this work?

10

yes. the before operation rule will work no matter if its VA or SaaS connector.

11

I attempted to use a WebServiceBeforeOperationRule on a Web Services SaaS connector to merge entitlement values before an updateUser call. Although the rule can be created and linked, it is never executed and has no effect on the request. Based on testing and documentation, Before/After Operation Rules are not supported for Web Services SaaS connectors, only for the VA-based Web Services connector.

Debug logs show that the Web Services SaaS connector executes the updateUser call successfully and then performs an automatic Get Object (read-after-write). The request contains only the delta value for permissionGroupsId, and there is no indication that a BeforeOperationRule is executed. This confirms that the rule is ignored and does not modify the request.

12

you will not see logs in VA if its SaaS connector.

For SaaS connector logs, you will have to follow :

while you do figure these CLI setup etc, for testing, have the rule to do basic operation like update the first name or something.

Also make sure you are attaching the rule correctly to the connector.