Web Services SaaS source Update Account issue

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

I have a Web Services SaaS connector (authoritative source) which needs to post back updates to the managed account for a handful of attributes. The Update Account HTTP operation uses a raw JSON body to deliver the required attributes to be updated:

{
  "globalid": "$plan.nativeIdentity$",
  "accountName": "$plan.AccountName$",
  "email": "$plan.Email$",
  "firstName": "$plan.firstname$",
  "lastName": "$plan.lastname$",
  "activeAccount": "$plan.adAccountActive$",
  "lastLoginEvent": "$plan.lastLogonEventTimestamp$"
}

The first 3 attributes (nativeidentity, AccountName and Email) are rendered correctly, however the remaining attributes are missing from the body as the request builder believes the $plan.*$ attributes are empty or incorrectly configured. This is confirmed by both the platform hosting the REST end-point (Azure integration Services) as well as the ISC logs (see below):

:"BaseHttpRequestBuilder.ts Exiting prepareRawBody() for JSON : {\"globalid\":\"HI200999\",\"accountName\":\"john.doe\",\"email\":\"john.doe@devlab.acme.com\"}","requestId":"8ea2fd575f6

The logs also record the removal of the attributes that are empty:

[2026-02-24T17:33:53.424+08:00] DEBUG | connectorMessage ▶︎ {"AppType":"Web Services SaaS","commandType":"std:account:update","invocationId":"f65082ab-914c-48d6-bc2f-4e09c043e58a","message"
:"BaseHttpRequestBuilder.ts Value for placeholder plan.lastname \"\n                                        + \"is empty. Skipping...","requestId":"8ea2fd575f6f40c3a58d1111faf58d50","timestamp"
:"2026-02-24T09:33:52.987Z","version":61}

My assumptions according to the documentation and online research are as follows:

  1. If the mapped attribute is null, the attribute is silently removed from the JSON body
  2. The $plan object maps to the identity itself (not the Web Services SaaS source schema)
  3. Attribute names are case sensitive
  4. The default CREATE provisioning policy is used for the Update Account operation - an UPDATE provisioning policy does not need to be created (although I did try creating this as well)

I have confirmed that the above attributes are indeed populated on the identity itself. I have tried every combination of case (camel, proper, lower) for all attributes, confirmed the spelling and the presence of each attribute in the source schema, create account configuration, attribute sync configuration and CREATE provisioning policy to no avail.

To further add confusion to the above, the Identity Events list for the identity that I have been manually syncing during testing shows 3 modify account passed events: 1 for the account name, 1 for the email address and 1 for the active account. The first 2 make sense as these appear in the JSON payload, however the active account does not.

Finally, on the identity account itself, under synced attributes, whilst all the above attributes appear, only the global id, first name and last name are populated, the remainder are null (double dash).

Anyone have similar issues or can shed any light on where to focus troubleshooting from here, would be greatly appreciated - I am out of ideas!

2

Hi @ssolig ,

what you can do is Create an Update Provisioning Policy and add the following in it.

Try adding attribute like emaildum and map the value to identity attribute of email and when you referring in the plan then refer is to as $plan.emaildum$

Do this for all the attributes which are missing and once you add all you should see the value coming for the update. Let me know if this does not work and we can look at other options

Thanks

3

Hi @ssolig ,

As @RAKGDS mentioned, adding a dummy attribute update in the provisioning policy has worked for me in the past. If that approach is not working in this case, you can consider using a Customizer to handle the requirement instead.

Thank you.

1 Like
4

Does your endpoint require you to send all of the attributes even if they aren’t changing? Trying to understand what your real issue is here. It is true that the entry will be removed from the object if the value being synced on the current account already matches.

5

Hi Rackesh,

yes something similar worked - I created duplicate/dummy attributes and mapped the required values to them, added them to the create provisioning policy and then used these in the update account operation and it worked. Did not need to create an update provisioning policy (I believe it just uses the create policy by default).

Not a very nice workaround but it works.

6

No, only some attributes are mandatory, the remainder are only required if they have values. As replied earlier, the dummy attribute solution is working for now. I am connecting with SP support and if we come up with a better solution I will post it here.