Web Services Connector - Update/Modify Account Best Practice

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

Hello,
I’m working with SailPoint Standard Web Services connector and need some guidance on how to implement an account modify/update operation purely through the Sailpoint ISC GUI—without writing any BeforeProvisioning rules. I have complete freedom to define how the target system should expose its “Update Account” API (it could be a PATCH, PUT, or any other HTTP method we choose), and I need to produce a set of technical requirements so that every downstream application can implement the same, standardized API contract.

My goal is to establish a common Update-Account API design that:

  • Accepts only the attributes that have actually changed (so a PATCH endpoint seems most appropriate, but I’m open to PUT operation or another approach).
  • Can be described in SailPoint’s web-services connector’s operation configuration entirely via the GUI.
  • Requires no custom rules or Java code—just clicks in the connector’s setup.

Right now, the only example in the SailPoint documentation is minimal and doesn’t explain how to structure the JSON request body for the Update operation in the connector. Could you provide:

  1. A recommendation for the best‐practice HTTP method (PATCH vs. PUT) and URL pattern for an “Update Account” endpoint.
  2. A sample JSON payload that shows how ISC web service connector must be configured

Maybe for this operation is mandatory to write at least a before provisioning rule but I think should be possible to update an account with only GUI configuration.

Example 1:
PUT Update Account (full update)

{
  "id": "12345",
  "firstName": "John",
  "lastName": "Doe",
  "email": "[email protected]",
  "phone": "+1-555-1234",
  "department": "Sales",
  "title": "Account Manager",
  "location": "New York",
  "active": true
}

I think that to manage this json is mandatory write a before provisioning rule. Is correct ?

Example 2:
PATCH (partial update)

{
  "email": "[email protected]",
  "phone": "+1-555-4321"
}

JSON with only modified attributes. How can we configure the connector to manage this ? Can you give me some body configuration examples ? I don’t know if there are some sailpoint placeholder that will contains these information (example: $plan.attributes.key$,$plan.attributes.value$)

Example 3:
PATCH (partial update) Standard (RFC 6902)

[
  { "op": "replace", "path": "/email", "value": "[email protected]" },
  { "op": "replace", "path": "/phone", "value": "+1-555-4321" }
]

JSON with only modified attributes in a particolar standard. How can we configure the connector to manage this ?

Thank you!

2

We helped a client do something similar with a custom-built application, and were very lucky the app’s dev team was great and very accommodating to SailPoint’s requirements.

In general, Example 2 is the way to go for the Update Account operation, which is only used for attribute sync natively. You configure the request body with all possible attributes that can be updated via attribute sync, and the connector will remove attributes not present in the plan from the body.

So with the following configuration that supports syncing email and displayName to the target system:

{
    "email": "$plan.email$",
    "displayName": "$plan.displayName$"
}

if email is the only attribute being updated, the displayName key/value pair will be removed entirely. For this example, the following request body would be sent to the target system’s API:

{
    "email": "[email protected]"
}
3

By utilizing the PATCH method and configuring the Update Account operation as outlined, you can achieve partial updates through the SailPoint IdentityNow GUI without the need for custom rules. This approach promotes efficiency and aligns with best practices for API interactions.

4

How can work this solution ?

{
    "email": "$plan.email$",
    "displayName": "$plan.displayName$"
}

I think that for example if the user changes only the email the final json will be:

{
    "email": "newUserEmail",
    "displayName": ""
}

And the displayName will be deleted on the target. This is not correct.

You wrote
" if email is the only attribute being updated, the displayName key/value pair will be removed entirely." How ? Will Sailpoint automatically remove from the json the fields with null value in the plan ?
If the connector automatically will remove attributes not present in the plan from the body how can we clean a field ? What if I want to clean for example a telephoneNumber ?

5

A key consideration when choosing between PUT and PATCH is whether you intend for SailPoint to manage all attributes of the target accounts.

We typically use PUT for new integrations where SailPoint is the authoritative source for every account attribute. PATCH, however, is easier to implement and better suited for targeted updates—such as enabling or disabling an account—where usually only a single attribute changes.

For broader modification operations using PATCH, we explicitly include all attributes intended for update in each request. This ensures these attributes are accurately reflected in both the SailPoint form and provisioning plan.

One challenge with this approach is maintaining a clear audit trail that accurately tracks each changed attribute. Additionally, the target system must be capable of intelligently recognizing and applying updates only to those attributes whose values have actually changed.

6
Objective Solution
Send only changed attributes $plan.accountAttributes$
Prevent overwriting unchanged fields Don’t use $plan.attribute$ directly
Explicitly clear (null) a value Use rule or explicit JSON config