How to Update Multiple Attributes Using Different Payloads in SailPoint ISC Web Services Connector

SailPoint Human Fabric (SHF) SHF Discussion and Questions
,
1

Hi everyone,

I’m currently working on a Web Services connector integration in SailPoint ISC, and I’m looking for some guidance on handling multiple attribute updates with different API payloads.

Current setup:

  • Web Services connector is configured and working

  • Account aggregation and account creation are successful

Requirement:
During account provisioning, we need to update different sets of attributes using separate SOAP API payloads:

  • End Date → updated via one SOAP request

  • First Name, Last Name, Email → updated via a different SOAP request

  • Both payloads also require the user’s assigned entitlement to be included

What worked so far -

  • I was able to implement attribute sync for a single attribute (end date) using one operation

  • Not sure how to extend this to handle multiple attributes requiring separate API calls within the same provisioning flow

Questions:

  1. What’s the best way to configure multiple update operations for a single account in the Web Services connector?

  2. How can we ensure both payloads receive the required entitlement data consistently?

2

You can use before operation rule in update account operation and update attribute through API call in rule itself and for one attribute you do it in update operation.

3

Set it up as a PATCH operation,
set id as "$getobject.nativeIdentity$
include all attributes that may get updated

job done. The UPDATE function will only send those attributes that get updated and send nulls for the rest. All in one operation

4

Thanks for the response @amankumargupta @PhilRawlings1

Regarding the update account operation — in my case, the target system requires two different SOAP payloads:

  • One for updating end date

  • Another for first name, last name, and email

Also, both payloads require:

  • All account attributes

  • Assigned entitlements

I was able to implement the end date update using a Before Operation Rule linked to the Update Account operation.

However, I’m trying to understand the best approach for handling multiple payloads within the same provisioning event.

Would it be recommended to:

  • Use a single Update Account operation and handle multiple API calls inside the Before Operation Rule, based on which attributes are changing?

If so:

  • What’s the best way to structure the rule to handle multiple payloads cleanly?

  • How can we reliably include entitlement data in both API calls?

5

Yes, that is how I implemented in one of the webservice application.

Check for the attributes which are present in the plan. Those attributes will be the attributes which needs an update on target system.

Attributes which are mandatory to pass and are not present in the plan, try to get those attributes values from target system and build the request body.

For example, if end Date is present in the plan that means, it requires an update and fetch all the mandatory attributes from target system by making an API call and build your request body for that.

If only one attribute needs an update just build the request body in before operation rule and let Update account operation, make an Api call.